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 <
philippe.waroqui...@skynet.be> 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
>
>
>
------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
