duncanca / mosaik-aligner

Automatically exported from code.google.com/p/mosaik-aligner
0 stars 0 forks source link

seg fault in MosaikMerge/AlignmentReader.cpp #17

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
(I'm using a read-only SVN checkout from 11/12/09)

I'm getting a segfault consistently after the first few alignments are read
by MosaikMerge; debugging with gdb, I see at line 737 of
AlignmentReader.cpp, this:

  memcpy((char*)&al.ReferenceIndex, mBufferPtr, SIZEOF_INT);

which then leads to an al.ReferenceIndex of something absurd (e.g.
287318578), which leads to the segfault when this absurd index is used to
offset the mRefSeqLUT array.  Again, this doesn't happen immediately/for
every alignment, but within the first 10 or so alignments it happens.  It's
as if the .dat file has some other data stuffed into that slot for those
alignments.

Curiously, MosaikText can parse and output these files without difficulty.

Original issue reported on code.google.com by ajmac...@gmail.com on 12 Nov 2009 at 4:59

GoogleCodeExporter commented 9 years ago
Hi there,

We noticed a problem where the reference index was being stored as an unsigned 
short
in previous versions (giving us up to 65,535 reference sequences). Some labs 
needed
more reference sequences for transcriptomics experiments and so we fixed the
reference index so that it's an unsigned int (up to 4 billion reference 
sequences).

While this was always the case in the code since Mosaik 1.0, I believe there 
were
some locations in MosaikSort that still recast the reference index to a short.

Best case, you may have to rerun MosaikSort on these older archives - worst 
case, you
may have to realign the archives (but that shouldn't be necessary).

The new release (1370) handles this problem.

Let me know how this works out,

// Michael

Original comment by snowneb...@gmail.com on 16 Jan 2010 at 2:17