Strobealign v0.15-v0.16 fail with seg fault, previous versions do not

[tprodanov]

With the following input files:
haplotypes.fa.gz
reads.fq.gz

and command

strobealign -M 796 -N 796 -R 8 -k 15 --eqx -r 150 -t 8 -o out.sam haplotypes.fa.gz reads.fq.gz

I get the following stderr

This is strobealign 0.16.1
Time reading reference: 0.03 s
Reference size: 4.02 Mbp (199 contigs; largest: 0.02 Mbp)
Using multi-context seeds: no
Indexing ...
  Time counting seeds: 0.02 s
  Time generating seeds: 0.04 s
  Time sorting seeds: 0.03 s
  Time generating hash table index: 0.01 s
Total time indexing: 0.10 s
Processing single-end reads using 8 threads
free(): invalid pointerreads @   551.86 us/read
zsh: IOT instruction (core dumped)

Similar error appears in strobealign 0.15, but not in 0.14 or 0.13, error can be replicated on different machines.

Thank you in advance, Timofey

[marcelm]

Strange, I cannot reproduce this here. Before doing more tests, can you say how you installed strobealign? Maybe some info about the machine you are running it on? (Operating system, CPU)

[tprodanov]

Strange! Right now I tested on Arch linux, x64 architecture, 12 processor Intel Core i7, but it also fails on a Debian server. I installed through conda, specifically I can reproduce under conda create --name stro16 strobealign=0.16.1 samtools. I had some errors during compilation from source, but can try to dig through that if it helps

[marcelm]

I was finally able to reproduce the problem by setting the MALLOC_CHECK_ environment variable to 4. Do you have that set? If so, which value? Until we have fixed this, you can set MALLOC_CHECK_ to a value less than 4 before running strobealign, as in

MALLOC_CHECK_=0 strobealign -M 796 -N 796 -R 8 -k 15 --eqx -r 150 -t 8 -o out.sam haplotypes.fa.gz reads.fq.gz

[tprodanov]

I actually had it unset, and it does not look like MALLOC_CHECK_=0 helps. But good that you could reproduce the error at least with some conditions!

[marcelm]

We’ve just released version 0.17.0 of strobealign, can you test with that one? Note that the meaning of the -R command-line argument has changed in that version and the simplest way to deal with it is probably to just remove it from your commandline.

I looked into this further a couple of days ago and noticed that things are weirder than I thought. It seems MALLOC_CHECK_ doesn’t have anything to do with the crash, it is just that the error is triggered sometimes and it happened to occur when I tested with MALLOC_CHECK_. (Actually, only the values 0-3 have any meaning for MALLOC_CHECK_, so it was a bit weird that setting it to 4 did anything.)

So the only way I can trigger this is by repeatedly running your command in a loop and after 100 iterations or so, I get a segmentation violation. I assume the problem still exists in 0.17.0 but don’t have time to test right now. We will investigate further if it does.

[tprodanov]

Hi, thank you for looking into that! Actually without -R I don't get the error in both v0.16 and v0.17. Maybe it can still appear in the new version, but only in some specific cases. I'll share some if I ever come across them