[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
|