Re: Obstack / type_hash_table corruption in tree.c

[Mumit Khan <khan at xraylith dot wisc dot EDU>]

Ulrich Weigand <weigand@informatik.uni-erlangen.de> writes:
> 
> Hello,
> 
> for some time, we are having problems compiling Wine with gcc;
> these manifest themselves by persistent, reproducible crashes of cc1.
> Thus, I decided to have a look at the problem, and I think I found
> the culprit.  (Note that this is the first time I ever looked at 
> the gcc sources in detail, so I might not be completely correct ...)
> 
> The immediate reason for the crash is that a pointer pointing to an
> object allocated on a local obstack is entered into a global hash
> table (type_hash_table in gcc/tree.c).  The pointer remains there
> even after the local obstack (and hence the object) are deleted 
> again.  Much later, that memory might happen to be reused for something
> else, and the type object is overwritten.  If gcc tries to access
> that slot of the hash table afterwards, it will crash.
> 
> Now, I tried to find out why this pointer is added to the hash table
> in the first place.  This happens within the routine
> build_type_attribute_variant (tree.c), which calls type_hash_canon
> which finally calls type_hash_add.

[ ... ]

Jim Wilson just sent a fix for it to gcc-patches list on July 15. See:

   Linkname: tree.c (build_type_attribute_variant): Move current_obstack
   URL: http://egcs.cygnus.com/ml/gcc-patches/1999-07/msg00391.html

Regards,
Mumit