and in fact the issue is an infinite recursion in Nautilus class>groupsManager:<div><br></div><div><div>0xbff5ead0 M Nautilus class>groupsManager 363174868: a(n) Nautilus class</div><div>0xbff5eae8 M Nautilus>groupsManager 397856104: a(n) Nautilus</div>
<div>0xbff5eb00 M NautilusUI(AbstractNautilusUI)>groupsManager 397856244: a(n) NautilusUI</div><div>0xbff5eb1c M NautilusUI(AbstractNautilusUI)>aGroupHasBeenAdded: 397856244: a(n) NautilusUI</div><div>0xbff5eb38 M WeakMessageSend>value: 397858000: a(n) WeakMessageSend</div>
<div>0xbff5eb54 M WeakMessageSend>cull: 397858000: a(n) WeakMessageSend</div><div>0xbff5eb70 M WeakMessageSend>cull:cull: 397858000: a(n) WeakMessageSend</div><div>0xbff5eb94 M [] in WeakAnnouncementSubscription>deliver: 397858036: a(n) WeakAnnouncementSubscription</div>
<div>0xbff5ebb0 M BlockClosure>on:do: 402448660: a(n) BlockClosure</div><div>0xbff5ebd0 M BlockClosure>on:fork: 402448660: a(n) BlockClosure</div><div>0xbff5ebf0 M WeakAnnouncementSubscription>deliver: 397858036: a(n) WeakAnnouncementSubscription</div>
<div>0xbff5ec14 M [] in SubscriptionRegistry>deliver:to: 363283080: a(n) SubscriptionRegistry</div><div>0xbff5ec34 M BlockClosure>ifCurtailed: 402448516: a(n) BlockClosure</div><div>0xbff5ec58 M [] in SubscriptionRegistry>deliver:to: 363283080: a(n) SubscriptionRegistry</div>
<div>0xbff5ec78 M OrderedCollection>do: 402427332: a(n) OrderedCollection</div><div>0xbff5ec94 M SubscriptionRegistry>deliver:to: 363283080: a(n) SubscriptionRegistry</div><div>0xbff5ecb8 M SubscriptionRegistry>deliver: 363283080: a(n) SubscriptionRegistry</div>
<div>0xbff5ecd8 M Announcer>announce: 363283068: a(n) Announcer</div><div>0xbff5ecf8 M GroupsHolder>addADynamicClassGroupSilentlyNamed:block: 402407104: a(n) GroupsHolder</div><div>0xbff5ed1c M Nautilus class>buildGroupManager 363174868: a(n) Nautilus class</div>
<div>0xbff5ed34 M Nautilus class>groupsManager 363174868: a(n) Nautilus class</div><div>0xbff5ed4c M Nautilus>groupsManager 397856104: a(n) Nautilus</div><div><br></div><br><div class="gmail_quote">On Mon, Feb 27, 2012 at 1:15 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">let me retry *with* the attachment :(<br><br><div class="gmail_quote"><div>On Mon, Feb 27, 2012 at 12:03 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>></span> wrote:<br>
</div><div><div></div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div>On 27 February 2012 10:53, Mariano Martinez Peck <<a href="mailto:marianopeck@gmail.com" target="_blank">marianopeck@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Feb 27, 2012 at 5:20 AM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br>
>><br>
>> Hi Mariano,<br>
>><br>
>> On Sun, Feb 26, 2012 at 8:58 AM, Mariano Martinez Peck <<a href="mailto:marianopeck@gmail.com" target="_blank">marianopeck@gmail.com</a>> wrote:<br>
>>><br>
>>><br>
>>> 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:<br>
>>> <a href="https://gforge.inria.fr/frs/download.php/30280/Marea.104-Crash.1.image.zip" target="_blank">https://gforge.inria.fr/frs/download.php/30280/Marea.104-Crash.1.image.zip</a><br>
>>><br>
>>> What the image is running at startup that causes the crash is:<br>
>>><br>
>>> | nautilus model ui|<br>
>>> Nautilus instVarNamed: 'groups' put: nil.<br>
>>> model := Nautilus open.<br>
>>> ui := model ui.<br>
>>> ui groupsButtonAction.<br>
>>><br>
>>> 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)<br>
>>><br>
>>> while (theSP <= frameRcvrOffset) {<br>
>>> oop = longAt(theSP);<br>
>>> if (!((oop & 1))) {<br>
>>> longAtput(theSP, remap(oop));<br>
>>> }<br>
>>> theSP += BytesPerWord;<br>
>>> }<br>
>>><br>
>>><br>
>>> Any ideas?<br>
>><br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
><br>
> wow, I never imagine about that.<br>
><br>
>><br>
>> a) Looks like weakRoots' size should be configurable either via a start-up flag or an image header constant (with e.g. vmParameter accessors).<br>
><br>
><br>
> yes, with vmParameter would be nice, like the external semaphore table.<br>
><br>
>><br>
>><br>
>> b) overflowing the weakRoots table (and possibly other tables) should probably cause the VM to abort with a useful error message.<br>
>><br>
><br>
> please! :)<br>
><br>
> I have check in the image, before reproducing the bug, and it is not that bad:<br>
><br>
> WeakMessageSend instanceCount 755.<br>
> WeakAnnouncementSubscription instanceCount 538<br>
><br>
> 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?<br>
><br>
><br>
</div></div>hmm.. i hardly believe that UI needs such amount of weak messages to<br>
wire the stuff.. but it is hard to tell, since i'm not an author.<br></blockquote><div><br></div><div><br></div></div></div><div><span style="border-collapse:collapse;font-family:arial,sans-serif;font-size:13px"><div>
Take a look at the attached. It is taken form the image at a point where an incrementalGC is performed when the weakRootTable has 6000 or more elements. It shows a very deep call stack full of WeakAnnouncementSubscriptions.</div>
<div style="color:rgb(80,0,80)"></div></span><div><br></div><div> </div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also, answering Stephane's question: AFAIK, a weak roots table size is<div>
<br>
not liearly depending on the total number of all weak containers in<br>
your image.<br></div></blockquote><div><br></div><div>The number of weak containers does define an upper bound on the size of the table. It doesn't necessarily correlate to how many containers are encountered in an incremental GC.</div>
<div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But i might be wrong.<br>
Eliot, can you please explain how this weak roots table populated and<br>
what triggers addition of new element(s) to it, and freeing the entry.<br></blockquote><div><br></div></div><div><span style="border-collapse:collapse;font-family:arial,sans-serif;font-size:13px"><div style="color:rgb(80,0,80)">
<div><br></div></div><div>So when an incremental GC is performed, any weak collections encountered must be scanned later, after the mark phase of non-objects have completed, so that the GC can discover which elements of weak collections are unmarked and nil these collections. So in markAndTrace any encountered weak objects get added as "roots" to the weakRootsTable. Later (either in incrementalGC or fullGC) the weak table is processed and unmarked referents in the weak arrays in the weak table are nilled. Hence the weak table fills during the mark phase and is emptied in the nilling phase.</div>
<div><br></div><div>But in reading the code more carefully I notice that the weak roots table is not used during a full GC. Instead, during a fullGC nilling is done as each weak container is encountered. I don't understand how this works yet. Anyone care to explain?</div>
</span></div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And is the weak roots table size limit reasonably good? Needless to<br>
say, that nobody likes when system hits the wall of hardcoded limits.<br></blockquote><div><br></div><div><br></div></div><div><span style="border-collapse:collapse;font-family:arial,sans-serif;font-size:13px">Hmmm... In VisualWorks, which has a two-space copying generational GC there is no weak root table during incremental GC. Instead the list of weak objects is threaded through the corpses left behind in from space. So at least for some GC designs a weak roots table isn't even needed. I will copy this scheme in my new object representation/GC. But for now I think just providing a parameter to determine the maximum size is sufficient.</span></div>
<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font color="#888888"><br>
--<br>
Best regards,<br>
Igor Stasenko.<br>
</font></blockquote></div></div><font color="#888888"><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>
</font></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>
</div>