Re: [Valgrind-users] Mismatched free/delete with GCC 4.8.3 std::string

[David C. <dc...@gm...>]

For the alloc'd line Valgrind points at new_allocator.h line 110, the
de-alloc line is pointed to new_allocator.h line 104.  The first looks like
this in GCC sources:

return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));

the second looks like this:

deallocate(pointer __p, size_type)
{ ::operator delete(__p); }

I don't see a mismatch there.

The particular use-case I'm looking at is in string_buf, but there are
literally thousands of others.

Regards,
David.

On Thu, Jun 11, 2015 at 6:58 PM, Philippe Waroquiers <
phi...@sk...> wrote:

> 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
>
>
>