-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory allocation crash #2
Comments
Hi Ryan, Thank you for developing this tool, it works great and is very accessible for even a non bioinformatician like me :).
or the alternative error message I received:
(note that flye was excluded because: ERROR: The input contain reads with duplicated IDs. Make sure all reads have unique IDs and restart. The first problematic ID was: 7bd66c9f-eabf-4c38-aab7-cda70857e95c I will ask our bioinformaticians if they know an easy fix for this (without Flye most assemblies are fully resolved, so it did not matter much to exclude this assembler). |
Excluding one assembler (e.g. Flye) is probably fine, as long as you're still getting to a fully resolved Autocycler assembly. But there may be something strange going on in your read processing if you have duplicate read IDs, and that might cause problems elsewhere (e.g. read alignment), so you may want to root out the problem! Regarding the memory crash, it occurred for you in the same part of Autocycler compress as it did for me, so very much looks like the same problem. Thanks for reporting it, and let me know if you have any issues with the gnu build. |
Our service provider provided us with bam files, I converted them to fastq with bedtools and compressed them with gzip. I am checking whether the conversion caused these issues or the bam files already had duplicate read IDs. edit: there were no duplicate IDs in the bam files, I used samtools instead of bedtools to convert, and that seems to have solved the issue. bedtools duplicated every read when converting to fastq Regarding the memory crash, using the glibc build solved the problem 👍 :
|
I encountered this curious crash when running Autocycler on an RHEL server:
It's strange for the following reasons:
indicatif
progress spinner, which is a very lightweight part of the code.I don't fully understand the problem, but the crash seems related to
indicatif
's use of a background thread (enable_steady_tick
), which interacts poorly with musl's stricter threading or memory allocation behaviour.In case anyone else runs into this problem, I've decided to also include a pre-built glibc-based binary of Autocycler in the releases. If you encounter this problem, using the glibc binary is a straightforward solution. If you're building Autocycler from source on Linux, it will default to using glibc, which avoids this problem.
I'm not sure if this is a rare issue unique to my server or a common problem affecting many users. If you also encounter this crash, please let me know. If it turns out to be widespread, I’ll consider a more robust solution, such as replacing
indicatif
with another progress spinner library.The text was updated successfully, but these errors were encountered: