On Thu, Apr 30, 2020 at 07:17:50AM -0700, Matthew Fernandez wrote:
>
> Valgrind, in its default mode, checks for a variety of memory issues
> (use-after-free, write out-of bounds, …). You don’t need any special
> configure/build options, but you probably want to enable debug symbols
> (`export CFLAGS=-g; export CXXFLAGS=-g`). Then you can prefix the test you’re
> running with Valgrind: `valgrind ./src/clustalo -i
> debian/tests/biopython_testdata/f002 …`.
Running on mipsel:
(sid_mipsel-dchroot)tille@eller:~/clustalo$ valgrind src/clustalo -i
debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o
temp_test.aln --outfmt clustal --force
==15149== Memcheck, a memory error detector
==15149== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==15149== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==15149== Command: src/clustalo -i debian/tests/biopython_testdata/f002
--guidetree-out temp_test.dnd -o temp_test.aln --outfmt clustal --force
==15149==
==15149== Conditional jump or move depends on uninitialised value(s)
==15149== at 0x4007828: cached_fpabi_reject_phdr_p
(dl-machine-reject-phdr.h:57)
==15149== by 0x4007828: elf_machine_reject_phdr_p
(dl-machine-reject-phdr.h:217)
==15149== by 0x4008080: open_verify.constprop.0 (dl-load.c:1688)
==15149== by 0x4009D7C: _dl_map_object (dl-load.c:2181)
==15149== by 0x40011F8: map_doit (rtld.c:607)
==15149== by 0x401B2A8: _dl_catch_exception (dl-error-skeleton.c:196)
==15149== by 0x401B334: _dl_catch_error (dl-error-skeleton.c:215)
==15149== by 0x4001138: do_preload (rtld.c:778)
==15149== by 0x4002560: handle_preload_list (rtld.c:879)
==15149== by 0x4005B08: dl_main (rtld.c:1684)
==15149== by 0x401A094: _dl_sysdep_start (dl-sysdep.c:253)
==15149== by 0x400199C: _dl_start_final (rtld.c:447)
==15149== by 0x4001D44: _dl_start (rtld.c:539)
==15149==
==15149== Invalid read of size 1
==15149== at 0x486F558: ??? (in
/usr/lib/mipsel-linux-gnu/libargtable2.so.0.1.8)
==15149== by 0x486F5F0: ??? (in
/usr/lib/mipsel-linux-gnu/libargtable2.so.0.1.8)
==15149== Address 0x4d655c5 is 0 bytes after a block of size 37 alloc'd
==15149== at 0x484B89C: malloc (in
/usr/lib/mipsel-linux-gnu/valgrind/vgpreload_memcheck-mips32-linux.so)
==15149== by 0x126674: CkMalloc (util.c:83)
==15149== by 0x126864: CkStrdup (util.c:213)
==15149== by 0x1108F4: ConvertOldCmdline(int*, char***, int, char**)
(main.cpp:358)
==15149== by 0x10FCDC: main (main.cpp:467)
==15149==
==15149== Invalid read of size 4
==15149== at 0x1221B8: PairDistances (pair_dist.c:346)
==15149== by 0x114774: AlignmentOrder (clustal-omega.c:835)
==15149== by 0x115024: Align (clustal-omega.c:1221)
==15149== by 0x112EB4: MyMain (mymain.c:1192)
==15149== by 0x10FCF0: main (main.cpp:469)
==15149== Address 0xffff83b0 is not stack'd, malloc'd or (recently) free'd
==15149==
==15149==
==15149== Process terminating with default action of signal 10 (SIGBUS)
==15149== at 0x1221B8: PairDistances (pair_dist.c:346)
==15149== by 0x114774: AlignmentOrder (clustal-omega.c:835)
==15149== by 0x115024: Align (clustal-omega.c:1221)
==15149== by 0x112EB4: MyMain (mymain.c:1192)
==15149== by 0x10FCF0: main (main.cpp:469)
==15149==
==15149== HEAP SUMMARY:
==15149== in use at exit: 8,039 bytes in 34 blocks
==15149== total heap usage: 112 allocs, 78 frees, 77,811 bytes allocated
==15149==
==15149== LEAK SUMMARY:
==15149== definitely lost: 128 bytes in 2 blocks
==15149== indirectly lost: 0 bytes in 0 blocks
==15149== possibly lost: 0 bytes in 0 blocks
==15149== still reachable: 7,911 bytes in 32 blocks
==15149== suppressed: 0 bytes in 0 blocks
==15149== Rerun with --leak-check=full to see details of leaked memory
==15149==
==15149== Use --track-origins=yes to see where uninitialised values come from
==15149== For lists of detected and suppressed errors, rerun with: -s
==15149== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
Bus error
Is this different from your tests on amd64?
> > On the other hand: Is valgrind possibly able to uncover issues also
> > on any other architecture?
>
> You mean if we were to use Valgrind to debug this on e.g. x86? In my own
> experiments on amd64, both ASan and Valgrind found multiple issues in both
> Clustal Omega and its dependency, argtable2. However I don’t believe any of
> the remaining ones I was seeing after the last patches I sent you could be
> causing the mipsel bus error; they were all memory leaks.
Thanks again for your great support and the time you've spent.
Kind regards
Andreas.
--
http://fam-tille.de
