[Vm-dev] Ephemerons and VM crash
Guille Polito
guillermopolito at gmail.com
Tue May 17 15:37:15 UTC 2016
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.
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
More information about the Vm-dev
mailing list