[SOLVED?] (was Re: [BUG HUNT!]ImageSegment loading troubles revisited)

John M McIntosh johnmci at smalltalkconsulting.com
Fri Jul 2 16:20:43 UTC 2004


Well if linux 2.6 loaded the image over the 2  GB boundary you would  
crash right away when you swizzle the oops at start up time.
What you should do is put a break point in the memory allocation logic  
that is responsible for growing the image and see when
the pointer goes negative as it's being adjusted after a grow/shrink.

You could also check what the start of memory location is, since I  
recall the unix VM wants to allocate 1GB, so does start of memory plus
1GB > 2GB?

On Jul 2, 2004, at 8:13 AM, goran.krampe at bluefish.se wrote:

> Hi all!
>
> Well, now I have come closer to the answer. I patched my interp.c so
> that when it normally failed - after oopHasOKclass(anOop) returns 0, I
> called oopHasOKclass() once more, so that I could step through it line
> by line.
>
> It appears to me in insight/gdb that foo->endOfMemory is negative (sign
> bit gotten set?) so the interval check that looks like this:
>
>         if (!((0 < oop) && (oop < foo->endOfMemory))) {
>                 return 0;
>         }
>
> ...fails.
>
> Hmmm, ok - so has this worked until now just because of luck? Has  
> memory
> normally been mapped below 32 bits, and now with kernel 2.6 (for
> example) Linux decides to place Squeak above it sometimes? And is the
> problem simply that we can't treat endOfMemory as a signed int?! And  
> did
> Greece really go to the Euro championship soccer final yesterday? It
> seems so.
>
> Here are the shocking evidence (in the form of png images) from my
> insight expedition into VM low level country, with assembler and all:
>
> 	http://anakin.bluefish.se/gohu/uploads/4/bughunt.zip
>
> Over and out from VM-expeditioner-newbie Göran Krampe, who is now
> jumping on a bus going home to eat a nice dinner and drink some wine
> with his wonderful wife hoping that someone else can bring order into
> this situation. :)
>
> regards, Göran
>
>
>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===




More information about the Squeak-dev mailing list