defuse segmentation fault

[Lien]

Hi all,

I'm using the defuse program to detect gene fusions from RNA-seq data experiments. So far, I have already run it succesfully on 19 samples, but one samples gives me an error. The sequencing and processing of the fastq-files was similar for all samples, so I don't understand what is causing the error and how to solve it. Also, defuse runs on a cluster, so memory should not be an issue.

Failure for defuse command:
/gmap/2014-12-25/bin/gmap -D /defuse/data/gmap -d chr12 -f psl /defuse_out/GC011104_new_make_pairs/jobs/breakpoints.split.001.fa > /defuse_out/GC011104_new_make_pairs/jobs/breakpoints.split.001.fa.genome.12.psl.tmp
Reason:
Job command with nonzero return code
Return codes: 139
Job output:
Running on cnpew06.uz.kuleuven.ac.be
GMAP version 2014-12-25 called with args: /gmap/2014-12-25/bin/gmap -D /defuse/data/gmap -d chr12 -f psl /defuse_out/GC011104_new_make_pairs/jobs/breakpoints.split.001.fa
Checking compiler assumptions for popcnt: 6B8B4567 __builtin_clz=1 __builtin_ctz=0 __builtin_popcount=17
Checking compiler assumptions for SSE2: 6B8B4567 327B23C6 xor=59F066A1
Finished checking compiler assumptions
Note: >1 sequence detected, so index files are being memory mapped.
GMAP can run slowly at first while the computer starts to accumulate
pages from the hard disk into its cache. To copy index files into RAM
instead of memory mapping, use -B 3, -B 4, or -B 5, if you have enough RAM.
For more speed, also try multiple threads (-t <int>), if you have multiple processors or cores.
Pre-loading compressed genome (oligos)...,..,...,...,...,...,...,...done (50,194,464 bytes, 12255 pages, 4.24 sec)
Pre-loading compressed genome (bits)...,..,...,...,...,...,...,...done (50,194,512 bytes, 12255 pages, 3.92 sec)
Looking for index files in directory /defuse/data/gmap/chr12
Pointers file is chr12.ref153offsets64meta
Offsets file is chr12.ref153offsets64strm
Positions file is chr12.ref153positions
Offsets compression type: bitpack64
Allocating memory for ref offset pointers, kmer 15, interval 3...done (134,217,744 bytes, 16.43 sec)
Allocating memory for ref offsets, kmer 15, interval 3...done (165,223,408 bytes, 15.29 sec)
Pre-loading ref positions, kmer 15, interval 3.......................................................................done (173,974,980 bytes, 42475 pages, 8.78 sec)
No paths found for 28672
No paths found for 18047
No paths found for 9575
No paths found for 4406
No paths found for 4399
No paths found for 17815
Exception: SIGSEGV--segmentation violation raised at gmap.c:4066
/defuse_out/GC011104_new_make_pairs/log/defuse.46.sh: line 6: 9384 Segmentation fault /gmap/2014-12-25/bin/gmap -D /defuse/data/gmap -d chr12 -f psl /defuse_out/GC011104_new_make_pairs/jobs/breakpoints.split.001.fa > /defuse_out/GC011104_new_make_pairs/jobs/breakpoints.split.001.fa.genome.12.psl.tmp

real 2m58.901s
user 2m7.904s
sys 0m2.226s


any suggestions are most welcome.

Thanks,
Lien

[kmcallenberg]

Hello, similarly for me, after running deFuse successfully on a large number of samples, I am reproducibly seeing this same behavior for one sample as well. The output suggests looking at ipcs -m, but this appears to be empty.

I will contact the authors of deFuse with this issue and post back here if they have any suggestions.

Here is my output:

Signal received: SIGSEGV
Calling Access_emergency_cleanup
Removed existing memory for shmid 3964929
Removed existing memory for shmid 3932160

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: 114725 (351 bp)

