[BUG][SM] Squeak map broken at server?

goran.krampe at bluefish.se goran.krampe at bluefish.se
Sun Jul 11 15:46:57 UTC 2004


Hi Stephand and all!

Stephan Rudlof <sr at evolgo.de> wrote:
> Goran,
> 
> thank you very much!

De nada. :)
 
> goran.krampe at bluefish.se wrote:
> > Hi Stephan!
> > 
> > Stephan Rudlof <sr at evolgo.de> wrote:
[SNIP]
> > This is the bug we have been discussing on this list recently - I am
> > pretty sure.
> > If you press alt-. (at the OK dialog), bring up debugger and do "full
> > stack" you should see that it is in .... .
> > 
> > (Sidenote: Just improved that dialog so that it asks if you want to
> > debug. :))
> > 
> 
> > And if this is the case, try if it works if you start the VM with
> > "-memory 30m".
> 
> Limiting the memory helps.
> 
> > I guess you are on perhaps Linux 2.6 or OpenBSD? :)
> 
> Linux 2.6.
> Hmm, let me try with 2.4; just a moment...
> 
> That's it!
> Without limiting memory
>   SMSqueakMap default reload
> works with
>   Linux karl 2.4.26sr #1 Sun May 23 19:28:24 CEST 2004 i686 GNU/Linux
> , but *not* with my home brewed
>   Linux karl 2.6.7 #1 Fri Jul 9 00:03:48 CEST 2004 i686 GNU/Linux
> !

I think this is related to the new virtual memory implementation in 2.6.
But it is of course a bug in Squeak - it just doesn't occur if the
Squeak process gets placed lower in the address space.

I should also mention that we have reports of this appearing on Solaris
8 and OpenBSD too.
 
> I remember some discussion about memory ranges and have upgraded to 2.6
> recently; but my mind hasn't made the connection between these events
> until yet...
> 
> 
> After looking into the discussion:
> 
> Since this is a serious problem, an ST changeset probably using David's
> MemoryAddressesPlugin checking for the memory problem at startup and
> both warning and hinting the user how to circumvent it, would be good,
> if it takes longer to bugfix the VMs.
> 
> Does the MemoryAddressesPlugin catch this error in every case?
> Does the workaround by manually limiting the memory work in each case?

Well, no. :) I guess that one could be unlucky and end up very close to
the limit and then it would still be allocated overlapping the limit.

> BTW: a release shouldn't be made with this error IMO.

Well, I agree. But I have no idea how much work it is to make a proper
fix - the problem must be very old, but we just haven't experienced it
probably because the OSes haven't used the address space up there
before. Or something.

I will post on the vm-dev list and see if anyone reacts there. It seems
some of our prominent VM people don't scan this list too carefully.

regards, Göran



More information about the Squeak-dev mailing list