Ya, I think the last GC bug we had which was related to class changing  
and process switching where one forgot
to remember to swap an instance variable was 2-3? years ago. This is  
not to say there couldn't be a bug, however in my
experiences any GC crash is related to some primitive trashing memory.

If you've seen the visualworks source code, why every step of the way  
in the debug vm, there are assert checks
to confirm there are no buffer overflow conditions and everything in  
sight is confirmed as valid. We aren't as paranoid in Squeak.

I'd suspect one would need to look at the BMP code and start coding up  
asserts to confirm there are no
memory overwrite conditions.

For example I just fixed a problem in the SerialPort Read Primitive  
were a size check is made, but on a failure
just the success flag is set (prim failed), and the vm cheerfully  
executes the memory trashing. It never has been an issue
because the primitive call is setting up the right values, still I was  
surprised to see it was defective.

On Friday, June 20, 2003, at 11:47  AM, Tim Rowledge wrote:

> It's very unlikely that this is a bug in the GC code. Crashing in prim
> 130 means nothing - much more plausible is that the BMP loading code is
> corrupting memory and the corruption causes GC to go mental.
>
> tim
> --
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Strange OpCodes: PUS: PUrge System
>
>
>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===