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
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
