sigsev in 64/32 bit VM

[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

[Martin Kuball]

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

[Martin Kuball]

Am Sunday, 28. May 2006 20:54 schrieb David T. Lewis:

> 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

What exactly are the absoulutely necessary plugins?

Martin

> 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

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


tim
--
tim Rowledge; tim@...; http://www.rowledge.org/tim
Useful Latin Phrases:- Utinam coniurati te in foro interficiant! =  
May conspirators assassinate you in the mall!

[Craig Latta]

Hi Martin

 > What exactly are the absoulutely necessary plugins?

        The current Spoon VMs are built with BitBlt, File, FloatArray,
Security, and Misc (all internal). Problems occurred if I took any of
those away, but haven't bothered to investigate yet. They probably
aren't all needed.


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

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

By the way when compiling I see a lot of warnings like this one:

        /home/kuball/SMT/vm-svn/trunk/platforms/unix/mysrc/vm/interp.c:7772:
        warning: cast from pointer to integer of different size

I'm not sure if it is save to ignore them.

The reason I did not mention anything about system startup is that
nothing unusual happend. And it's not the the first time I build a
VM. I even have an 64/32 bit VM working here. But it's almost 1 year
old and has no network support. Because of that and because I plan to
resume work on my xvid plugin I want something more up to date.

Martin

[Martin Kuball]

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?

Martin