[Vm-dev] [unix] 4.10.2.2614 segfaults on ARM

David T. Lewis lewis at mail.msen.com
Wed Oct 9 18:09:47 UTC 2013


Tim, could you try running this DrGeo image on an interpreter VM for RISC OS?

I don't have an ARM machine to test, and I'm afraid that it is going to require
a debugger (gdb) to sort this one out.

That said, here are some ideas:

My first thought was that this might be a plugin issue. But noting that
the segfault happens right after the display window opens, and before
much of anything else happens, and also noting that -1799995044 negative
number in the error output, I am inclined to think it is failing in the
process of loading the image and fixing up addresses from the disk image,
or very shortly thereafter. This is a format 6504 image, which means that
there is no issue of reordering floats during this process, but the VM
still needs to scan through the entire object memory to fix object pointers
before it can do anything else, so perhaps the failure is happening at
around that point.

I took a look at the image file header and don't see anything of obvious
concern. The image was saved from an interpreter VM, so there is no
possibility of Cog related issues. I am attaching the header information
in case it prompts any ideas from others.

Things that someone can try without resorting to gdb:

It would be good to verify whether other images fail in the same way,
or whether this is in some way specific to the DrGeo image. Perhaps someone
can take a recent Squeak image, save it from an interpreter VM (to make
sure that it is in 6504 format like DrGeo), and see if it runs on
the OLPC X0-1.75 machine. If it works, then we know the problem is
in some way associated with the DrGeo image, otherwise (and more likely)
it is associated with the VM.

On the OLPC X0-1.75, try deleting (or renaming) the external VM plugins.
Then see if it is possible to start the DrGeo image. If there is a problem
in one of the plugins, this could help identify it.

If someone has a different ARM Linux box (maybe a Raspberry Pi?), then
check and see if DrGeo works at that platform.

On the OLPC X0-1.75, try using the "-memory" command line option to
the VM. Pick a few reasonable looking values, and see if one of them
accidentally causes the VM to start working. Rationale: If the problem
is somehow associated with initial load of the image file into memory,
then fiddling around with this setting might cause the symptoms to change
or possibly even go away.

HTH,
Dave

On Wed, Oct 09, 2013 at 03:27:44PM +0200, Bert Freudenberg wrote:
> 
> The same image works fine using the interpreter on x86, and on various other VMs. Here's the drgeo.image, inside a zip renamed to .xo:
> 
> https://gforge.inria.fr/frs/download.php/30585/DrGeoII-12.04.xo
> 
> (original report below)
> 
> Any idea what might be wrong?
> 
> - Bert -
> 
> Begin forwarded message:
> 
> > From: "Daniel Drake [via Dr. Geo Forum]" <ml-node+s996172n4024197h7 at n3.nabble.com>
> > Subject: Running on OLPC XO-1.75 (ARM)
> > Date: 8. Oktober 2013 23:41:32 MESZ
> > To: bert <bert at freudenbergs.de>
> > 
> > Hi, 
> > 
> > I am trying to run DrGeo on OLPC XO-1.75 using the Sugar activity provided. 
> > 
> > This fails to launch because the Sugar activity includes an x86 Squeak VM. I modified the launcher script to use the system-wide Squeak VM (we have 4.10.2.2614, also used for Scratch and Etoys) but without success. 
> > 
> > Now, I briefly see a window, then it crashes with: 
> > Segmentation fault 
> > -1799995044 UndefinedObject>? 
> > Segmentation fault 
> > 
> > Any ideas or things I can try? I guess the squeak VM we are running there is much newer than the one shipped in the Sugar activity - maybe there is a new drgeo image that I could try against the new VM? 
> > 
> > Thanks 
> > Daniel 
> > 
> > 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DrGeo-ImageFileHeader.png
Type: image/png
Size: 31382 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20131009/deb746d9/DrGeo-ImageFileHeader-0001.png


More information about the Vm-dev mailing list