Thanks for the below info.
Can you post the full stacktraces of a mismatch error
(including program counters etc) ?
Also, can you confirm if the mismatch errors
appeared with a switch to valgrind 3.10.1 ?
Or with a switch to gcc 4.8.3 ?
Thanks
Philippe
On Thu, 2015-06-11 at 23:29 +0100, David Carter wrote:
> 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
