[mira_talk] Re: malloc error with Mira 4.9.5_2
- From: Chris Hoefler <hoeflerb@xxxxxxxxx>
- To: "mira_talk@xxxxxxxxxxxxx" <mira_talk@xxxxxxxxxxxxx>
- Date: Fri, 12 Jun 2015 16:55:53 -0500
Whooooops … a malloc error? Strange little critter to see when the C++
code does not contain any malloc/free, and even new/delete have become very
rare.
Indeed. It's a perplexing error, but I have some more information. My
initial hunch about library incompatibilities seems incorrect. After some
fun with gcc 4.9.2, I was able to recompile and dynamically link mira.
Running it with our dataset gave me an upgraded error message,
$ ~/mira-4.9.5-local/bin/mira manifest.conf
Loading reads from S2-AP02_S2_L001_R1_001.fastq type fastq
*** glibc detected *** /home/hoeflerb/mira-4.9.5-local/bin/mira: malloc():
memory corruption: 0x0000000000ee106d ***
I played with some manifest settings and discovered that a denovo assembly
with the same data runs just fine. The problem only surfaces while running
a mapping assembly. So, I recompiled mira with debug flags and was able to
upgrade the error again,
$ gdb ~/mira-4.9.5-local/bin/mira
gdb> set args manifest.conf
gdb> run
Localtime: Thu Jun 11 10:28:27 2015
Loading reads or assembled contigs as reference backbone from
map_annotatedreference_out.maf type maf
/home/hoeflerb/local/include/c++/4.9.2/debug/vector:387:error: attempt to
access an element in an empty container.
Objects involved in the operation:
sequence "this" @ 0x0x9895fe8 {
type = NSt7__debug6vectorIN17PlacedContigReads8addoff_tESaIS2_EEE;
}
Failure, wrapped MIRA process aborted.
Program exited with code 0144.
There seems to be a problem when loading this maf file. Stepping through I
was able to get a backtrace,
247 as.loadSequenceData();
gdb> next
Localtime: Fri Jun 12 16:31:31 2015
Loading reads or assembled contigs as reference backbone from
/mnt/userdata/hoeflerb/wsgi/data/hoeflerb/mutants/mapping/map_annotatedreference_out.maf
type maf
/opt/local/include/c++/4.9.2/debug/vector:387:error: attempt to access an
element in an empty container.
Objects involved in the operation:
sequence "this" @ 0x0x98a11c8 {
type = NSt7__debug6vectorIN17PlacedContigReads8addoff_tESaIS2_EEE;
}
Program received signal SIGABRT, Aborted.
0x00007ffff5c72cc9 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
gdb> backtrace
#0 0x00007ffff5c72cc9 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff5c760d8 in __GI_abort () at abort.c:89
#2 0x00007ffff67ee7d5 in __gnu_debug::_Error_formatter::_M_error
(this=0x7fffffff8a30)
at ../../../../../gcc-4.9.2/libstdc++-v3/src/c++11/debug.cc:782
#3 0x00000000008631f8 in std::__debug::vector<PlacedContigReads::addoff_t,
std::allocator<PlacedContigReads::addoff_t> >::back
(this=0x98a11c8) at /opt/local/include/c++/4.9.2/debug/vector:387
#4 0x000000000085c823 in PlacedContigReads::searchOffsetTileForPlacement
(this=0x98ac338, position=0) at pcrcontainer.C:255
#5 0x000000000085d9c8 in PlacedContigReads::placeRead_helper
(this=0x98ac338, rpid=1, position=0, dir=1 '\001', urdid=1,
araoindex=@0x7fffffff9e2c: 0) at pcrcontainer.C:455
#6 0x000000000085e6c5 in PlacedContigReads::placeRead_helper
(this=0x98ac338, rpid=1, position=0, dir=1 '\001', urdid=1,
araoindex=@0x7fffffff9e2c: 0) at pcrcontainer.C:575
#7 0x000000000085d783 in PlacedContigReads::placeRead (this=0x98ac338,
theread=..., rpid=1, position=0, dir=1 '\001')
at pcrcontainer.C:412
#8 0x0000000000611ffc in Contig::initialiseContig (this=0x98ac300,
rlist=std::__debug::list = {...},
tags=std::__debug::vector of length 888, capacity 1024 = {...},
contigname="miseqd37_denovo_c1_bb",
fixedseq="atggaggtcgaggacgagagcatcctcgtcagcaaccggtccaaggtgtccggcctctcccagcggtatgcgaagatccgcgcacaggccctgagcccggacgaatccctgggcctcatcgagcggttggcgggagaacggaaatgagcaccagcaccctgcggtggttcaagtcgagctacagcgacagcggcggcggc"...,
fixedqual=std::__debug::vector of length 118186, capacity 118186 =
{...}) at contig.C:4957
#9 0x000000000082a583 in MAFParse::parseLineEC (this=0xe75b70,
acttoken="EC", actline="!FFEDEDDEDC") at maf_parse.C:1278
#10 0x0000000000824c33 in MAFParse::loadNextSeqs (this=0xe75b70,
numseqstoload=18446744073709551615,
numconstoload=18446744073709551615) at maf_parse.C:477
#11 0x00000000008ab98c in ReadPoolIO::priv_loadNextSeqs_maf
(this=0x7fffffffb5a0, numseqstoload=18446744073709551615,
numconstoload=18446744073709551615) at readpool_io.C:699
#12 0x00000000008a9c05 in ReadPoolIO::loadNextSeqs (this=0x7fffffffb5a0,
numseqs=18446744073709551615,
numcons=18446744073709551615) at readpool_io.C:407
#13 0x00000000007044e4 in Assembly::streamSequenceDataFromManifest (
miraparams=std::__debug::vector of length 8, capacity 8 = {...},
man=..., readpool=..., contigsptr=0x7fffffffd570,
readsasbackbonecontigs=0x7fffffffbe10) at assembly_io.C:496
#14 0x00000000007026fc in Assembly::loadSequenceDataFromManifest
(this=0x7fffffffcbe0) at assembly_io.C:236
#15 0x000000000070214e in Assembly::loadSequenceData (this=0x7fffffffcbe0)
at assembly_io.C:116
#16 0x0000000000476a1b in miraMain_wrapped (argc=2, argv=0x7fffffffeb28) at
mod_mira.C:247
#17 0x000000000047817b in miraMain (argc=2, argv=0x7fffffffeb28) at
mod_mira.C:462
#18 0x00000000004142c9 in main (argc=2, argv=0x7fffffffeb28) at mira.C:153
Does that help any? I can send the maf file, but it's large... (~3 Gb).
Other related posts:
