Error at GBitVec: index 16 out of bounds (size 16) (Stringtie V.1.3.1c)

[AMMMachado]

Hi,

This issue has been reported in #78 but i think we are currently still running into the same error with Stringtie version 1.3.1c.

Error at GBitVec: index 16 out of bounds (size 16)
Segmentation fault (core dumped)

The SAM file was generated with HISAT2 2.0.5 version with the --dta option and converted to BAM with samtools. We then run Stringtie (using 32 Gb of RAM) with the following command:

./stringtie -p 10 -G Mus_musculus.GRCm38.87.gtf -o SRR850587.gtf -l Mus_musculus SRR850587.bam

Cheers.

[gpertea]

Could you please run this without -p option but with -v so we can locate the bundle triggering the error?
Then after indexing the .bam file it would be great if you could extract the alignments for that bundle's region (using samtools view -b) and share the resulting .bam file with me.
I am assuming the annotation reference GTF you used there was downloaded directly from Ensembl, unchanged -- so I can download it myself from Ensembl. But if you processed it in any way please let me have that file too.

[AMMMachado]

Em 2016-12-19 18:12, Geo Pertea escreveu:

Could you please run this without -p option but with -v so we can locate the bundle triggering the error? Then after indexing the .bam file it would be great if you could extract the alignments for that bundle's region (using samtools view -b) and share the resulting .bam file with me. I am assuming the annotation reference GTF you used there was downloaded directly from Ensembl, unchanged -- so I can download it myself from Ensembl. But if you processed it in any way please let me have that file too. -- You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub [1], or mute the thread [2].

Hey Geo, Thanks for your attention. Here's what you asked for. In the .txt file goes the location package .With these coordinates was extracts the bam file. The gtf file was extracted directly from the Ensemble, as well as the file of the Mus genome. If you need something, just say. Best regards A.Machado Links: ------ - Output of -v [12/19 18:25:05]^bundle X:53772836-53773159(2) done (1 processed potential transcripts). [12/19 18:25:05]>bundle X:53774048-53776394(8) (1 guides) loaded, begins processing... [12/19 18:25:05]^bundle X:53774048-53776394(8) done (1 processed potential transcripts). [12/19 18:25:05]>bundle X:53777118-53797706(48) (3 guides) loaded, begins processing... Error at GBitVec: index 16 out of bounds (size 16) Mus_musculus_Assembly$ Commands used to generate and extract the subset bam file. samtools sort -@ 10 SRR850587_unsorted.bam SRR850587.bam samtools index SRR850587.bam samtools view -b SRR850587.bam X:53777118-53797706 > SRR850587.subset.bam

[gpertea]

Thanks - but I cannot access the file SRR850587.subset.bam, could you upload it somewhere? The github link you provided appears invalid (for me) -- it's some sort of "unsubscribe" link (?) which does not work for my account.

[AMMMachado]

SRR850587.subset.bam.zip

Try this link please.
A.Machado

[gpertea]

Still not working.. there is nothing intelligible in that 4K .bam file I unpacked from the .zip. What is the actual byte size of the .bam file you are trying to share? For me it shows as 4789 bytes .bam file inside that 4979 bytes zip file. But the .bam file does not have the correct header, it is not recognized as a real BAM file.
Also, as a side note, there should be no reason to zip a .bam file, it's already compressed (usually).

[AMMMachado]

In fact, my .bam file have 4766 bytes. Maybe having occurs some error during the process of .bam build.
Try in this link. I will add the complet bam file to the path.
https://www.dropbox.com/sh/87g5sdumzzry8wi/AACeoUyNpkzenBCHwtUITPuWa?dl=0

[gpertea]

Got it now and reproduced the error -- thanks! We'll take a closer look at this.

[gpertea]

There were some 1-base terminal exon read alignments there which triggered this bug.. We think we have a fix which will be released with v1.3.2 -- but until then, you could -- if you want -- test it on your data. The pre-release (not tested!) version can be downloaded here:

http://ccb.jhu.edu/software/stringtie/dl/stringtie-1.3.2-pre.tar.gz (source)
http://ccb.jhu.edu/software/stringtie/dl/stringtie-1.3.2-pre.Linux_x86_64.tar.gz (Linux binaries)

[AMMMachado]

Thanks by the answer. I can try the new one.
If i remove the SRA that triggered this bug in 1.3.1c, the remaining analysis keeps coherent and trustworthy?

[gpertea]

Rhetorical questions aside (I cannot know if discarding a sample from your data set has no impact on your research..), I tentatively released v1.3.2, if you're still using StringTie please download the last version from http://ccb.jhu.edu/software/stringtie/#install and let me know if you still encounter problems. I'm going to close this issue for now as I assume this particular bug was fixed, but feel free to re-open it (or add a comment) if that's not the case.