[Vm-dev] Linux 4.4.7.2357 VM crash under memory pressure

[David T. Lewis]

On Sun, May 20, 2012 at 03:08:20PM +0200, Bert Freudenberg wrote:
> 
> Hilaire discovered that his newest DrGeo segfaults on the XO-1. It works fine elsewhere, including the XO-1.5, which has pretty much the same OS.
> 
> We narrowed down the problem to the XO-1 having only 256 MB of RAM and no swap space. I can reproduce the crash in a virtual Ubuntu 12 with 768 MB RAM (!) but no swap. Top reports:
> 
> Mem:    766204k total,   601588k used,   164616k free,    45624k buffers
> Swap:        0k total,        0k used,        0k free,   277024k cached
> 
> but DrGeo still crashes. Etoys runs fine using the same Squeak VM on the same system (and on XO-1). DrGeo is based on Pharo 1.4, using a closure image. Etoys still is pre-closure. 
> 
> I ran the DrGeo under GDB. Here is the backtrace after the SEGFAULT, "gnu-interp.c:27272" maps to the "newOop = longAt(fwdBlock);" line in updatePointersInRootObjectsFromto():
> 
> =============
> (gdb) bt
> #0  0x0807acdb in updatePointersInRootObjectsFromto (memStart=-1314145112, 
>     memEnd=-1312574048)
>     at /home/olpc/Squeak-4.4.7.2357-src/bld/gnu-interp.c:27272
> #1  0x08068586 in mapPointersInObjectsFromto (memStart=-1314145112, 
>     memEnd=-1312574048)
>     at /home/olpc/Squeak-4.4.7.2357-src/bld/gnu-interp.c:13495
> #2  0x0805b53f in incCompBody ()
>     at /home/olpc/Squeak-4.4.7.2357-src/bld/gnu-interp.c:5068
> #3  0x0805bbe8 in incrementalGC ()
>     at /home/olpc/Squeak-4.4.7.2357-src/bld/gnu-interp.c:5405
> #4  0x0805c9c7 in instantiateContextsizeInBytes (classPointer=-1324064796, 
>     sizeInBytes=92) at /home/olpc/Squeak-4.4.7.2357-src/bld/gnu-interp.c:6099
> #5  0x080575b8 in allocateOrRecycleContext (needsLarge=0)
>     at /home/olpc/Squeak-4.4.7.2357-src/bld/gnu-interp.c:2050
> #6  0x08061898 in interpret ()
>     at /home/olpc/Squeak-4.4.7.2357-src/bld/gnu-interp.c:9310
> #7  0x0807f107 in main (argc=2, argv=0xbffff494, envp=0xbffff4a0)
>     at /home/olpc/Squeak-4.4.7.2357-src/unix/vm/sqUnixMain.c:1444
> (gdb) p/x memory
> $3 = 0xb1094000
> (gdb) p/x foo->endOfMemory
> $4 = 0xb1c3b5a0
> (gdb) p/x memStart
> $5 = 0xb1abbca8
> (gdb) p/x memEnd
> $6 = 0xb1c3b5a0
> (gdb) p/x fwdBlock
> $7 = 0x63577a08
> =============
> 
> fwdBlock appears to be clearly outside the object memory, that can't be right? Any idea how to fix it?
> 

I'm fairly sure this problem is going to be an issue in the Smalltalk slang
(VMMaker) as opposed to the support code. I'm not sure what's going on there,
but looking at the Smalltalk source may give some clues.

The failure is occurring in ObjectMemory>>remapFieldsAndClassOf: which is
stepping through the fields of oop to remap pointers. Presumably the value
of fwdBlock is bogus at the time of the crash. I note a fair amount of logic
related to object header formats in ObjectMemory>>lastPointerWhileForwarding:
that goes computing the value of fwdBlock, and also that NewObjectMemory for
Cog has some different logic here.

I wonder if lastPointerWhileForwarding: may be missing some update necessary
to support closure images?

Eliot, could you have a look at the old ObjectMemory>>lastPointerWhileForwarding:
and see if something is missing that would be required for a closure image?

Dave