sigsev in 64/32 bit VM

> Hi!
>
> I compiled a 64/32 bit VM from svn. Immediately after start I get a
> SIGSEV at: interp.c line 7865:
>
> longAtput(where + ((ReceiverIndex + i) << ShiftForWord),
>  longAtPointer(localSP - ((argCount2 - i) * BytesPerWord)));
>
> I examined the arguments to longAtput and they seem OK. But there
> is no Memory mapped at sqMemoryBase. How could that happen?
>
> Martin

> Hi Martin,
>
> It's been a couple of months since I've tried compiling a VM on
> amd64, but if noone else replies to this I'll give it a try
> sometime in the next couple of days and let you know if it works
> for me. Right now I'm too busy drinking beer and enjoying a long
> Memorial Day weekend ;) (that's the US holiday to honor war
> veterans, but also the semi-official first day of summer).
>
> In the past I have seen symptoms like this due to problems in the
> memory access macros/functions in sqMemoryAccess.h, but it really
> could be caused by most anything. You should definitely build only
> the absolutely necessary plugins until you get the VM to run, as
> many of the plugins are not 64 bit clean.
>
> Dave

> On Sun, May 28, 2006 at 07:26:11PM +0200, Martin Kuball wrote:
> > Am Sunday, 28. May 2006 15:24 schrieb Martin Kuball:
> > > Hi!
> > >
> > > I compiled a 64/32 bit VM from svn. Immediately after start I
> > > get a SIGSEV at: interp.c line 7865:
> > >
> > > longAtput(where + ((ReceiverIndex + i) << ShiftForWord),
> > >  longAtPointer(localSP - ((argCount2 - i) * BytesPerWord)));
> > >
> > > I examined the arguments to longAtput and they seem OK. But
> > > there is no Memory mapped at sqMemoryBase. How could that
> > > happen?
> > >
> > > Martin
> >
> > Forgot to give you some more details. I'm running a amd64 system
> > with linux 2.6.14. Compiler ist gcc 4.0.3.
> >
> > Martin

> On 29-May-06, at 12:51 PM, Martin Kuball wrote:
> >>>> I examined the arguments to longAtput and they seem OK. But
> >>>> there is no Memory mapped at sqMemoryBase. How could that
> >>>> happen?
> >>>>
> >>>> Martin
> >>>
> >>> Forgot to give you some more details. I'm running a amd64
> >>> system with linux 2.6.14. Compiler ist gcc 4.0.3.
>
> If there is no memory mapped at a fundamental address like
> sqMemoryBase that implies to me that some very serious has failed,
> and I think it must surely have failed right at the beginning of
> starting Squeak. You didn't mention anything about whether the
> system started up or not, what you were doing, or anything that
> might help us.
>
> sqMemoryBase is typically set right at the beginning of the VM
> startup, by allocating the memory for the image so if for some
> strange reason that fails you could be in trouble. It's hard to
> imagine how the allocate could fail and not be detected though.

> Am Monday, 29. May 2006 23:43 schrieb tim Rowledge:
> > On 29-May-06, at 12:51 PM, Martin Kuball wrote:
> > >>>> I examined the arguments to longAtput and they seem OK. But
> > >>>> there is no Memory mapped at sqMemoryBase. How could that
> > >>>> happen?
> > >>>>
> > >>>> Martin
> > >>>
> > >>> Forgot to give you some more details. I'm running a amd64
> > >>> system with linux 2.6.14. Compiler ist gcc 4.0.3.
> >
> > If there is no memory mapped at a fundamental address like
> > sqMemoryBase that implies to me that some very serious has
> > failed, and I think it must surely have failed right at the
> > beginning of starting Squeak. You didn't mention anything about
> > whether the system started up or not, what you were doing, or
> > anything that might help us.
> >
> > sqMemoryBase is typically set right at the beginning of the VM
> > startup, by allocating the memory for the image so if for some
> > strange reason that fails you could be in trouble. It's hard to
> > imagine how the allocate could fail and not be detected though.
>
> Hi!
>
> I compiled a VM with BallonEngine, BitBlitSimulation and
> FilePlugin. I started the vm in gdb and checked the allocation of
> the memory. All went well. The reason I reported a bad memory
> region earlier is that sqMemoryBase is the real base - 16.
> Now the interpreter loop runs and at its 12th cylce (opcode 134) I
> still get the SIGSEV. Further investigation showed that
> foo->stackPointer is the culprit. All the cycles before it had a
> value of 15723512. But this time the value is 1509280732. Really
> bad. I will try to find out where this change happens tomorrow.