On 11/07/11 18:46, Sébastien Boisvert wrote: > The said address is not stored. > \see > https://github.com/sebhtml/ray/blob/v1.6.1-rc3/code/structures/ArrayOfReads.cpp#L50
Ah, sorry, I missed the copy on line 90. It makes a lot more sense now. >> There's also another (?related) issue in that Read doesn't have a >> destructor, but it stores a uint8_t array which may need to be >> deallocated (or somehow flagged for potential deallocation) once the >> read structure is removed. > Read allocates memory using an external memory allocator. > See > https://github.com/sebhtml/ray/blob/v1.6.1-rc3/code/structures/Read.cpp#L124 > So basically, when Ray exists, this very allocator deallocates its > memory. Thanks, I see that now. > Run Ray in gdb to find your bug in constant time ! (or so) I did that, which is how I came to a piece of code that was copying a string. That really shouldn't cause a segfault: $ gdb ../code/Ray ... Reading symbols from /home/bioinf/install/ray/git/ray/code/Ray...done. (gdb) run -p phix_1.fasta phix_2.fasta ... Rank 0 has 10718 vertices (completed) Rank 0 is purging edges [1/10718] Rank 0 is purging edges [10718/10718] (completed) Rank 0: peak number of workers: 500, maximum: 30000 Rank 0: VirtualCommunicator: 21436 pushed messages generated 44 virtual messages (0.205262%) Rank 0 wrote RayOutput.degreeDistribution.txt ... Rank 0 is selecting optimal read markers [1/2000] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff69e65d3 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (gdb) bt #0 0x00007ffff69e65d3 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #1 0x00007ffff69e7a06 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::assign(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #2 0x0000000000486f9e in operator= (this=<value optimized out>, sequenceId=<value optimized out>, sequence=..., parameters=0x6eca08, outboxAllocator=0x6ef1a8, vc=0x6e8558, workerId=0, a=0x6ef2b8, allocator=0x6ea5d0) at /usr/include/c++/4.6/bits/basic_string.h:542 #3 IndexerWorker::constructor (this=<value optimized out>, sequenceId=<value optimized out>, sequence=..., parameters=0x6eca08, outboxAllocator=0x6ef1a8, vc=0x6e8558, workerId=0, a=0x6ef2b8, allocator=0x6ea5d0) at code/assembler/IndexerWorker.cpp:30 #4 0x00000000004b312f in SequencesIndexer::attachReads (this=0x6ea560, m_myReads=0x6ef2b8, m_outboxAllocator=0x6ef1a8, m_outbox=0x6ec988, m_mode=0x6ec938, m_wordSize=<value optimized out>, m_size=1, m_rank=0) at code/assembler/SequencesIndexer.cpp:106 #5 0x000000000044e726 in Machine::call_RAY_SLAVE_MODE_INDEX_SEQUENCES (this=<value optimized out>) at code/core/Machine.cpp:1094 #6 0x000000000044fffa in processData (this=0x6e8090) at code/core/Machine.cpp:1352 #7 Machine::runVanilla (this=0x6e8090) at code/core/Machine.cpp:529 #8 0x0000000000451864 in run (this=0x6e8090) at code/core/Machine.cpp:511 #9 Machine::start (this=0x6e8090) at code/core/Machine.cpp:456 #10 0x000000000042696b in main (argc=4, argv=0x7fffffffe298) at code/assembler/ray_main.cpp:29 Unfortunately, this doesn't happen all the time. Sometimes it quits with no scaffolds output. > If you introduce regressions in Ray that are not causing faults, you may be > interested in using git bisect too ! I actually tried git bisect after having trouble with observing the cause of the segfault with gdb, but it wasn't particularly informative (in part, because some of my commits didn't compile properly...). After that, I tried running again with your original git tree, and it was successful -- not quite sure why I thought both trees weren't assembling properly last night. -- David ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Denovoassembler-users mailing list Denovoassembler-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/denovoassembler-users
