Tests crash
pb-cdunn opened this issue · comments
I have random failures with the faitest part of test/all. (When I run it repeatedly, sometimes is passes, sometimes it fails.) Same with vcftest, though less often.
#0 0x0000000000405ad7 in rawAlloc_yn9c8RLaS8vgVBeMBfmkdUg (a=0x6ad600 <gch_IcYaEuuWivYAS86vFMTS3Q+96>, requestedSize=65)
at /mnt/software/n/nim/0.17.2/lib/system/alloc.nim:561
#1 0x000000000040bc5c in rawNewObj_QBPo5VW2O56Eeh8hPbQ7Pg (typ=0x6afa00 <strDesc_D0UzA4zsDu5tgpJQ9a9clXPg>, size=49,
gch=0x6ad5a0 <gch_IcYaEuuWivYAS86vFMTS3Q>) at /mnt/software/n/nim/0.17.2/lib/system/gc.nim:466
#2 0x0000000000407199 in newObj (typ=0x6afa00 <strDesc_D0UzA4zsDu5tgpJQ9a9clXPg>, size=49)
at /mnt/software/n/nim/0.17.2/lib/system/gc.nim:495
#3 0x0000000000407f76 in rawNewString (space=32) at /mnt/software/n/nim/0.17.2/lib/system/sysstr.nim:66
#4 0x000000000040826c in nimIntToStr (x=32) at /mnt/software/n/nim/0.17.2/lib/system/sysstr.nim:293
#5 0x00000000004703a4 in setForegroundColor_Tw7yxMupneOmAicqiYt3NA (f=0x2aaaab79a400 <_IO_2_1_stdout_>, fg=32 ' ',
bright=0 '\000') at /mnt/software/n/nim/0.17.2/lib/pure/terminal.nim:531
#6 0x000000000044eddf in testEnded_AsoOYSa1sGgPTBsUoT9cxsw (formatter=0x2aaaaaafc048,
testResult=0x6be150 <testResult_YxIndn6uRV6zIf6okXYQIw_4>) at /mnt/software/n/nim/0.17.2/lib/pure/terminal.nim:620
#7 0x0000000000401e54 in testEnded_azSnnJ3hAiHHuUdLzViJlw (formatter=0x2aaaaaafc048,
testResult=0x6be150 <testResult_YxIndn6uRV6zIf6okXYQIw_4>) at /mnt/software/n/nim/0.17.2/lib/pure/unittest.nim:137
#8 0x00000000004509c1 in testEnded_xoIS1BdhYWQ6hhMP22XXiw (testResult=0x6be150 <testResult_YxIndn6uRV6zIf6okXYQIw_4>)
at /mnt/software/n/nim/0.17.2/lib/pure/unittest.nim:328
#9 0x000000000043c142 in hts_bgzftestInit000 () at /mnt/software/n/nim/0.17.2/lib/pure/unittest.nim:425
#10 0x0000000000402130 in PreMainInner () at /mnt/software/n/nim/0.17.2/lib/system.nim:2861
#11 0x0000000000402168 in PreMain () at /mnt/software/n/nim/0.17.2/lib/system.nim:2872
#12 0x0000000000402182 in NimMain () at /mnt/software/n/nim/0.17.2/lib/system.nim:2884
#13 0x00000000004021d5 in main (argc=1, args=0x7fffffffe068, env=0x7fffffffe078)
at /mnt/software/n/nim/0.17.2/lib/system.nim:2894
I haven't seen it fail on its own. I have to include at least a couple tests before it:
import cigartest, bgzftest, faitest
[Suite] flag cigar-suite
[OK] test op
[OK] ref coverage
[Suite] bgzf-suite
[OK] test-write
[OK] test-read
[OK] write-with-index
Segmentation fault
I use nim-0.17.2 and htslib-1.6. I linked statically with htslib.
I think this is a bug in the testing framework in nim. I see it periodically but I can never recreate in real code. We've run mosdepth 10's of thousands of times, and each of those writes multiple bgzf files and never get a failure.
how did you link statically?
I ran valgrind on tests/all, and I found some possible problems:
==5486== Use of uninitialised value of size 8
==5486== at 0x459A6A: ref_coverage_YBLv47zweGLEtZG2KmYifw (cigar.nim:100)
==5486== by 0x4264C7: hts_cigartestInit000 (cigartest.nim:23)
==5486== by 0x40223F: PreMainInner (system.nim:2844)
==5486== by 0x40229B: PreMain (system.nim:2862)
==5486== by 0x4022B7: NimMain (system.nim:2874)
==5486== by 0x40230B: main (system.nim:2884)
==5486==
==5486== Use of uninitialised value of size 8
==5486== at 0x459174: X5BX5D__Wj0nQaHHpbJA69bFJgqE2BQbam (cigar.nim:51)
==5486== by 0x459A88: ref_coverage_YBLv47zweGLEtZG2KmYifw (cigar.nim:100)
==5486== by 0x4264C7: hts_cigartestInit000 (cigartest.nim:23)
==5486== by 0x40223F: PreMainInner (system.nim:2844)
==5486== by 0x40229B: PreMain (system.nim:2862)
==5486== by 0x4022B7: NimMain (system.nim:2874)
==5486== by 0x40230B: main (system.nim:2884)
18 test "ref coverage":
19 var b:hts.Bam
20 open(b, "tests/HG02002.bam")
21 for rec in b:
22 if rec.flag.unmapped: continue
23 var pieces = rec.cigar.ref_coverage(ipos=rec.start)I think rec.cigar is not fully initialized there. I hope that helps.
How did you link statically?
Actually, I don't know.
Hint: gcc -o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/all /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/hts_all.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/stdlib_system.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/hts_cigartest.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/hts_faitest.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/stdlib_unittest.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/stdlib_macros.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/stdlib_strutils.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/stdlib_streams.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/stdlib_times.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/stdlib_sets.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/stdlib_parseutils.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/stdlib_math.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/stdlib_algorithm.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/stdlib_hashes.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/stdlib_os.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/stdlib_posix.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/stdlib_ospaths.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/stdlib_terminal.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/stdlib_termios.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/hts_bam.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/hts_hts_concat.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/hts_simpleoption.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/stdlib_typetraits.o /home/UNIXHOME/cdunn/repo/gh/hts-nim/tests/nimcache/hts_fai.o -lm -lrt -ldl [Exec]
I don't see where that links with htslib. It's definitely not dynamically linked:
$ ldd tests/all
linux-vdso.so.1 => (0x00007ffe63752000)
libm.so.6 => /lib64/libm.so.6 (0x00002ac4332ee000)
librt.so.1 => /lib64/librt.so.1 (0x00002ac4335f1000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002ac4337f9000)
libc.so.6 => /lib64/libc.so.6 (0x00002ac4339fd000)
/lib64/ld-linux-x86-64.so.2 (0x00005574d0019000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002ac433dc1000)
can you try with nim 0.18.XX ? I just did:
for i in $(seq 200); do ./tests/all || break; done
and got no problems. but got a break nearly immediately with 0.17.2
I have to install 0.18.
I'll update this ticket when I do.
if you use choosenim
then it's simply: choosenim 0.17.2 or choosenim 0.18.0.
We have an older glibc, so I have to do something special to install. (Long story.)
* https://github.com/nim-lang/Nim/issues/1734
* https://forum.nim-lang.org/t/1972
* https://github.com/nim-lang/Nim/issues/3138
Not sure if that's solved yet. (Araq would have to update csources.)
ouch. yeah, that's a pain. can you setup your own gcc via (bio)conda and use that?
I see you probably have more experience in nim than I do! I hadn't seen your stuff. Would be great to join forces.
Would be great to join forces.
Yes! When I get this working, I will gladly drop my htslib-wrapping work. What I need the most is a subset of networkx, for graph libraries.
Just sent you an invite for bio-nim. If you want to host hts-nim there, I'd even make you an owner. Otherwise, we'll just updated our fork now and then.
I joined. I'm not opposed to moving, but don't want to do it now as it just came out. If it gains traction and contributors then the bio-nim namespace would be nice.
With nim-0.18.0, the cigar.nim valgrind warnings are gone. (There are still tons in Nim alloc.nim, but that's because of Nim's memory-management.) And the tests never fail. Excellent!
Closing.
What versions of htslib does this work with? I had to do some special if-wrapping for older htslib.
1.6+ for sure. maybe 1.5+
The biggest annoyance was new return values on old functions. In C, those funcs are still binary-compatible, but in Nim you have to "discard" or use the return values.
I don't think you need to worry about 1.5 though. You're lucky you started with 1.6!