GMAP error - Problem Sequence: TRINITY_DN422143_c0_g1_i1 (301 bp)

Question

[TrentGenomics]

Hello,

I'm using GMAP-2017-09-11 as part of the RECOT (read coordinate transformer; http://sesejun.github.io/recot/ ; https://scfbm.biomedcentral.com/articles/10.1186/1751-0473-8-6) pipeline to transform the coordinates of a transcriptome assembly to the coordinates of the mouse genome (Mus_musculus.GRCm36.dna.primary_assembly.fa).

I have RNA-seq reads that I've assembled with Trinity, and have built a GMAP database for a target genome.

When I try to align my Trinity transcriptome to the target genome using:

$ gmap -f sampe -d Mus_musculus /scratch/$USER/Trinity.fasta > Mouse_on_Trinity.sam

the program terminates with this:

'Signal received: SIGSEGV
Calling Access_emergency_cleanup
Removed existing memory for shmid 1835049
Removed existing memory for shmid 1802280
You may want to run 'ipcs -m' to see if any shared memory segments are still in use
You can remove a shared memory segment manually by doing 'ipcrm -m <shmid>'
Problem sequence: TRINITY_DN422143_c0_g1_i1 (301 bp)'

Is anyone familiar with this program or has run into this problem before?

Any insight would be appreciated. Thank you.

[GenoMax]

What do you get if you run grep -c TRINITY_DN422143_c0_g1_i1 your_trinity.fa? (trying to see if you have that identifier repeated in your file).

[TrentGenomics]

Hi genomax. There is only one instance of that Trinity accession in my fasta file.

[WouterDeCoster]

As far as I know, the author is very responsive, so he may be able to nail this down. The error message is not very specific with regard what is wrong. Check the "problem sequence" and compare it with the others... to figure out if something is odd with this one.

[dukecomeback]

Dear TrentGenomics, have you solved this? I'm also stucked here

[tengwen2018]

Dear TrentGenomics and dukecomeback, I have just encountered the same situations. Do you fix it? Any help would be very appreciated!

... 
Removed existing memory for shmid 2818061 
Removed existing memory for shmid 2785292

You may want to run 'ipcs -m' to see if any shared memory segments are
still in use You can remove a shared memory segment manually by doing
'ipcrm -m <shmid>'

You may want to run 'ipcs -m' to see if any shared memory segments are
still in use You can remove a shared memory segment manually by doing
'ipcrm -m <shmid>'

Problem sequence: NS500669:281:HWHG5BGX5:1:11101:8270:1069 (38 bp)
Problem sequence: NS500669:281:HWHG5BGX5:1:11101:20770:1053 (38 bp)
Problem sequence: NS500669:281:HWHG5BGX5:1:11101:20770:1053
Problem sequence: NS500669:281:HWHG5BGX5:1:11101:13483:1063 (38 bp)
Problem sequence: CCTCTNS500669:281:HWHG5BGX5:1:11101:8270:1069
Problem sequence: NS500669:281:HWHG5BGX5:1:11101:11440:1061 (38 bp)
...

[EarlyEvol]

In case any one else is dealing with this problem.... I just encountered this error too. GMAP was complaining because I was piping the output to another program that was erroring out. Didn't notice the stderr from the downstream program because it was a bunch of lines up in gmap's verbose output.

[dukecomeback]

I'm not so sure if it has something to do with the header of the fasta sequences. Keeping the header of sequences in simple characters maybe help.