https://bugs.kde.org/show_bug.cgi?id=472346
Bug ID: 472346 Summary: False positive mismatched frees Classification: Developer tools Product: valgrind Version: 3.22 GIT Platform: Compiled Sources OS: Unspecified Status: REPORTED Severity: wishlist Priority: NOR Component: memcheck Assignee: jsew...@acm.org Reporter: pjfl...@wanadoo.fr Target Milestone: --- Some details. RHEL 7.9, GCC 5.3 home rolled. Debug exe but it dlopens a Here are a couple of cases that I see ==12389== Mismatched free() / delete / delete [] ==12389== at 0x63E3164: free (vg_replace_malloc.c:974) ==12389== by 0x1B4D75F5: __gnu_cxx::new_allocator ..snip ... ::deallocate ...snip... (new_allocator.h:110) ==12389== Address 0x27246130 is 0 bytes inside a block of size 88 alloc'd ==12389== at 0x63E0EF1: operator new(unsigned long) (vg_replace_malloc.c:472) ==12389== by 0x2514CCD: __gnu_cxx::new_allocator...snip...::allocate(unsigned long, void const*) (ext/new_allocator.h:104) The code for deallocate is // __p is not permitted to be a null pointer. void deallocate(pointer __p, size_type) { ::operator delete(__p); } The mangled last function in the callstack is _ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeISt4pairIKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt6vectorIS2_IS8_S8_ESaISB_EEEEE10deallocateEPSF_m which is deallocating a std::map<std::string, std::vector<std::pair<std::string,std::string> > > cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt6vectorIS2_IS8_S8_ESaISB_EEEEE10deallocateEPSF_m>: 925d6: 55 push %rbp 925d7: 48 89 e5 mov %rsp,%rbp 925da: 48 83 ec 20 sub $0x20,%rsp 925de: 48 89 7d f8 mov %rdi,-0x8(%rbp) 925e2: 48 89 75 f0 mov %rsi,-0x10(%rbp) 925e6: 48 89 55 e8 mov %rdx,-0x18(%rbp) 925ea: 48 8b 45 f0 mov -0x10(%rbp),%rax 925ee: 48 89 c7 mov %rax,%rdi 925f1: e8 6a 3c 9c 00 callq a56260 <_ZdlPv> 925f6: 90 nop 925f7: c9 leaveq 925f8: c3 retq There is something weird there. _ZdlPv in mangle-speak is _Z (C++) dl (delete) Pv (pointer to void). But Valgrind is redirecting this to free. Originally I thought that the ::operator delete(__p) was simply being inlined. A second error from the same testcase: ==31400== Mismatched free() / delete / delete [] ==31400== at 0x63E36C5: operator delete(void*) (vg_replace_malloc.c:1025) ==31400== by 0x2543553: ...snip... user code ==31400== Address 0x285f41d0 is 0 bytes inside a block of size 64 alloc'd ==31400== at 0x63E078B: malloc (vg_replace_malloc.c:431) ==31400== by 0x27E4E2F7: operator new(unsigned long) (new_op.cc:50) ==31400== by 0x2778CA2A: ...snip... user code This is definitely a Valgrind problem - operator delete is redirected but operator new isn't. I tried debugging this with vgdb, and putting a break on _Znwm and there were 4 sites. Need more tracing / debugging of redirs and symtab when that shared library gets dlopen'd and mmap'd. Now a second exe which generates huge numbers of errors on startup. These are for things like const set<string> options = { "option1", "option2"}; Temporary std::string objects get created for the options shich cause errors like ==31386== Mismatched free() / delete / delete [] ==31386== at 0x188D7164: free (vg_replace_malloc.c:974) ==31386== by 0x620C460: __static_initialization_and_destruction_0(int, int) (header.h:63) ==31386== by 0x621BE96: _GLOBAL__sub_I_source.cc (source.cc:12969) ==31386== by 0x163647CC: __libc_csu_init (in /path/to/exe) ==31386== by 0x20E9A4E4: (below main) (in /usr/lib64/libc-2.17.so) ==31386== Address 0x217dc590 is 0 bytes inside a block of size 37 alloc'd ==31386== at 0x188D61E7: operator new[](unsigned long) (vg_replace_malloc.c:714) ==31386== by 0x736C3DB: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) (basic_string.tcc:223) ==31386== by 0x1B24FA9E: _M_construct_aux<char const*> (basic_string.h:236) ==31386== by 0x1B24FA9E: _M_construct<char const*> (basic_string.h:255) ==31386== by 0x1B24FA9E: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (basic_string.h:511) ==31386== by 0x620C3D7: __static_initialization_and_destruction_0(int, int) (header.h:44) ==31386== by 0x621BE96: _GLOBAL__sub_I_source.cc (source.cc:12969) ==31386== by 0x163647CC: __libc_csu_init (in /path/to/exe) ==31386== by 0x20E9A4E4: (below main) (in /usr/lib64/libc-2.17.so) What I had originally thought was inlining might be tail call optimization. In 000000000012b000 <_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE9_M_createERmm>: there is 12b036: e9 25 b1 f5 ff jmpq 86160 <_Znwm@plt> -- You are receiving this mail because: You are watching all bug changes.