Closed frederic-mahe closed 5 years ago
I see similar problems when I run it with the same input in valgrind.
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 possible
There seems to be a small memory leak when using the --log
option (1 allocation is not freed).
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.
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
?
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.
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: