Thanks for the reply, Paul. You're right. It's about replacement functions instead of overloads.
The VG run was done in an optimized environment and the functions got indeed inlined. Cheers, Thomas ________________________________ From: Paul Floyd via Valgrind-users <valgrind-users@lists.sourceforge.net> Sent: Monday, June 17, 2024 1:18 PM To: valgrind-users@lists.sourceforge.net <valgrind-users@lists.sourceforge.net> Subject: Re: [Valgrind-users] question regarding mismatching free/delete On 17-06-24 08:45, Thomas Wollenzin wrote: > Hi, > > I have a questing regarding Valgrind report 'Mismatched free() / delete > / delete []'. > > I understand that Valgrind is redirecting calls to new/delete and so on > to its own. On the allocation side I see: > > operator new(unsigned long) (vg_replace_malloc.c:487) > > > on the deallocation side > > free (vg_replace_malloc.c:989) > > Our new/delete operators are overloaded and call effectively malloc/free > at some point. > Could it be that Valgrind can get confused and not resolve the > overloaded operators correctly? By coincidence I updated the FAQ on this subject yesterday. See https://valgrind.org/docs/manual/faq.html#faq.mismatches It doesn't sound like you are using tcmalloc. I assume that you mean "replacement new/delete", not overload. See https://en.cppreference.com/w/cpp/memory/new/operator_new ("replaceable allocation functions"). If you really are adding a new overload to the existing set then I would expect Memcheck to not be able to redirect your overloads. If (more likely) you are replacing one of the existing set of standard overloads then are you ensuring that they don't get inlined? (See the FAQ). A+ Paul _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users ________________________________ From: Paul Floyd via Valgrind-users <valgrind-users@lists.sourceforge.net> Sent: Monday, June 17, 2024 1:18 PM To: valgrind-users@lists.sourceforge.net <valgrind-users@lists.sourceforge.net> Subject: Re: [Valgrind-users] question regarding mismatching free/delete On 17-06-24 08:45, Thomas Wollenzin wrote: > Hi, > > I have a questing regarding Valgrind report 'Mismatched free() / delete > / delete []'. > > I understand that Valgrind is redirecting calls to new/delete and so on > to its own. On the allocation side I see: > > operator new(unsigned long) (vg_replace_malloc.c:487) > > > on the deallocation side > > free (vg_replace_malloc.c:989) > > Our new/delete operators are overloaded and call effectively malloc/free > at some point. > Could it be that Valgrind can get confused and not resolve the > overloaded operators correctly? By coincidence I updated the FAQ on this subject yesterday. See https://valgrind.org/docs/manual/faq.html#faq.mismatches It doesn't sound like you are using tcmalloc. I assume that you mean "replacement new/delete", not overload. See https://en.cppreference.com/w/cpp/memory/new/operator_new ("replaceable allocation functions"). If you really are adding a new overload to the existing set then I would expect Memcheck to not be able to redirect your overloads. If (more likely) you are replacing one of the existing set of standard overloads then are you ensuring that they don't get inlined? (See the FAQ). A+ Paul _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
_______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
