[Vm-dev] Ephemerons and VM crash
Guille Polito
guillermopolito at gmail.com
Wed May 18 07:46:19 UTC 2016
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
More information about the Vm-dev
mailing list