search

lh3 / miniasm

Ultrafast de novo assembly for long noisy reads (though having no consensus step)
MIT License
299 stars 68 forks source link

Segmentation fault at step 1 #19

Open LeandroRitter opened 7 years ago

LeandroRitter commented 7 years ago

Hi Heng,

miniasm throws the following segmentation fault error already during step 1: [M::main] ===> Step 1: reading read mappings <=== /var/spool/slurmd/job9221389/slurm_script: line 26: 3636 Segmentation fault (core dumped) miniasm -f $FASTQ minimap_GRW_reads.paf.gz > miniasm_GRW_contings.gfa

I successfully ran minimap and got minimap_GRW_reads.paf.gz file. I allocated 128GB of RAM and using a profiler script checked that the RAM consumption was never above 80GB including the moment of crush. Could you please advise me on how to fix it? Thanks!

Best, Nikolay

chjp commented 7 years ago

I have the same errors with the test data set miniasm/miniasm -f reads.fq reads.paf.gz > reads.gfa [M::main] ===> Step 1: reading read mappings <=== Segmentation fault (core dumped)

mictadlo commented 7 years ago

Me too https://github.com/isovic/racon/issues/22#issuecomment-285914567

ebioman commented 7 years ago

Hello I am having a similar issue. I was mapping data with minimap (0.2.r124.dirty) and tried next to assemble. The mapping file size is 457 GB and the machine has > 500GB RAM. Using miniasm (0.2.r137.dirty) it gives a segmentation fault in step 1. I updated miniasm (0.2.r159.dirty) but still got the same core dump. This time I monitored as well closely the RAM consumption and it did not exceed 50% of the RAM at crush-time.

ebioman commented 7 years ago

Hi No real fix but work-around which was acceptable in my case:

miniasm -Rc2 -f MyReads.fastq.gz MyAlignments.paf.gz > MyAssembly.gfa

This filters contained reads first, which reduced the RAM usage a lot - takes a moment though.