real 5m31.585s
user 5m23.275s
sys 0m6.870s
Return codes: 9
Commands failed after 333 seconds

[anandksrao]

Could you resolve your problem?

gmap --cmdline=ATACCAGGTCCTTCATACCAGGTCCTTCATACCAGGTCCTTCATACCAGGTCCTTCATGCCAGGTCCTTCATACCAGGTCCTTCATGCCAGGTCCTTCATGCCAGGTTCTTCATACCAGGTCCTTCATCGCGACCTCACCAGGTCTATCAACGACCTCCTCAAATTACAGGTCTTTCAACGACCTCAAGAATATTTATGCCATACAGGGGGCTATTCTCACTTTATCTAATGAAATTAACTTATTATTAGCACAATTAGCTATTAATGATATTTTTTGTAGC,CCCTAAGCCAACGACCTATCAGGTCCCTAAGCCAACGACCTCTCAGGTCCCTAAGCCAACGACCTCTCAGGTCCCTAAGCTAACGACCTCTCAGGTCCCTAAGCCAACGACCTCTCAGGTCCTTCATGTCAGGTCCTTCATCGCGACCTCACCAGGTCTATCAACGACCTCCTCAAATTACAGGTCTTTCAACGACCTCAAGAACATTTATGCCATACAGGGGGCTATTCTCACTTTATCTAATGAAGTTAACTTATTATTAGCACAATTAGCTATTAATGAT -S
GMAP version 2015-06-23 called with args: gmap --cmdline=ATACCAGGTCCTTCATACCAGGTCCTTCATACCAGGTCCTTCATACCAGGTCCTTCATGCCAGGTCCTTCATACCAGGTCCTTCATGCCAGGTCCTTCATGCCAGGTTCTTCATACCAGGTCCTTCATCGCGACCTCACCAGGTCTATCAACGACCTCCTCAAATTACAGGTCTTTCAACGACCTCAAGAATATTTATGCCATACAGGGGGCTATTCTCACTTTATCTAATGAAATTAACTTATTATTAGCACAATTAGCTATTAATGATATTTTTTGTAGC,CCCTAAGCCAACGACCTATCAGGTCCCTAAGCCAACGACCTCTCAGGTCCCTAAGCCAACGACCTCTCAGGTCCCTAAGCTAACGACCTCTCAGGTCCCTAAGCCAACGACCTCTCAGGTCCTTCATGTCAGGTCCTTCATCGCGACCTCACCAGGTCTATCAACGACCTCCTCAAATTACAGGTCTTTCAACGACCTCAAGAACATTTATGCCATACAGGGGGCTATTCTCACTTTATCTAATGAAGTTAACTTATTATTAGCACAATTAGCTATTAATGAT -S
Checking compiler assumptions for popcnt: 000041A7 __builtin_clz=17 __builtin_ctz=0 _mm_popcnt_u32=7 __builtin_popcount=7
Checking compiler assumptions for SSE2: 000041A7 10D63AF1 xor=10D67B56
Checking compiler assumptions for SSE4.1: -89 -15 max=241 => compiler zero extends
Finished checking compiler assumptions
Starting alignment
Signal received: SIGSEGV
Calling Access_emergency_cleanup
Unable to retrieve queryseq for request

