sigsev in 64/32 bit VM

Martin Kuball martinkuball at
Wed May 31 20:26:26 UTC 2006

Am Tuesday, 30. May 2006 22:19 schrieb Martin Kuball:
> 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.

The only thing I can tell you is that the stackpointer is set from 
localSP at one point via:
	foo->stackPointer = oopForPointer(localSP);
Now oopForPointer seems to be a simple cast to sqInt (which is a 
typedef from int). Now casting a pointer to a char to an int might 
actually leed to problems on a 64bit system. Which indeed it does in 
this case as 0x2aaaad732bec becomes 0xffffffffad732bec.

Any suggestions what to do now?


More information about the Vm-dev mailing list