torognes
commented
5 years ago I see similar problems when I run it with the same input in valgrind.
Closed frederic-mahe closed 5 years ago
torognes
commented
5 years ago I see similar problems when I run it with the same input in valgrind.
frederic-mahe
commented
5 years ago I confirm:
valgrind ./swarm -f -o /dev/null -l /dev/null <(printf ">s1_10\nAA\n>s2_1\nCC\n")
==31554== Memcheck, a memory error detector
==31554== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==31554== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==31554== Command: ./swarm -f -o /dev/null /dev/fd/63 -l /dev/null
==31554==
==31554== Thread 2:
==31554== Invalid write of size 2
==31554== at 0x4C3269B: memmove (vg_replace_strmem.c:1252)
==31554== by 0x117A3D: generate_variant_sequence (variants.cc:79)
==31554== by 0x117A3D: check_heavy_var (algod1.cc:367)
==31554== by 0x117A3D: check_heavy_thread(long) (algod1.cc:402)
==31554== by 0x117BCB: ThreadRunner::worker(void*) (threads.h:57)
==31554== by 0x4E3F493: start_thread (pthread_create.c:333)
==31554== by 0x59DAACE: clone (clone.S:97)
==31554== Address 0x5e37334 is 0 bytes after a block of size 4 alloc'd
==31554== at 0x4C2DF16: memalign (vg_replace_malloc.c:857)
==31554== by 0x4C2E021: posix_memalign (vg_replace_malloc.c:1020)
==31554== by 0x1173F0: xmalloc (util.cc:95)
==31554== by 0x1173F0: check_heavy_thread(long) (algod1.cc:390)
==31554== by 0x117BCB: ThreadRunner::worker(void*) (threads.h:57)
==31554== by 0x4E3F493: start_thread (pthread_create.c:333)
==31554== by 0x59DAACE: clone (clone.S:97)
==31554==
==31554== Invalid write of size 8
==31554== at 0x117A66: nt_set (variants.cc:33)
==31554== by 0x117A66: generate_variant_sequence (variants.cc:80)
==31554== by 0x117A66: check_heavy_var (algod1.cc:367)
==31554== by 0x117A66: check_heavy_thread(long) (algod1.cc:402)
==31554== by 0x117BCB: ThreadRunner::worker(void*) (threads.h:57)
==31554== by 0x4E3F493: start_thread (pthread_create.c:333)
==31554== by 0x59DAACE: clone (clone.S:97)
==31554== Address 0x5e37330 is 0 bytes inside a block of size 4 alloc'd
==31554== at 0x4C2DF16: memalign (vg_replace_malloc.c:857)
==31554== by 0x4C2E021: posix_memalign (vg_replace_malloc.c:1020)
==31554== by 0x1173F0: xmalloc (util.cc:95)
==31554== by 0x1173F0: check_heavy_thread(long) (algod1.cc:390)
==31554== by 0x117BCB: ThreadRunner::worker(void*) (threads.h:57)
==31554== by 0x4E3F493: start_thread (pthread_create.c:333)
==31554== by 0x59DAACE: clone (clone.S:97)
==31554==
==31554==
==31554== HEAP SUMMARY:
==31554== in use at exit: 552 bytes in 1 blocks
==31554== total heap usage: 40 allocs, 39 frees, 5,925,248 bytes allocated
==31554==
==31554== LEAK SUMMARY:
==31554== definitely lost: 0 bytes in 0 blocks
==31554== indirectly lost: 0 bytes in 0 blocks
==31554== possibly lost: 0 bytes in 0 blocks
==31554== still reachable: 552 bytes in 1 blocks
==31554== suppressed: 0 bytes in 0 blocks
==31554== Rerun with --leak-check=full to see details of leaked memory
==31554==
==31554== For counts of detected and suppressed errors, rerun with: -v
==31554== ERROR SUMMARY: 10 errors from 2 contexts (suppressed: 0 from 0)Also, note the difference when using the --log option or not (no --fastidious option):
valgrind ./swarm -o /dev/null <(printf ">s1_10\nAA\n>s2_1\nCC\n") -l /dev/null
==2084== HEAP SUMMARY:
==2084== in use at exit: 552 bytes in 1 blocks
==2084== total heap usage: 28 allocs, 27 frees, 5,399,504 bytes allocated
valgrind ./swarm -o /dev/null <(printf ">s1_10\nAA\n>s2_1\nCC\n")
==2094== HEAP SUMMARY:
==2094== in use at exit: 0 bytes in 0 blocks
==2094== total heap usage: 26 allocs, 26 frees, 5,394,856 bytes allocated
==2094==
==2094== All heap blocks were freed -- no leaks are possibleThere seems to be a small memory leak when using the --log option (1 allocation is not freed).
torognes
commented
5 years ago The initial problem was caused by an incorrect memory allocation for the variant sequences. For short sequences, when no sequence was longer than 6 bp, the amount allocated was too little. For longer sequences the amount was actually closer to 4x too much. Fixed now in commit 996e052d7f9bc963cd442161f29bd50ad35b2327.
frederic-mahe
commented
5 years ago I've run address sanitizer tests and fuzzing on swarm 2 with the fastidious option without any problem, so I assume that issue concerned only swarm 3.
Is it possible to get rid of the unfreed-allocation reported by valgrind when using --log?
torognes
commented
5 years ago Yes, the problem only applies to Swarm 3 with the fastidious option. The memory allocation for some temporary variant sequences was not adjusted after changing to 2-bit representation. The memory needs were actually reduced to one fourth, but they needed padding to 8 bytes. The overall total memory needs are not changed.
Regarding the lost memory with log file: The error is located and will be fixed in both branches in a moment. I just forgot to close the log file at the end of the program. Applies to all versions.
torognes
commented
5 years ago Log file problem fixed in commit 6edcf8eff09da51388e8c4c633da82621eeb5554.
Thanks for spotting these bugs!
when compiling swarm 3 with address sanitizer (see issue #120), a buffer-overflow is detected but it the error log is not very clear to me (see below). It could be an error in a shared-library.
error message is: