[Vm-dev] Ephemerons and VM crash

[Guille Polito]

Hello,

-------- Original Message --------
>   
>
>
> Hi Guille, Hi Pablo (and welcome),
>
> On Tue, May 17, 2016 at 8:37 AM, Guille Polito 
> <guillermopolito at gmail.com <mailto:guillermopolito at gmail.com>> wrote:
>
>
>     Hi Eliot, list
>
>     I'm working here with Pablo (Tesone) on moving forward the
>     Ephemeron implementation. We first installed Eliot's changeset,
>     added a #mourn method and an EphemeronDictionary collection, and
>     then started testing something like this:
>
>     f := ObjectFinalizer receiver: 'Hello' selector: #logCr.
>     d := EphemeronDictionary new.
>
>     d at: f put: f.
>
>     f := nil.
>     Smalltalk garbageCollect.
>
>
> So this looks like something simulate able.  Are you able to use the 
> simulator?  If not, why not?

For some reason I have that bytesToShift when opening the image is negative.

     bytesToShift := objectMemory memoryBaseForImageRead - oldBaseAddr.  
"adjust pointers for zero base address"

So I cannot continue loading because addresses become negative and I 
have "Improper Store into indexable object kind of errors".
>
> When debugging the VM there are two main levels of support, one is the 
> simulator where there is maximum support for debugging:
> - asserts on all the time
> - arbitrary breakpoints
> - attempting every GC in a copy of the heap before doing the real GC 
> so that bugs in the GC can be investigated without needing to 
> construct a reproducible case after a crash
> - the Smalltalk environment to inspect and browse
>
> The next level is the assert and debug VMs.  If you look in the build 
> directories on the Cog svn branch you'll see that all of them build 
> three VMs, a production VM with maximum optimisation and asserts 
> excluded, an assert VM with -O1 and asserts enabled, and a debug VM 
> with -O0 and asserts enabled.  So if you either don't see the bug in 
> the simulator, or the simulator is too slow for the case being 
> examined, or if the bug doesn't show up in the simulator (the worst of 
> all worlds), build both assert and debug VMs and run with the assert 
> VM first.
>
Well so far we were using a VM compiled for debug with a graphical C 
debugger. It was not so bad. However, I cannot say I'm missing a better 
debugger.

> Note that there is a heap leak checker which can be enabled both in 
> the simulator and the assert and debug VMs.  See the checkForLeaks 
> method and the -leakcheck argument.

ok!
>
> Without the simulator or the assert and debug VMs you are flying 
> blind.  It is /really/ productive to use the simulator for debugging, 
> provided the bug is reproducible within a short amount of time, as for 
> example your case is above.

Ok, gotcha! By this afternoon I'll have some news probably.

Thanks a lot!
>
>
>
>
>     However, as soon as we garbage collect twice, we have a VM crash.
>     We started debugging the VM to see if we could have some more clues.
>
>     The first thing we noticed is that the first time the GC runs, the
>     mournQueue is nil. This is of course expected because the new
>     finalization mechanism was not active and then there was no need
>     to create the mournQueue. We saw that the mournQueue is actually
>     created in a lazy fashion when putting queuing a mourned object (I
>     refer myself to #queueMourner: and #ensureRoomOnObjStackAt:). So
>     the second time the GC passes, the mournQueue is there. So far ok,
>     but still crashing.
>
>     The crash happens in the call to
>
>     markAndTraceObjStackandContents(GIV(mournQueue), 1);
>
>     after the
>
>         if (!markAndTraceContents) {
>            return;
>         }
>
>     But when understanding why, it starts being less clear to us :).
>     We used the printObjStack() function and we saw that:
>
>     call printObjStack(markStack)
>     call printObjStack(weaklingStack)
>
>     and we saw in the console some output that makes sense. However,
>     printing the mournQueue in the same manner produces some strange
>     output
>
>     call printObjStack(mournQueue)
>
>     head  0xb06e980 cx 18 (18) fmt 10 (10) sz 4092 (4092) myx: 4098
>     (4098) unmkd
>         topx: 14 next:        0x0 free:        0x0
>
>     We noticed that free and next are 0x0 while the others are not...
>
>     Finally we saw there is isValidObjStack(), that gave us the
>     following results:
>
>     call isValidObjStack(markStack) => 1
>
>     call isValidObjStack(weaklingStack) => 0
>     p objStackInvalidBecause = "marking but page is unmarked"
>
>     call isValidObjStack(mournQueue) => 0
>     p objStackInvalidBecause = "marking but page is unmarked"
>
>
>     So we assume that the stack creation is wrong? We are a bit lost
>     in here.
>
>     Guille and Pablo
>
>
>
>
> -- 
> _,,,^..^,,,_
> best, Eliot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160518/52cb24e1/attachment.htm