majiq build crash

[Bruce Southey]

Hi,

I am trying to Majiq with mouse NCBI annotated mm10 genome from UCSC.

Majiq Build v2.2-e25c4ac crashes after:

INFO - Detecting LSVs ngenes: 50563 

2021-04-27 11:20:40,444 (PID:2625700) - DEBUG - b'Gm18510'] Connect introns

2021-04-27 11:20:40,444 (PID:2625700) - DEBUG - b'Rack1'] Connect introns

/usr/include/c++/8/bits/stl_vector.h:932: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = grimoire::Intron*; _Alloc = std::allocator<grimoire::Intron*>; std::vector<_Tp, _Alloc>::reference = grimoire::Intron*&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed.

2021-04-27 11:20:40,444 (PID:2625700) - DEBUG - b'Gm13733'] Connect introns

This appears to be parsing the GFF file for the example above removing the following entry continues until the one

chr2    ncbiRefSeq.2020-10-27   gene    86953975        86954791        .       -       .       Name=Gm13733;ID=Gm13733;Name=Gm13733

chr2    ncbiRefSeq.2020-10-27   transcript      86953975        86954791        .       -       .       Parent=Gm13733;ID=Gm13733

chr2    ncbiRefSeq.2020-10-27   exon    86953975        86954791        .       -       .       Parent=Gm13733;ID=exon:Gm13733:1

There is some way to detemine the source of the crash?

Thanks

Bruce

[Paul Jewell]

Hi Bruce, 

Just as a preliminary, I want to make sure to mention it's important that your annotation (refseq?) matches the chr /seqid names from your bamfiles. 

However, in general, I'm not able to isolate the error case from this debug message alone. Would you be able to provide a full or subsetted example of the DB+bamfiles you are using to generate this error?

Thank you, 

-Paul

[Bruce Southey]

Hi,

The message seems to be related to introns so seems something is not being defined correctly.

Do you have a test example?

At least that should verify my build if it is software issues.

Is another option or build that provides actual debugging info?

Do you have place to upload it?

Thanks

Bruce

[Bruce Southey]

Hi

This is likely a memory-related bug exposed via aggressive gcc optimization.

I had tried using a single thread or different number of threads and different runs crash at different points. Then I tried an older computer with gcc 7.3 (instead of the gcc 8.4) and it did not crash.