Pre-Release 1.9.3 is unstable

[uludag]

I consistently get core dumps with Lambda Pre-Release 1.9.3 for large fastq files (compressed size ~ 2GB). Running Lambda with single thread does not help. Running with a small fastq file of 1000 reads do return successfully.

I get the segmentation faults after the following message is logged:

Loading Query Sequences and Ids...translating...

[h-2]

Thanks for your bug report! Can you make one of the files that cause this behaviour available to me somehow? (FTP, Dropbox...)

[uludag]

I don't own the fastq files, I could not share them, I will test them with the next Lambda release candidate when one made available.
I have tried building Lambda from the latest source following the instructions on your wiki but have not been successful.

[h-2]

I don't own the fastq files, I could not share them,

Hm, that makes it quite difficult for me to track down the problem. There is no chance of giving me access to any of the files? Doesn't have to be public access, you can also put it somewhere password protected and send me the password via e-mail ( hannes . hauswedell @ fu-berlin . de).

I will test them with the next Lambda release candidate when one made available.

Nothing has changed in this area in Lambda so I am quite sure the problem still exists.

I have tried building Lambda from the latest source following the instructions on your wiki but have not been successful.

What exactly have you tried and why did it not succeed? Can you open an additional issue for this so that I can have a look and improve the documentation? Thanks!

[uludag]

After finding Software Collections I'm now able to build Lambda on my desktop. However my first test with running lambda2 in gdb did not crash while translating the sequences.
I will talk to the owner of the data to learn whether I can share them.

[h-2]

I have also tried with a 4GB fastq file (compressed size) and had no problems 🤔

So it's not a general size issue, but likely related to the specific files.

[uludag]

It was my fault. I was not using cutadapt's --minimum-length option. BLAST warnings opened my eyes. There were empty sequences in my fastq file. Before Lambda I was using DIAMOND, it was ignoring empty sequences silently.

[h-2]

It was my fault. I was not using cutadapt's --minimum-length option. BLAST warnings opened my eyes. There were empty sequences in my fastq file. Before Lambda I was using DIAMOND, it was ignoring empty sequences silently.

Thanks for the report in any case! Even if the sequences are empty, Lambda shouldn't crash so I still need to fix the behaviour 😄