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 at smalltalkconsulting.com>
To: "The general-purpose Squeak developers list" <squeak-dev at 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 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
> ========================================================================
> ===
>
>