Closed mmokrejs closed 5 years ago
brianwalenz
commented
5 years ago Awesome, thanks for the stack trace.
It's generating a diagnostic report on how useful the overlaps look for assembly. The report isn't used by Canu, and so the crash here is ignored and Canu continues running.
For what it's worth, its crashing when computing statistics on overlap depth for reads with low coverage.
mmokrejs
commented
5 years ago Thank you, yes it seemed it is not really needed. If you need the tt_16D1C3L12.ovlStore.per-read.log file or some other please let me know. Or I can test some patches.
brianwalenz
commented
5 years ago Should be fixed, but I wasn't able to reproduce exactly the failure. I'd appreciate testing with the github latest code; ovStoreStats won't interfere with any existing canu run.
mmokrejs
commented
5 years ago Unfortunately it did not help:
$ gdb /scratch/work/project/bio/canu/Linux-amd64-uv1_dbg/bin/ovStoreStats /scratch/work/project/bio/open-13-42/assemblies/canu/tt_16D1C3L12__OxNano_passed_and_failed__assembly/unitigging/core.106887
GNU gdb (Gentoo 8.2 p1) 8.2
...
Reading symbols from /scratch/work/project/bio/canu/Linux-amd64-uv1_dbg/bin/ovStoreStats...done.
[New LWP 106887]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/apps/gentoo/lib64/libthread_db.so.1".
Core was generated by `ovStoreStats -C 4 -S ../tt_16D1C3L12.seqStore -O ./tt_16D1C3L12.ovlStore -o ./t'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007ffff7dc76cc in histogramStatistics::finalizeData (this=0x7ffff8017960) at utility/stddev.H:486
486 maddata[mad] += _histogram[ii];
(gdb) where
#0 0x00007ffff7dc76cc in histogramStatistics::finalizeData (this=0x7ffff8017960) at utility/stddev.H:486
#1 0x00007ffff7dc5623 in main (argc=9, argv=0x7fffffffda38) at stores/ovStoreStats.C:544
(gdb) bt full
#0 0x00007ffff7dc76cc in histogramStatistics::finalizeData (this=0x7ffff8017960) at utility/stddev.H:486
mad = 6614635
ii = 0
maddata = 0x7ffff8017f60
#1 0x00007ffff7dc5623 in main (argc=9, argv=0x7fffffffda38) at stores/ovStoreStats.C:544
seqName = 0x7fffffffdd44 "../tt_16D1C3L12.seqStore"
ovlName = 0x7fffffffdd60 "./tt_16D1C3L12.ovlStore"
outPrefix = 0x7fffffffdd7b "./tt_16D1C3L12.ovlStore"
bgnID = 0
endID = 885412
ovlSelect = 255
ovlAtMost = 4095
ovlAtLeast = 0
expectedMean = 4
toFile = true
beVerbose = false
arg = 9
err = 0
seqStore = 0x7ffff8010d20
ovlStore = 0x7ffff8012f70
readNoOlaps = 0x7ffff8017300
readHole = 0x7ffff8017360
readHump = 0x7ffff80173c0
readNo5 = 0x7ffff8017420
readNo3 = 0x7ffff8017480
olapHole = 0x7ffff80174e0
olapHump = 0x7ffff8017540
olapNo5 = 0x7ffff80175a0
olapNo3 = 0x7ffff8017600
readLowCov = 0x7ffff8017660
readUnique = 0x7ffff80176c0
readRepeatCont = 0x7ffff8017720
readRepeatDove = 0x7ffff8017780
readSpanRepeat = 0x7ffff80177e0
readUniqRepeatCont = 0x7ffff8017840
readUniqRepeatDove = 0x7ffff80178a0
readUniqAnchor = 0x7ffff8017900
covrLowCov = 0x7ffff8017960
covrUnique = 0x7ffff80179c0
covrRepeatCont = 0x7ffff8017a20
covrRepeatDove = 0x7ffff8017a80
covrSpanRepeat = 0x7ffff8017ae0
covrUniqRepeatCont = 0x7ffff8017b40
covrUniqRepeatDove = 0x7ffff8017ba0
covrUniqAnchor = 0x7ffff8017c00
olapLowCov = 0x7ffff8017c60
olapUnique = 0x7ffff8017cc0
olapRepeatCont = 0x7ffff8017d20
olapRepeatDove = 0x7ffff8017d80
olapSpanRepeat = 0x7ffff8017de0
olapUniqRepeatCont = 0x7ffff8017e40
olapUniqRepeatDove = 0x7ffff8017ea0
olapUniqAnchor = 0x7ffff8017f00
LOGname = "./tt_16D1C3L12.ovlStore.per-read.log", '\000' <repeats 2996 times>...
LOG = 0x0
overlapsMax = 65536
overlaps = 0x7fff71348018
C = {static _spinr = {0x7ffff7df0c08 "[|]", 0x7ffff7df0c0c "[/]", 0x7ffff7df0c10 "[-]", 0x7ffff7df0c14 "[\\]"}, static _liner = <same as static member of an already seen type>, _count = 0, _draws = 0, _unit = 1,
_freq = 127, _startTime = 1549290819.8606889, _fmt = 0x7ffff7defa50 " %9.0f reads (%6.1f reads/sec)\r", _spin = false, _line = false, _enabled = false}
--Type <RET> for more, q to quit, c to continue without paging--
__PRETTY_FUNCTION__ = "int main(int, char**)"
nReads = 0
(gdb)If you give me some copy&paste commands I can execute them within the gdb session for you.
brianwalenz
commented
5 years ago OK, now I think I've got it fixed. Reopen if you happen to test and it fails.
mmokrejs
commented
5 years ago So I tested the 490b517a0..83c539e66 changes
$ make
Building for 'Linux' '3.10.0-957.5.1.el7.x86_64' as 'amd64' into '/scratch/work/project/bio/canu/Linux-amd64/{bin,obj}'.
Using '/apps/gentoo/usr/x86_64-pc-linux-gnu/gcc-bin/8.2.0/c++' version '8.2.0'.
Building snapshot v1.8 +125 changes (r9335 83c539e663be24be1eee22d5e2f9d974ba5344c9) (sync'd with guthub)
...The guthub is a typo somewhere?
Anyway, it seems to work now:
category reads % read length feature size or coverage analysis
---------------- ------- ------- ---------------------- ------------------------ --------------------
middle-missing 5345 0.80 12263.38 +- 10693.88 1240.07 +- 1578.59 (bad trimming)
middle-hump 2324 0.35 8991.05 +- 8870.64 703.47 +- 1211.24 (bad trimming)
no-5-prime 12330 1.84 12612.22 +- 11219.66 387.39 +- 841.17 (bad trimming)
no-3-prime 13043 1.95 12529.12 +- 11346.99 407.90 +- 857.84 (bad trimming)
low-coverage 3023 0.45 2188.10 +- 1391.91 1.00 +- 0.00 (easy to assemble, potential for lower quality consensus)
unique 65822 9.83 3914.31 +- 3471.64 3.94 +- 1.18 (easy to assemble, perfect, yay)
repeat-cont 245593 36.67 5393.85 +- 4924.16 1950.25 +- 3547.52 (potential for consensus errors, no impact on assembly)
repeat-dove 7069 1.06 14546.78 +- 11628.63 815.37 +- 1750.08 (hard to assemble, likely won't assemble correctly or even at all)
span-repeat 49299 7.36 13288.81 +- 9440.20 6585.27 +- 8265.17 (read spans a large repeat, usually easy to assemble)
uniq-repeat-cont 141887 21.19 8571.22 +- 6383.85 (should be uniquely placed, low potential for consensus errors, no impact on assembly)
uniq-repeat-dove 41936 6.26 18335.75 +- 12485.79 (will end contigs, potential to misassemble)
uniq-anchor 78616 11.74 14608.19 +- 10426.85 7364.40 +- 8674.17 (repeat read, with unique section, probable bad read)Thank you.
brianwalenz
commented
5 years ago Ha! I wish I could say I put that there on purpose, but...
Thanks for confirming it works!
Hi, I have only about 10x coverage for a 1.3Gb genome from MiniION R9.4. I tried some error-correction alone and here I tried to continue with assembly. Somehow, this step is crashing and it seems similar to https://github.com/marbl/canu/issues/1159:
I retried later to run just the crashing command but I am getting same error: