Closed ASLeonard closed 2 years ago
Thank you! Is it possible to share me with your data? I don't see the crash on my data. I had a look at code and recent changes but it is not immediately clear to me what could go wrong. When running minigraph, you may use
make asan=1
minigraph --dbg-kalloc --dbg-qname -t1
asan=1
and --dbg-kalloc
helps to expose memory bugs. --dbg-qname
prints query name. -t1
uses one thread. With these settings, you may be able to catch the read that breaks minigraph.
BTW, the current github HEAD has features backported from minimap2-2.24.
The kalloc flag should be --no-kalloc
, but the output was
QR f2b6a9cc-eb94-4075-8db2-f6ff580557e4 0 91405
QR 48d7d91a-eeb5-4163-a6dc-931e631f4a5c 1 11718
minigraph: lchain.c:363: mg_lchain_rmq: Assertion `max_j < 0 || (a[max_j].x < a[i].x && (int32_t)a[max_j].y < (int32_t)a[i].y)' failed.
Aborted
The gfa and reads should be accessible here.
Thanks a lot for this example. I believe I have fixed it.
Yep that fixed it, runs smoothly now. Thanks!
I was mapping a subset of nanopore reads to a subset of a gfa, and everything worked fine under my previous minigraph version (0.15-r426) but then repeatedly failed an assertion in the latest version (0.15-r434-dirty) from the same command
minigraph -t 2 -xlr --vc unitigs.gfa nanopore.fq.gz
error was
Same code segfaults at 011f4a2, and crashes at 94289c8 with the following
So the assertion error seems to appear at 0c9086b.