segmentation fault on klocate find

[ulduc]

Hi,

my colleague went on holidays leaving me with an error on klocate

klocate find -k 23 -f 1 hifiasm.fa ../ARNg/ARNg_1.fasta > test.bed

and this gives :

[M::bwa_idx_load_from_disk] read 0 ALT contigs Index load. Segmentation fault (core dumped)

It is on our cluster, it was compiled by myself from a git clone like in the readme.

Would there be a logical reason i didn't see ?

Thank you

[ldenti]

Hi, did it work on the example data?

Moreover, what kind of sequences the query fasta (../ARNg/ARNg_1.fasta) contains? Are 23-mers?

Can you please do a

head ../ARNg/ARNg_1.fasta

and send me the output?

Thanks, Luca

[ulduc]

here is the head you asked

ARNg_1 GTCAATAATTTCACGTGTACTGG

edit : i dont know about the examples, i'll try them myself i guess

[ldenti]

Is a > missing on the first line? With -f 1, klocate expects a well-formed fasta.

Try to add > to the entry header and try again.

[ulduc]

head ARNg_1.fasta

ARNg_1 GTCAATAATTTCACGTGTACTGG

well i'm sorry i didn't paste properly, it seems well formed

[ldenti]

oh, I see. The > is quoting the content.. Well, let me know if the example works

[ulduc]

Well, the example with the fastas gave me a fa.bed very fast very nice.

i would say it comes from the original fasta, the index worked well on it, i redid it myself just to be sure.

the query fasta is only 75Ko, i dont know what's wrong

Nicolas

[ulduc]

If i use my target with your kmer file, i get the same segmentation fault. Maybe it's my target fasta that is weird, being indexed is not a validation maybe

[ldenti]

You could also try to use the example target file and your kmer file (just to be sure).

Is there any sequence (strictly) shorter than 23bp in your target fasta? In case, can you send me the corresponding .fai (obtained with samtools faidx hifiasm.fa)?

[ulduc]

more hifiasm.bp.fa.fai hifiasmptg000001l 30513 31 60 61 hifiasmptg000002l 25987 31084 60 61 hifiasmptg000003l 16779 57536 60 61

here is the samtool faidx if it can help

[ulduc]

if it can help find the problem, i compiled this using i guess

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.4.0-1ubuntu1~20.04.1' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-9-Av3uEd/gcc-9-9.4.0/debian/tmp-nvptx/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)

[ldenti]

Well, I don't have any clue right now on the cause.. Would it be possible for you to share the target .fasta? It'll be much easier for me to troubleshoot the issue

[ulduc]

hifiasm_klocate.zip

here are the two files my colleague is using, i hope you can find something

Thank you and good luck !

Nicolas

[ldenti]

Hi, I think I solved it.. I forgot to manage kmers not occurring in the index.. Can you confirm that the input kmer cannot be found in the input target? I tried with:

grep -v "^>" hifiasm.bp.fa | tr -d "\n" | grep -o "GTCAATAATTTCACGTGTACTGG"
echo "GTCAATAATTTCACGTGTACTGG" | rev | tr ACGT TGCA
grep -v "^>" hifiasm.bp.fa | tr -d "\n" | grep -o "CCAGTACACGTGAAATTATTGAC"

Now it should be solved. Can you please check the new commit (9e1825f5783afdd350bf02888549a0985ad544e9)?

Let me know if it works on your data.

Luca