On Thu, Mar 28, 2002 at 10:21:21PM -0800, Dan Ingalls wrote:
> 
> > >		int remapBuffer[26];
> >
> >I know nothing about this.
> 
> It doesn't help at all to make this bigger than necessary, but it's disastrous if it isn't big enough.  It holds a stack (that is not checked for overflow!) of oops to handle code patterns like...
> 
> 	interpreterProxy pushRemappableOop: ffiRetClass.
> 	retOop _ self ffiCreateReturnOop: retVal.
> 	ffiRetClass _ interpreterProxy popRemappableOop.
> 
> In this case ffiCreateReturnOop could cause a GC, and thus invalidate the value of ffiRetClass.  By pushing it into this buffer and then popping it back out, one is assured that if a GC does take place, an updated opp will be returned by the pop.
> 
> [In reviewing this code I think I'd figure some low-overhead way to check for overflow here.  I don't think there are many places where this is time-critical and it would be an *awful* bug to track down].
>

I recently posted a possible fix for this under the title "[VM][BUG][FIX] pushRemappableOop: stack overflow", see http://swiki.gsug.org:8080/sqfixes/2272.html.

This is probably a reasonable fix, although to be honest I think that any
primitive which overflows this stack is probably going to fail catastrophically
anyway, so it might be just as well to stop the VM with error dump when
this happens. In any case, from what I could tell, most existing code seems
to use this stack to a depth no greater than about six (I don't remember
exactly), and most primitives are just using it to a depth of one.

And yes, it was a nasty bug to track down. I had written a primitive which
answers an arbitrarily sized array of strings (the collection of environment
strings on a Windows OS), and which was building the array on the fly. If
the array had more than 25 entries, bad things happened. I'm afraid that
I have gotten so accustomed to Squeak doing the right thing with collections
that I completely forgot to look at what kind of "collection" I was dealing
with in the VM ;)

Dave