Re: oballoc, try_combine, and such

[Jeffrey A Law <law at hurl dot cygnus dot com>]

  In message <199812102255.OAA13414@adsl-206-170-148-33.dsl.pacbell.net>you wri
te:
  > 
  > Folks --
  > 
  >   I just tracked down a nasty bug in the C++ front-end that might have
  > been more easily caught with some changes to the back-end.  In
  > particular, the C++ front-end was calling rest_of_compilation with
  > current_obstack and saveable_obstack set to permanent_obstack, rather
  > than the usual temporary_obstack and function_maybepermanent_obstack.
  > (Basically, we had pushed permanent obstacks and not popped them.)
You've hit on one of the reasons why we want to kill many of the obstack
uses in the compiler.  They're useful for some things, but as the primary
allocator, they suck in a big way.


  > Normally, this would just be a colossal and undetectable waste of
  > space.
  > 
  >   But, try_combine did:
  > 
  >   /* Save the current high-water-mark so we can free storage if we didn't
  >      accept this combination.  */
  >   undobuf.storage = (char *) oballoc (0);
  > 
  > Then, it called immed_double_const, which hooked something on the
  > const_double_chain.  Finally, it called:
  > 
  >       undo_all ();
  > 
  > which freed the memory, leaving the const_double_chain in tatters.
  > The tricky thing here is that immed_double_const inentionally
  > allocates on the saveable_obstack; try_combine is therefore implicitly
  > assuming that oballoc is not allocating from the saveable_obstack.  
Yes.  I suspect there are other places that assume that certain obstacks 
can not be the "current obstack".


  >   I suggest that we put in one or more of the following asserts:
  > 
  >     o That saveable_obstack != current_obstack in try_combine.
  >     o That current_obstack == temporary_obstack in oballoc.
  >     o ???
  > 
  >   I'm not sure what's most appropriate, here, but I'm sure that a
  > simple assert like this would help prevent another bug like this
  > popping up.
Not sure either.  I'd almost be tempted to put a call in toplev.c to check
that the well known obstacks are "sensible".  Most obstack problems are
front-end related since they tend to do more manipulation of well known
obstacks.  So if we could catch the problem as we enter rest_of_compilation
we win.

Also if we have a functional interface, we can call it from the debugger
if we think the obstacks may have gotten confused.



jeff