Skip to content
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

Segmentation fault (core dumped) #5

Closed
Hannah1746 opened this issue Oct 14, 2021 · 3 comments
Closed

Segmentation fault (core dumped) #5

Hannah1746 opened this issue Oct 14, 2021 · 3 comments
Labels
bug Something isn't working

Comments

@Hannah1746
Copy link

I am trying to use methpipe and can't seem to get it to work for me.

I first run:
abismalidx FINAL_MX_HiC_50CHRs_rn.fa MX.abismalidx

This produces an index file that is 2.7G from my 2.3G genome

Then I run:
abismal -i MX.abismalidx -o MX_gill.sam MX_gill_output.fastq
but I get this core dumped error so I tried:
abismal -g FINAL_MX_HiC_50CHRs_rn.fa -o MX_gill.sam MX_gill.fastq
I get the same error on this too.

I am using Nanopore data so my fastq are singled end and are all cated together.

@guilhermesena1
Copy link
Collaborator

Hello,

Thank you so much for reporting this issue. Abismal was developed as a short read mapper for bisulfite sequencing reads, so it is not the appropriate tool for nanopore reads.

That said, the program should not be returning a segfault on a long read, but rather it should fail gracefully stating that the read is too long to be mapped. I tried on my end mapping some simulated reads of large size but couldn't reproduce the error. I suspect you got a segfault because you got a hit near the end of the genome and the alignment spanned way past beyond the genome end. This can be handled easily on short reads but less so on long reads.

I will be pushing a "fix" that requires a maximum read length and stops mapping if any read goes above this cut-off. Apologies for the inconvenience!

@guilhermesena1 guilhermesena1 added the bug Something isn't working label Oct 27, 2021
@guilhermesena1
Copy link
Collaborator

Hello,

Just following up on this. We extended the maximum read length for abismal to ~1 million reads on commit 9c93354 (currently abismal can only safely map reads of size > 1024) . This requires rebuilding the index. If any read of length >1 million is passed, the program will fail stating that a read that is too long is being passed.

This will possibly solve your issue if your read lengths are <1m. If you are still having problems, we'd appreciate if you could could provide a small test case in which we can reproduce the issue on our end. If you're not comfortable publicly sharing data you can always reach out by e-mail (desenabr@usc.edu)

@guilhermesena1
Copy link
Collaborator

closing this issue for now (this was incorporated on 2.0.0) but feel free to reopen if this problem resurfaces.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants