Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bwa mem - segmentation fault #181

Closed
sguizard opened this issue Feb 27, 2018 · 2 comments
Closed

bwa mem - segmentation fault #181

sguizard opened this issue Feb 27, 2018 · 2 comments

Comments

@sguizard
Copy link

Hi,

I'm facing to quite annoying problem with bwa mem (version 0.7.15-r1140).
Indeed, I'm trying to run an alignment on our cluster (OS : Fedora 27) on two subset of reads by running this command :

$ head 1.fastq
@SRR5349606.1/1 HWI-D00238R:465:C6KY4ANXX:4:1101:1463:1865 length=125
NGATCGTTTGCTTCATTTTCAGTTTGTGTGCAGACAACTTTCTGTAAAATTCTCTTCTTAGCAAAGTTCATTTTTCACTTTGGGTGTGACAAGCTTATGTAAAATTTCTCTTTTTATTAGCAAAG
+SRR5349606.1/1 HWI-D00238R:465:C6KY4ANXX:4:1101:1463:1865 length=125
#<:AADB@F>FGGGEG1FCDF>G1B@FGGGGEGD>FBG@GGGGCFGGE1EGC>1E1:1F:@11=FFGGGGGGGGGG@BDEGG>//EGGEGEFGDDGCFGGGGGGGEGGGGGGGGF@GGGCGFCFD
@SRR5349606.2/1 HWI-D00238R:465:C6KY4ANXX:4:1101:1348:1993 length=125
NTTCATCTTCAACACTTAGAAACCTATCAAAGCCATGACATGTCATCATCTCCAAATCCCTACACTTTAGTTCAAAAAGGGAAAGAAAGGGGTTAGCACAATTAAGTACTAAGTATGGAGACCAT
+SRR5349606.2/1 HWI-D00238R:465:C6KY4ANXX:4:1101:1348:1993 length=125
#==BBGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGFGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
@SRR5349606.3/1 HWI-D00238R:465:C6KY4ANXX:4:1101:1296:1997 length=125
NTTATTTATGAAAGAATGGGTATTTCAGGAATTAATTTGAGTTTNANTNNGGANTTGTAATTATTTTAGATTTTATGGCCCATTTATGTAGTTATATATATATATATATATATATGATAGGAGAA

$ head 2.fastq
@SRR5349606.1/2 HWI-D00238R:465:C6KY4ANXX:4:1101:1463:1865 length=125
GTTTTCGTTTACAATTTTTTATGCTATTGTTGATCAATCTATCTAAAAGTAAAACAATAGAAACTTGGAATTGGAACTCTTTTTTTTGGTCACTACTGACGCCGTAGACTGAAAATGATGAAAAT
+SRR5349606.1/2 HWI-D00238R:465:C6KY4ANXX:4:1101:1463:1865 length=125
?B@BBEGEGGGEGGGGEFCDEGGGGGGGCFEGGGGGEGEG>FGCGGGGG@FDGGEGGDGFGGGGGGGFGGCFGGGGCE@FGEGGAGG@<F0E>FB@EGD0..9CGG<BFFFGC@C@@EGGG@E@@
@SRR5349606.2/2 HWI-D00238R:465:C6KY4ANXX:4:1101:1348:1993 length=125
AAAATGGTTTCTTAAAGAATGTTGGTCTATTGATGTTATGTTGTAAAGGAAATGTCCTTATCTAAGGTAATCTTGAGGAACACTTAAGTGTGCTTGAAGAGGTTGTATGGGCGGTCACTTCTTGT
+SRR5349606.2/2 HWI-D00238R:465:C6KY4ANXX:4:1101:1348:1993 length=125
BCCCBGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGFGFGGGGGGGGGGGGGGEGGGGG
@SRR5349606.3/2 HWI-D00238R:465:C6KY4ANXX:4:1101:1296:1997 length=125
TAATATTTAATTATTTATAATTTAAAATTCTGAATTTTGTGCTGCTGACATGTGTCCTTTTTTTCTTCTCCTATTATATATAGATAGATATTAAATCTGTCCTAGATATAAAAAAAAAATTAAAT

$ bwa mem -v4 potato_dm_v404_all_pm_un.fasta 1.fastq 2.fastq 
[M::bwa_idx_load_from_disk] read 0 ALT contigs
@SQ	SN:chr01	LN:88663952
@SQ	SN:chr02	LN:48614681
@SQ	SN:chr03	LN:62290286
@SQ	SN:chr04	LN:72208621
@SQ	SN:chr05	LN:52070158
@SQ	SN:chr06	LN:59532096
@SQ	SN:chr07	LN:56760843
@SQ	SN:chr08	LN:56938457
@SQ	SN:chr09	LN:61540751
@SQ	SN:chr10	LN:59756223
@SQ	SN:chr11	LN:45475667
@SQ	SN:chr12	LN:61165649
@SQ	SN:chr00	LN:48012048
@SQ	SN:ChrUn	LN:111078864
@PG	ID:bwa	PN:bwa	VN:0.7.15-r1140	CL:bwa mem -v4 potato_dm_v404_all_pm_un.fasta 1.fastq 2.fastq
[M::process] read 1000 sequences (125000 bp)...
=====> Processing read 'SRR5349606.1'/1 <=====
Segmentation fault (core dumped)

