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

[Emilio Pozuelo Monfort]

On 12/12/16 22:19, Santiago Vila wrote:
> 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?

I need the full log. Run valgrind like this:

valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=20 --log-file=vgdump.txt .libs/check_data_proxy

And attach vgdump.txt

Thanks,
Emilio