On Thu, 2015-06-11 at 12:14 +0200, Julian Seward wrote:
> > 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.
Do you see these 'mismatches free/delete' only with Valgrind 3.10.1 ?
I.e. has it appeared with Valgrind 3.10.1 or has it appeared
with a switch to 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.
If the problem is due to "differential inlining", then that should
be visible in the stacktraces either of the "new" or of the "delete" :
unless you specify --read-inline-info=no, valgrind stacktraces will
show both the "new/malloc" or "delete/free" in the stacktraces,
but with an identical program counter.
>
> 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.
What might be done is (assuming that the inline info shows properly the
call to new/delete), is to have an additional check before reporting
a 'mismatched' error: if the stacktrace contains an inlined call to
the expected "freeing function", then do not report the error.
Eg, we might have a third value for --show-mismatched-frees=checkinline
which would activate this verification.
That should remove the false positive errors, and allow to
keep the true positive. The price to pay will be a translation
of program counters to function name and string comparison for
all cases of such "differential inlining" (and that might have to
be done both for the alloc and the free stacktrace).
Philippe
------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
