Reference Chimera checking. about vsearch HOT 12 CLOSED

I have the same problem on my Linux box. It seems to be a library problem. A quick gdb shows:

(gdb) run --uchime_ref vderep.fsa  --db refs.fsa --chimeras chimeras.fasta --nonchimeras non_chimeras.fasta --uchimeout derep.uchime --abskew 2
Starting program: /usr/bin/vsearch --uchime_ref vderep.fsa  --db refs.fsa --chimeras chimeras.fasta --nonchimeras non_chimeras.fasta --uchimeout derep.uchime --abskew 2
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
vsearch v1.0.5_linux_x86_64, 15.6GB RAM, 4 cores
https://github.com/torognes/vsearch

Reading file refs.fsa 100%  
620 nt in 2 seqs, min 240, max 380, avg 310
Indexing sequences 100% 
Counting unique k-mers 100% 
Creating index of unique k-mers 100% 
Detecting chimeras 0%[New Thread 0x7ffff6fb2700 (LWP 16544)]
[New Thread 0x7ffff67b1700 (LWP 16545)]
[New Thread 0x7ffff5fb0700 (LWP 16546)]
[New Thread 0x7ffff57af700 (LWP 16547)]
Detecting chimeras 0%*** Error in `/usr/bin/vsearch': realloc(): invalid next size: 0x00007fffec024780 ***

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff5fb0700 (LWP 16546)]
0x00007ffff7029107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.

I'll dig deeper into the stack tomorrow morning.

from vsearch.

Ok thanks!

from vsearch.

Hi Julia and Frederic,
if you provide me a set of example input files where the problem occurs, I could try to debug/fix the problem now.
tomas

from vsearch.

I can also look into it! :) I am unable to reproduce any of these problems, but I do not have database you are using nor all the query sequences. It seems like a memory allocation/deallocation bug in VSEARCH.

VSEARCH should handle both the wrapped and unwrapped input files. I do not understand why you get an error with the input file in your second try, Julia. The problem might be further down in your query file. I do not think the two problems are related.

I'll implement the --log option soon.

from vsearch.

Julia: Thanks for reporting this bug and sorry for the problems caused.

from vsearch.

Julia: I found your testing_vsearch repo and cloned it. I got the same error. Looking into it...

from vsearch.

Ok great! That was fast.

from vsearch.

I believe I have found and removed the bug. It allocated insufficient memory for the alignment sequences. Fixed now in VSEARCH 1.0.6 just released. I hope this fixes your problems. Please report back if it works or not. Thanks.

from vsearch.

Great fixed! Thanks for such a quick response! My test set works perfectly now.

Unfortunately I now getting an illegal header line error: Fatal error: Illegal header line in query fasta file from some header in my fasta file. I will try to track down what it giving the error and see if it warrants another issue or perhaps it is something I should fix in my headers. The joys of having used different sequencing facilities. 😬

from vsearch.

The problem with the header line might also be a bug in vsearch. It should have reported the line number so that it would be easier to track down the problem.

Do you have some particularly long lines in your fasta file? That could be the problem.

from vsearch.

Ok my bad, I was mistakenly using the fasta file I edited to have no line wrapping (after using vseach's derep_fulllength). vsearch did not report the line number of any problems.

Using the correct, unadultered output from derep_fulllength the uchime_ref is now working!

from vsearch.

Version 1.0.6 works correctly for me too. Sorry for not spotting that during the test phase.

from vsearch.