Could this be caused by some smart* using -static-libstdc
To create one of the involved shared libraries? Peter From: Foelsche, Peter Sent: Tuesday, August 4, 2020 10:28 To: valgrind-users@lists.sourceforge.net Subject: [Valgrind-users] Mismatched free() / delete / delete[] -- false positives * Valgrind-3.13.0 * CentOS release 6.5 (Final) * g++ (GCC) 5.3.0 * no usage of tcmalloc I checked by cat /proc/<PID>/maps |sed -e 's/[a-zA-Z0-9_:-]*[ \t][ \t]*//g'|sort -u|xargs nm -A|grep '\<free\>'|grep -v '\<U\>' output was /lib64/ld-2.12.so:0000003bfba16090 W free /lib64/libc-2.12.so:0000003bfc27b520 T free /path/executable:000000000f9f3c50 W free * positives for both directions o free used for memory allocated with new o delete used for memory allocated with malloc 1) ==11679== Mismatched free() / delete / delete [] ==11679== at 0x127ECAFE: free (vg_replace_malloc.c:530) ==11679== by 0x1CC871A1: void std::_Destroy<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) (stl_construct.h:93) ==11679== by 0x1CC82295: void std::_Destroy_aux<false>::__destroy<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) (stl_construct.h:103) ... ==11679== Address 0x2633aeb0 is 0 bytes inside a block of size 155 alloc'd ==11679== at 0x127EDBE7: operator new(unsigned long) (vg_replace_malloc.c:334) ==11679== by 0x54B81C3: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forwar d_iterator_tag) (basic_string.tcc:223) 2) ==11679== Mismatched free() / delete / delete [] ==11679== at 0x127EC64E: operator delete(void*) (vg_replace_malloc.c:576) ==11679== by 0x8172EC3: __gnu_cxx::new_allocator<Sdi::StateVar const*>::deallocate(Sdi::StateVar const**, unsigned long) (new_allocator.h:110) ==11679== by 0x8172767: std::allocator_traits<std::allocator<Sdi::StateVar const*> >::deallocate(std::allocator<Sdi::StateVar const*>&, Sdi::StateVar const**, unsigned long) (alloc_traits.h:386) ... ==11679== Address 0x2a5e08b0 is 0 bytes inside a block of size 32 alloc'd ==11679== at 0x127ED104: malloc (vg_replace_malloc.c:299) ==11679== by 0x206F33E7: operator new(unsigned long) (new_op.cc:50) ==11679== by 0x1CCE9829: __gnu_cxx::new_allocator<Sdi::StateVar const*>::allocate(unsigned long, void const*) (new_allocator.h:104) There are only a 7 of the 1) messages and 3 of the 2) despite there are many more such allocations. As you can see, both places are inside STL and thus are likely to be correct. I think vg_replace_malloc.c is coming from valgrind, isn't it? Peter Mogan : Hey Bruno. What are you? A 65? Bruno : Model 63. Deluxe. Kelp : 63? Talk about ancient. Bruno : Your sister didn't seem to mind.
_______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
