> I've recently switched over to Valgrind 3.10.1 and I'm now see vast numbers
> of 'mismatched free/delete' type messages all coming from std::string
> shipped with GCC 4.8.3.

I've seen this a lot in the past year when working with Firefox.  I believe
that it is due to what you could call "differential inlining".  I'm not 100%
sure of the details, but the general problem is like this:

Memcheck intercepts malloc, free, new and delete.  It expects memory
allocated by malloc to be freed by free and memory allocated by new
to be freed by delete (and the same for new[] and delete[]).

Imagine now that some C++ header file contains something like this

   operator new ( size_t n ) { return malloc(n); }
   operator delete ( void* p ) { free(p); }

If g++ decides to inline new but not delete, or the other way round, then
the code still works (of course) but from Memcheck's point of view there is
a problem.  That's because it can't intercept the inlined function -- there
is no single piece of code to intercept.  So what it ends up seeing is,
for example, memory allocated by new (because that isn't inlined) but freed
by free (because delete got inlined).  So it complains -- incorrectly.

I couldn't figure out any sane way to work around this, so I added a new
flag, --show-mismatched-frees=no|yes [default=yes], to the trunk.  This
disables allocator-mismatch checking and gets rid of the noise, but it of
course also gets rid of the ability to detect genuine mismatch errors.

One other option is to play around with optimisation settings for your
app, to see if it changes g++'s inline/no-inline decisions.  For example,
at -O0 it may be that neither function is inlined, and at -O2 both are,
and it's only at -O1 (a.k.a -O) that you get into this differentially
inlined situation.  I've found -Og, which is available in 4.8 and later,
to be not-bad, but YMMV.  Plus, playing with optimisation options is
of limited use since normally you can only recompile your app, not the
vast stack of libraries on which most apps now depend.

J


------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to