Bug#839444: libgda5: FTBFS: tests failures annotations:

[Santiago Vila]

On Mon, Dec 12, 2016 at 09:54:57PM +0100, Emilio Pozuelo Monfort wrote:

> Huh, this is crashing in libc's malloc().
> 
> Can you run the test under valgrind's memcheck? Maybe there's some memory
> corruption that would explain this.

Do you mean this?

valgrind the-test-that-we-want-to-debug

How do I run only the test that we want to debug?

(I got the previus backtrace by pure chance, after "ulimit -c unlimited"
and "make check").

Do I need any LD_LIBRARY_PATH or something?
Any command line arguments?

If I just do this:

valgrind tests/data-models/.libs/check_data_proxy

I get this:

==25068== Memcheck, a memory error detector
==25068== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==25068== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==25068== Command: tests/data-models/.libs/check_data_proxy
==25068== 
tests/data-models/.libs/check_data_proxy: error while loading shared libraries: libgda-5.0.so.4: cannot open shared object file: No such file or directory
==25068== Jump to the invalid address stated on the next line
==25068==    at 0x596: ???
==25068==    by 0x400F352: _dl_signal_error (dl-error.c:125)
==25068==    by 0x400DF05: _dl_map_object_deps (dl-deps.c:686)
==25068==    by 0x4002EF8: dl_main (rtld.c:1610)
==25068==    by 0x401766D: _dl_sysdep_start (dl-sysdep.c:249)
==25068==    by 0x4004D27: _dl_start_final (rtld.c:307)
==25068==    by 0x4004D27: _dl_start (rtld.c:413)
==25068==    by 0x4000CA7: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==25068==  Address 0x596 is not stack'd, malloc'd or (recently) free'd
==25068== 
==25068== 
==25068== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==25068==  Bad permissions for mapped region at address 0x596
==25068==    at 0x596: ???
==25068==    by 0x400F352: _dl_signal_error (dl-error.c:125)
==25068==    by 0x400DF05: _dl_map_object_deps (dl-deps.c:686)
==25068==    by 0x4002EF8: dl_main (rtld.c:1610)
==25068==    by 0x401766D: _dl_sysdep_start (dl-sysdep.c:249)
==25068==    by 0x4004D27: _dl_start_final (rtld.c:307)
==25068==    by 0x4004D27: _dl_start (rtld.c:413)
==25068==    by 0x4000CA7: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==25068== 
==25068== HEAP SUMMARY:
==25068==     in use at exit: 0 bytes in 0 blocks
==25068==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==25068== 
==25068== All heap blocks were freed -- no leaks are possible
==25068== 
==25068== For counts of detected and suppressed errors, rerun with: -v
==25068== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)


and because of the "error while loading shared libraries" part I'm
not sure this is exactly what should be done.


Well, I finally figured out (maybe).


export LD_LIBRARY_PATH=pwd/libgda/.libs
cd tests/data-models
valgrind .libs/check_data_proxy

and this is the valgrind report at the end:

==25768== 
==25768== HEAP SUMMARY:
==25768==     in use at exit: 1,730,127 bytes in 45,645 blocks
==25768==   total heap usage: 809,031 allocs, 763,386 frees, 736,853,843 bytes allocated
==25768== 
==25768== LEAK SUMMARY:
==25768==    definitely lost: 31,346 bytes in 253 blocks
==25768==    indirectly lost: 7,898 bytes in 241 blocks
==25768==      possibly lost: 2,638 bytes in 27 blocks
==25768==    still reachable: 1,558,413 bytes in 43,683 blocks
==25768==                       of which reachable via heuristic:
==25768==                         length64           : 440 bytes in 11 blocks
==25768==                         newarray           : 1,568 bytes in 18 blocks
==25768==         suppressed: 0 bytes in 0 blocks
==25768== Rerun with --leak-check=full to see details of leaked memory
==25768== 
==25768== For counts of detected and suppressed errors, rerun with: -v
==25768== ERROR SUMMARY: 40 errors from 3 contexts (suppressed: 0 from 0)

Is this what you need?

Thanks.