Re: [Valgrind-users] valgrind: Heap block lo/hi size mismatch when trying to debug a C++ program running inside Docker container
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
Re: [Valgrind-users] valgrind: Heap block lo/hi size mismatch when trying to debug a C++ program running inside Docker container
On 11/13/19 at 04:18 UTC, Karthik Jayaraman wrote: When trying to debug my C++ binary, I am running into the following issue. valgrind: m_mallocfree.c:307 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed. valgrind : Heap block lo/hi size mismatch: lo = 1, hi = 4294967295. This is probably caused by your program erroneously writing past the end of a heap block and corrupting heap metadata . If you fix any invalid writes reported by Memcheck, this assertion failure will probably go away . Please try that before reporting this as a bug. <> Which version of valgrind? (Run "valgrind --version".) Which hardware, operating system, and version? Which C++ compiler and version? Did memcheck report any invalid writes? Did you fix them? 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. If the operating system that runs inside the container does not layout the address space of valgrind identically to the address space of valgrind as laid out by the VM outside the container, then the results can differ. (There might be a bug in memcheck, too.) Re-run with "valgrind -v -v -v -d -d -d <>" to get more information. Copy+paste that info into an attachment of a bug report; see the Bug Reports link on the page http://valgrind.org . ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] valgrind: Heap block lo/hi size mismatch when trying to debug a C++ program running inside Docker container
When trying to debug my C++ binary, I am running into the following issue. valgrind: m_mallocfree.c:307 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed. valgrind : Heap block lo/hi size mismatch: lo = 1, hi = 4294967295. This is probably caused by your program erroneously writing past the end of a heap block and corrupting heap metadata . If you fix any invalid writes reported by Memcheck, this assertion failure will probably go away . Please try that before reporting this as a bug. host stacktrace : ==1747==at 0x58013284: ??? (in /usr/lib64/valgrind/massif-amd64-linux) ==1747==by 0x58013397: ??? (in /usr/lib64/valgrind/massif-amd64-linux) ==1747==by 0x58013531: ??? (in /usr/lib64/valgrind/massif-amd64-linux) ==1747==by 0x5801BD6D: ??? (in /usr/lib64/valgrind/massif-amd64-linux) ==1747==by 0x5800CDC1: ??? (in /usr/lib64/valgrind/massif-amd64-linux) ==1747==by 0x580614A7: ??? (in /usr/lib64/valgrind/massif-amd64-linux) ==1747==by 0x580737A7: ??? (in /usr/lib64/valgrind/massif-amd64-linux) ==1747==by 0x580738DC: ??? (in /usr/lib64/valgrind/massif-amd64-linux) ==1747==by 0x580C9561: ??? (in /usr/lib64/valgrind/massif-amd64-linux) ==1747==by 0x580C96AA: ??? (in /usr/lib64/valgrind/massif-amd64-linux) ==1747==by 0x580720CD: ??? (in /usr/lib64/valgrind/massif-amd64-linux) ==1747==by 0xDEADBEEFDEADBEEE: ??? ==1747==by 0xDEADBEEFDEADBEEE: ??? ==1747==by 0xDEADBEEFDEADBEEE: ??? sched status : running_tid =47 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. Any help appreciated. -Karthik ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
