Hi John,
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.
I tend to agree with Tim and you about this. That's why it was categorised as 'nasty and dirty' ;-)
But Mark reported a crash when he evaluated:
Form fromFileNamed: 'anything.bmp'
I could never reproduce this. However I could randomly crashed Squeak when I tried to makeActorFrom cat.mdl. Sometimes I got a cat sometimes I got a crash before my first post.
After my first posting, I tried several times on two diffrent machines and could not reproduce it even when loading mutiple actors, one after another.
How can this behavior be explained ? What can cause Squeak to crash in a non-reproducible manner ?
If the loading of BMP is corrupting the memory, would the crash be reproducible every time ?
To me this bug seems to be dependent on environment. Maybe Mark can clarify this by trying to reproduce it under different environments.
I also noticed a few things that may be helpful for further investigations:
1/- primitiveFullGC (130) is never called during my game session (FreeCell, Tetris)
2/- primitiveFullGC is not called when I evaluated:
Form fromFileNamed: 'F:\squeak\AliceObjects\Animals\Chicken.bmp'
3/- primitiveFullGC is not call when I open/view same bitmap via FileList.
4/- primitiveFullGC is called many times when I open 'Chicken.mdl' once for every part of the chicken, namely:
left leg, left foot, right leg, right foot, neck, head, upperLip, lowerLip.
who, what are responsible for the GC call ?
5/- at this point sometimes it crashed, sometimes it didn't, but if it did not crash, it did not show me the chicken either (not even in the garbage bin ;-)
Where is my chicken ? Is this reproducible on other platforms.
Cheers,
PhiHo.
----- Original Message ----- From: "John M McIntosh" johnmci@smalltalkconsulting.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Friday, June 20, 2003 4:10 PM Subject: Re: [BUG] Can't read BMPs in 3.4/3.5 Windows VM (was Re: [bug?] Problems with Alice -- can't open new models)
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 ======================================================================== ===