When I manually and arbitrarily change the query CDS sequence, by shortening it, it works and gives an alignment. Just an example below:
DCook04-2:RGEC anand$ gmap --cmdline=ATACCAGGTCCTTCATACCAGGTCCTTCATACCAGGTCCTTCATACCAGGTCCTTCATGCCAGGTCCTTCATACCAGGTCCTTCATGCCAGGTCCTTCATGCCAGGTTCTTCATACCAGGTCCTTCATCGCGACCTCACCAGGTCTATCAACGACCTCCTCAAATTACAGGTCTTTCAACGACCTCAAGAATATTTATGCCATACAGGGGGCTATTCTCACTTTATCTAATGAAATTAACTTATTATTAGCACAATTAGCTATTAATGATATTTTTTGTAGC,CCCTAAGCCAACGACCTATCAGGTCCCTAAGCCAACGACCTCTCAGGTCCCTAAGCCAACGACCTCTCAGGTCCCTAAGCTAACGACCTCTCAGGTCCCTAAGCCAACGACCTCTCAGGTCCTTCATGTCAGGTCCTTCATCGCGACCTCACCAGGTCTATCAACGACCTCCTCAAATTACAGGTCTTTCAACGAC -S
GMAP version 2015-06-23 called with args: gmap --cmdline=ATACCAGGTCCTTCATACCAGGTCCTTCATACCAGGTCCTTCATACCAGGTCCTTCATGCCAGGTCCTTCATACCAGGTCCTTCATGCCAGGTCCTTCATGCCAGGTTCTTCATACCAGGTCCTTCATCGCGACCTCACCAGGTCTATCAACGACCTCCTCAAATTACAGGTCTTTCAACGACCTCAAGAATATTTATGCCATACAGGGGGCTATTCTCACTTTATCTAATGAAATTAACTTATTATTAGCACAATTAGCTATTAATGATATTTTTTGTAGC,CCCTAAGCCAACGACCTATCAGGTCCCTAAGCCAACGACCTCTCAGGTCCCTAAGCCAACGACCTCTCAGGTCCCTAAGCTAACGACCTCTCAGGTCCCTAAGCCAACGACCTCTCAGGTCCTTCATGTCAGGTCCTTCATCGCGACCTCACCAGGTCTATCAACGACCTCCTCAAATTACAGGTCTTTCAACGAC -S
Checking compiler assumptions for popcnt: 000041A7 __builtin_clz=17 __builtin_ctz=0 _mm_popcnt_u32=7 __builtin_popcount=7
Checking compiler assumptions for SSE2: 000041A7 10D63AF1 xor=10D67B56
Checking compiler assumptions for SSE4.1: -89 -15 max=241 => compiler zero extends
Finished checking compiler assumptions
Starting alignment
>NO_HEADER
Paths (3):
Path 1: query 116..196 (81 bp) => genome 89..183 (95 bp)
cDNA direction: sense
Genomic pos: 89..183 (+ strand)
Number of exons: 2
Coverage: 41.3 (query length: 196 bp)
Trimmed coverage: 41.3 (trimmed length: 196 bp, trimmed region: 1..196)
Percent identity: 98.8 (80 matches, 1 mismatches, 0 indels, 0 unknowns)
Translation: 116..196 (27 aa)
Amino acid changes: A5V [127]

Path 2: query 116..141 (26 bp) => genome 47..72 (26 bp)
cDNA direction: indeterminate
Genomic pos: 47..72 (+ strand)
Number of exons: 1
Coverage: 13.3 (query length: 196 bp)
Trimmed coverage: 13.3 (trimmed length: 196 bp, trimmed region: 1..196)
Percent identity: 96.2 (25 matches, 1 mismatches, 0 indels, 0 unknowns)
Amino acid changes:

Path 3: query 116..141 (26 bp) => genome 5..30 (26 bp)
cDNA direction: indeterminate
Genomic pos: 5..30 (+ strand)
Number of exons: 1
Coverage: 13.3 (query length: 196 bp)
Trimmed coverage: 13.3 (trimmed length: 196 bp, trimmed region: 1..196)
Percent identity: 92.3 (24 matches, 2 mismatches, 0 indels, 0 unknowns)
Amino acid changes:

Alignments:
Alignment for path 1:

89-105 (116-132) 94% -> ...14...
120-183 (133-196) 100%

Alignment for path 2:

47-72 (116-141) 96%

Alignment for path 3:

5-30 (116-141) 92%

Processed 1 queries in 0.03 seconds (33.33 queries/sec)

So WHY am I getting this error, and how can I resolve it?