Re: [Valgrind-users] valgrind: Heap block lo/hi size mismatch when trying to debug a C++ program running inside Docker container

[Philippe W. <phi...@sk...>]

On Tue, 2019-11-12 at 20:18 -0800, Karthik Jayaraman wrote:
> 
> Thread 47: status = VgTs_Runnable (lwpid 1861)
> ==1747==    at 0x4C2922D: free (vg_replace_malloc.c:540)
> ==1747==    by 0x9A7CB7B: __libc_freeres (in /usr/lib64/libc-2.17.so)
> ==1747==    by 0x4A24739: _vgnU_freeres (vg_preloaded.c:77)
> 
> client 
> stack range: ??????? client SP: 0x289569C8
> 
> valgrind 
> stack range: [0x1009516000 0x1009615FFF] top usage: 5064 of 1048576
> 
> But the interesting fact is, it works wonderfully well when same binary is running outside the container (on a VM). If my source binary has a memory link (as per Valgrind FAQs) I am puzzled as to why I am not encountering the issue when not running in a container. 

You are using the massif tool. Massif does not detect leaks or errors,
it rather produces a report about the memory used (evolution, peak, ...).

The above seems to be a crash at the time your program terminates,
as the glibc __libc_freeres is called by valgrind function _vgnU_freeres
at exit.

If your program crashes at exit in __libc_freeres, it is recommended
to use --run-libc-freeres=no: the user manual indicates to use this
for buggy glibc. See user manual for more details.

The fact that it crashes inside a docker and not in another environment
might be explained by different glibc version or (as John said) because
of another layout of the memory.

Philippe