Re: Recent libstdc++-v3 regressions (PCHs related?!?)

[David Malcolm <dmalcolm@redhat.com>]

On Tue, 2013-08-20 at 17:02 +0200, Paolo Carlini wrote:
> Hi,
> 
> On 08/20/2013 04:41 PM, David Malcolm wrote:
> > On Tue, 2013-08-20 at 14:03 +0200, Paolo Carlini wrote:
> >> Hi,
> >>
> >> sorry it the issue is by now well known but... I see many libstdc++-v3
> >> regressions on at least x86_64-linux. When running the libstdc++-v3
> >> testsuite (which uses PCHs) one gets tons of new fails like the below.
> >> That's annoying, a lot of confusing noise.
> >>
> >> Thanks!
> >> Paolo.
> >>
> >> PS: CC-ing two "random" ;) people lately very active.
> > Sorry about this - looking at the backtrace this could well be due to
> > me, specifically r201865, which moved the gcc::pass_manager and all the
> > passes into the GC heap (so that we can then move GC-owned per-pass
> > state into the pass instances).
> I can confirm that r201864 isn't affected. Thanks for looking into this!

Thanks.

It tool me a while to reproduce the failure - perhaps on my test box, GC
is happening much less than on yours?  On a test run I only saw 6
failures due to this (my test machine appears to have 3.6 GB of RAM)

Is there a good way to encourage the testsuite to GC more? (I know about
setting --param ggc-min-expand=0 --param ggc-min-heapsize=0 on an
individual invocation, but is there a standard way of doing this?  Or do
I need to run the whole thing in a cgroup or somesuch, and constrain the
available RAM?)

The bug (or, at least the first one I see) is that the pass_manager's
"passes_by_id" array is being allocated using XRESIZEVEC (xrealloc,
hence malloc/realloc under the covers), but given that all this is meant
to interact with GC, it needs to be persistable to PCH [1].  Now that I
see it, I'm wondering how it managed to work in my prior testing.
Presumably the array always happened to be allocated at the same
location between the process that created the pch file and the processes
that read it.

Is there a good way to perturb memory so that accidentally mixing a
malloc allocation with a GC allocation is more reliably fatal, to shake
out this kind of bug?  i.e. to make malloc place its results at
locations that vary from process to process?  (perhaps in libiberty?)
Perhaps also valgrind can catch this kind of thing?

Thanks
Dave

[1] I wish I could just have GC and not have to deal with PCH; oh well.