As you can see, the program stop at the first read with a segfault.
I checked validity of the fastq file and didn't found any problems. I tested the bwa mem program by successfully running an alignment on the same genome with other data.
Because i didn't found the origin of the problem, I decided to download the data on my desktop computer (OS Fedora 27) and run bwa mem (version 0.7.15-r1140) on it. Surprisingly, I didn't get any segfault and the program worked perfectly.

So i tried to recompile bwa on our cluster, but the segfault persist.
I have no more ideas for debugging this, that why I'm requiring your help.

I followed this Biostar thread, for generating the following backtrace :

$ gdb bwa-0.7.17/bwa
GNU gdb (GDB) Fedora 8.0.1-33.fc27
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from bwa-0.7.17/bwa...done.
(gdb) run mem -v4 potato_dm_v404_all_pm_un.fasta 1.fastq 2.fastq
Starting program: /home/sguizard/Work/sandbox/Align_PI245940_Andigena_seb/bwa-0.7.17/bwa mem -v4 potato_dm_v404_all_pm_un.fasta 1.fastq 2.fastq
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.26-21.fc27.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[M::bwa_idx_load_from_disk] read 0 ALT contigs
@SQ	SN:chr01	LN:88663952
@SQ	SN:chr02	LN:48614681
@SQ	SN:chr03	LN:62290286
@SQ	SN:chr04	LN:72208621
@SQ	SN:chr05	LN:52070158
@SQ	SN:chr06	LN:59532096
@SQ	SN:chr07	LN:56760843
@SQ	SN:chr08	LN:56938457
@SQ	SN:chr09	LN:61540751
@SQ	SN:chr10	LN:59756223
@SQ	SN:chr11	LN:45475667
@SQ	SN:chr12	LN:61165649
@SQ	SN:chr00	LN:48012048
@SQ	SN:ChrUn	LN:111078864
@PG	ID:bwa	PN:bwa	VN:0.7.17-r1188	CL:/home/sguizard/Work/sandbox/Align_PI245940_Andigena_seb/bwa-0.7.17/bwa mem -v4 potato_dm_v404_all_pm_un.fasta 1.fastq 2.fastq
[New Thread 0x7fff9a991700 (LWP 7900)]
[New Thread 0x7fff9a190700 (LWP 7901)]
[M::process] read 1000 sequences (125000 bp)...
[New Thread 0x7fff9998f700 (LWP 7902)]
=====> Processing read 'SRR5349606.1'/1 <=====

Thread 4 "bwa" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff9998f700 (LWP 7902)]
0x00007ffff71130b7 in memcpy@GLIBC_2.2.5 () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install libgcc-7.2.1-2.fc27.x86_64
(gdb) bt
#0  0x00007ffff71130b7 in memcpy@GLIBC_2.2.5 () from /lib64/libc.so.6
#1  0x000000000043137a in bwt_occ4 (bwt=0x670720, k=1858244998, cnt=0x7fff9998e9a0) at bwt.c:179
#2  0x0000000000431600 in bwt_2occ4 (bwt=0x670720, k=1244120757, l=1858244999, cntk=0x7fff9998e9c0, 
    cntl=0x7fff9998e9a0) at bwt.c:196
#3  0x0000000000431cca in bwt_extend (bwt=0x670720, ik=0x7fff9998eae0, ok=0x7fff9998ea60, is_back=0)
    at bwt.c:266
#4  0x00000000004322b8 in bwt_smem1a (bwt=0x670720, len=125, q=0x7fff94013910 "\004\002", x=35, 
    min_intv=2, max_intv=0, mem=0x7fff94080328, tmpvec=0x7fff94080340) at bwt.c:310
#5  0x0000000000432a17 in bwt_smem1 (bwt=0x670720, len=125, q=0x7fff94013910 "\004\002", x=35, 
    min_intv=2, mem=0x7fff94080328, tmpvec=0x7fff94080340) at bwt.c:355
#6  0x000000000043a97b in mem_collect_intv (opt=0x670370, bwt=0x670720, len=125, 
    seq=0x7fff94013910 "\004\002", a=0x7fff94080310) at bwamem.c:138
#7  0x000000000043d26f in mem_chain (opt=0x670370, bwt=0x670720, bns=0x670b90, len=125, 
    seq=0x7fff94013910 "\004\002", buf=0x7fff94080310) at bwamem.c:264
#8  0x00000000004503af in mem_align1_core (opt=0x670370, bwt=0x670720, bns=0x670b90, 
    pac=0x7fff9a992010 "S\374\n\320;\205H\222\220\005@\377\066?۹\f\267:/\376\270ރ\326\023\v\316p", 
    l_seq=125, seq=0x7fff94013910 "\004\002", buf=0x7fff94080310) at bwamem.c:1060
#9  0x00000000004510c4 in worker1 (data=0x7fff9a990d00, i=0, tid=0) at bwamem.c:1181
#10 0x000000000042bf67 in ktf_worker (data=0x7fff9a990bb0) at kthread.c:42
#11 0x00007ffff765161b in start_thread () from /lib64/libpthread.so.0
#12 0x00007ffff717691f in clone () from /lib64/libc.so.6

Thanks in advance for your answers and your help.

@sguizard
Copy link
Author

Ok, I found what happened.
It was the only thing that I didn't tested, the index files were corrupted.

I apologize for this useless issue.

@balis
Copy link

balis commented Dec 19, 2019

FWIW, it's not a useless issue at all, I just had the same problem and it gave me a hint to rebuild the index files - it helped, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants