[Vm-dev] Reproducible Cog crash from image startup

Igor Stasenko siguctua at gmail.com
Mon Feb 27 20:03:25 UTC 2012


On 27 February 2012 10:53, Mariano Martinez Peck <marianopeck at gmail.com> wrote:
>
>
>
> On Mon, Feb 27, 2012 at 5:20 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>
>> Hi Mariano,
>>
>> On Sun, Feb 26, 2012 at 8:58 AM, Mariano Martinez Peck <marianopeck at gmail.com> wrote:
>>>
>>>
>>> Hi. I have faced a VM crash while using Nautilus browser. It took me a while, but I finally could make a reproducible crash from image startup. You can find the image here:
>>> https://gforge.inria.fr/frs/download.php/30280/Marea.104-Crash.1.image.zip
>>>
>>> What the image is running at startup that causes the crash is:
>>>
>>> | nautilus model ui|
>>> Nautilus instVarNamed: 'groups' put: nil.
>>> model := Nautilus open.
>>> ui := model ui.
>>> ui groupsButtonAction.
>>>
>>> If you need more about the "domain", we can ask Ben, Nautilus developer.  From what I can see in GDB, it crashes in #mapStackPages  because it does a remap to an OOP that is 0 (zero)
>>>
>>> while (theSP <= frameRcvrOffset) {
>>>                     oop = longAt(theSP);
>>>                     if (!((oop & 1))) {
>>>                         longAtput(theSP, remap(oop));
>>>                     }
>>>                     theSP += BytesPerWord;
>>>                 }
>>>
>>>
>>> Any ideas?
>>
>>
>> The image overflows the weakRoots table in scanning stack pages.  The weakRoots table registers weak objects for scanning at the end of a GC.  It is, unfortunately, fixed size (~2600 entries), and there are lots of WeakMessageSends and WeakAnnouncementSubscriptions on the stack.
>>
>> I found this using aDebug VM with assert enabled (i.e. compiled with NDEBUG /not/ defined).  I increased the table size to 3000 then 6000 before finding it no longer crashed with a weakRoots  table size of 12000.
>>
>
> wow, I never imagine about that.
>
>>
>> a) Looks like weakRoots' size should be configurable either via a start-up flag or an image header constant (with e.g. vmParameter accessors).
>
>
> yes, with vmParameter would be nice, like the external semaphore table.
>
>>
>>
>> b) overflowing the weakRoots table (and possibly other tables) should probably cause the VM to abort with a useful error message.
>>
>
> please!  :)
>
> I have check in the image, before reproducing the bug, and it is not that bad:
>
> WeakMessageSend instanceCount 755.
> WeakAnnouncementSubscription instanceCount 538
>
> So...maybe when I do the stuff that reproduces the crash there is ANOTHER bug (say a loop for example), that cause to have much more instances of those weak stuff?
>
>
hmm.. i hardly believe that UI needs such amount of weak messages to
wire the stuff.. but it is hard to tell, since i'm not an author.

Also, answering Stephane's question: AFAIK, a weak roots table size is
not liearly depending on the total number of all weak containers in
your image.
But i might be wrong.
Eliot, can you please explain how this weak roots table populated and
what triggers addition of new element(s) to it, and freeing the entry.
And is the weak roots table size limit reasonably good? Needless to
say, that nobody likes when system hits the wall of hardcoded limits.

-- 
Best regards,
Igor Stasenko.


More information about the Vm-dev mailing list