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@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: PUS: PUrge System
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===