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

[David Malcolm <dmalcolm at redhat dot com>]

On Tue, 2013-08-20 at 21:26 -0400, David Malcolm wrote:
> 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.

...and also the code wasn't visiting the array itself during pch
traversal, just the elements within it.   Fixing this will likely make
the other problem show up immediately.


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