Segmentation fault (core dumped)

[mksingh2104]

Describe the bug

Reading from SRR25144788_MN908947_3_bwa-mem_sorted.bam
Minimum Read Length based on 1000 reads: 50
Segmentation fault (core dumped)

To Reproduce

ivar trim -i SRR25144788_MN908947_3_bwa-mem_sorted.bam -p trimmed

[cmaceves]

Hi, can you please provide the version of ivar your using and a sample file?

[watronfire]

Hello, I'm having this same issue.

Upon running the following command: ivar trim -i test.bam -m 30
The following output and error is thrown:

Reading from test.bam
@HD     VN:1.6  SO:coordinate
@SQ     SN:AE003852     LN:2961182
@SQ     SN:AE003853     LN:1072319
@PG     ID:bwa  PN:bwa  VN:0.7.17-r1198-dirty   CL:bwa mem -M -t 8 resources/vc_reference.fasta /home/nate/analysis/2023.07.28_cholera/input/illumina/ERR976436_1.fastq.gz /home/nate/analysis/2023.07.28_cholera/input/illumina/ERR976436_2.fastq.gz
@PG     ID:samtools     PN:samtools     PP:bwa  VN:1.17 CL:samtools view -Sb -
@PG     ID:samtools.1   PN:samtools     PP:samtools     VN:1.17 CL:samtools sort -
@PG     ID:samtools.2   PN:samtools     PP:samtools.1   VN:1.17 CL:samtools addreplacerg -r ID:ERR976436 -o intermediates/illumina/merged_aligned_bams/ERR976436.sorted.bam -
@RG     ID:ERR976436
@PG     ID:ivar-trim    PN:ivar VN:1.4.2        CL:ivar trim -i test.bam -m 30
Segmentation fault (core dumped)

I'm using iVar v1.4.2, Samtools v1.9, and HTSlib v1.9 installed from conda.

Attached is the sample BAM file in question.
test.bam.zip

[cmaceves]

Thanks for the sample file @watronfire, our team will get right on that!

[watronfire]

I ran gdb and it seems like the issue is related to the primer parsing.

(gdb) r trim -i test.bam -m 30
Starting program: /home/nate/miniconda3/envs/eureka/bin/ivar trim -i test.bam -m 30
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Dwarf Error: wrong version in compilation unit header (is 5, should be 2, 3, or 4) [in module /home/nate/miniconda3/envs/eureka/bin/../lib/libstdc++.so.6]
Dwarf Error: wrong version in compilation unit header (is 5, should be 2, 3, or 4) [in module /home/nate/miniconda3/envs/eureka/bin/../lib/libgcc_s.so.1]
Reading from test.bam
@HD     VN:1.6  SO:coordinate
@SQ     SN:AE003852     LN:2961182
@SQ     SN:AE003853     LN:1072319
@PG     ID:bwa  PN:bwa  VN:0.7.17-r1198-dirty   CL:bwa mem -M -t 8 resources/vc_reference.fasta /home/nate/analysis/2023.07.28_cholera/input/illumina/ERR976436_1.fastq.gz /home/nate/analysis/2023.07.28_cholera/input/illumina/ERR976436_2.fastq.gz
@PG     ID:samtools     PN:samtools     PP:bwa  VN:1.17 CL:samtools view -Sb -
@PG     ID:samtools.1   PN:samtools     PP:samtools     VN:1.17 CL:samtools sort -
@PG     ID:samtools.2   PN:samtools     PP:samtools.1   VN:1.17 CL:samtools addreplacerg -r ID:ERR976436 -o intermediates/illumina/merged_aligned_bams/ERR976436.sorted.bam -
@RG     ID:ERR976436
@PG     ID:ivar-trim    PN:ivar VN:1.4.2        CL:/home/nate/miniconda3/envs/eureka/bin/ivar trim -i test.bam -m 30

Program received signal SIGSEGV, Segmentation fault.
0x0000555555572bc0 in primer::get_start() const ()
(gdb) where
#0  0x0000555555572bc0 in primer::get_start() const ()
#1  0x000055555556b5ae in binary_search(std::vector<primer, std::allocator<primer> >&, unsigned int, int, int) ()
#2  0x000055555556bd7d in get_overlapping_primers(bam1_t*, std::vector<primer, std::allocator<primer> >&, std::vector<primer, std::allocator<primer> >&) ()
#3  0x000055555556c907 in trim_bam_qual_primer(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, unsigned char, unsigned char, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, bool, int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, int) ()
#4  0x000055555555eb6d in main ()

• Edited to include the full stacktrace.

[cmaceves]

okay thanks for providing that. we're actually pushing a change to the way we handle this portion of the code anyways - it's passed testing and just waiting review