On Sat, 2 Jan 2010, Schwab,Wilhelm K wrote:

Eliot,

Squeak's weak collections are, weak, in more ways than one.  They are not thread safe, 
and not clean up after finalization, which is of course how they get away without thread 
safety.  See "Thread-safe collections" starting on 23 Oct from this list.  I 
will post, as a separate message with attachment, something that I **threw together** to 
try to address some of the missing features.  I have not had time to test it separately 
from the rest of my image, so please start slowly and let me know if you have any 
problems.

All collections are intentionally not thread-safe (except SharedQueue and WeakRegistry). All weak collections clean up themselves in a lazy fashion. I think there's no way to ensure that garbage collected objects are immediately removed from weak collections without vm changes.


Levente




Bill



________________________________
From: [email protected] 
[mailto:[email protected]] On Behalf Of Eliot Miranda
Sent: Saturday, January 02, 2010 6:08 PM
To: [email protected]
Subject: Re: [Pharo-project] Can't debug in 1.1



On Thu, Dec 31, 2009 at 2:33 AM, Marcus Denker 
<[email protected]<mailto:[email protected]>> wrote:

On Dec 31, 2009, at 9:50 AM, Stéphane Ducasse wrote:

Probably the changes of Martin von Lowis.

Yes. The changeset had code to migrate all instances... it might be that the 
debugger's use
of WeakKeyDictionary was added by Eliot? This would explain why it was not 
migrated.

Yes, DebuggerMethodMap is mine. A DebuggerMethodMap maps between the vector of 
temp names in the lower right-hand debugger window and temp locations in method 
activations.  This is much more complex using closures tan blue-book blocks 
since in-scope temps are spread from a closure through its nested closures out 
to the home method.  The cache holds the maps for the most recent N methods 
inspected with the debugger (N=16).  The cache is weak so as not to hold onto 
methods that get deleted or redefined.

As far as registering the cache for finalization or not, I would defer to 
someone familiar with Squeak weak collections.  I think I'm right in thinking 
that in VW a weak dictionary will be automatically finalized and will keep its 
tally correct.  One only needs to register for finalization if something needs 
to happen besides simply removing elements.  So when I implemented this in 
Squeak I could easily have got things wrong.


I suggest to just do the reset in a postscript in one of the next updates, and 
it's fixed.


I imagine that when marcus is bad from holidays he can tell us more.


I'm back... kind of. Decided not to travel to south germany this morning after 
moving boxes
for 3 days... better to have an 
IKEA-unboxing-relaxing-reading-emails-hacking-weekend.

      Marcus



Now I try to reproduce it in 11128.

I put a self halt in a method and execute the method.
And I got no problem.
After I tried to select 'self halt' + doit in the debugger itself and it worked 
too.

Did you have a way reproduce it systematically ?

Stef
On Dec 31, 2009, at 4:17 AM, Martin McClure wrote:

This one's pretty nasty.

Symptom:

The debugger in recent and current 1.1 images is completely broken.

To reproduce (save your image first!):

"self halt" doit. It goes into an infinite loop, and if there's a way to
get out of that without killing the VM I'd like to know about it. Alt-.
works, but just tries to open another debugger, which goes into another
infinite loop, etc.



Cause:

DebuggerMethodMap>MapCache is a WeakIdentityKeyDictionary, but it is
corrupt. It has an array of 22 nils, expired is 0, so it contains
nothing, but tally=16.

This causes MapCache to lie about its size.

This drives DebuggerMethodMap class>>cacheDebugMap:forMethod: into an
infinite loop, the whileTrue: condition is always true, it keeps trying
to remove non-existent elements to get the size to be less than 16 but
the size is always 16.

I don't see any obvious code paths to get into this state. I suspect it
may have been left in this state when weak collections were updated with
the new code not too long ago.


Cure:

In an inspector, set tally=0. Debuggers then work again.

Not sure how to package this as a slice, so I'll leave the update to
someone else, and get back to hashing, which was hard when every
walkback froze my system :-)


Regards,

-Martin

_______________________________________________
Pharo-project mailing list
[email protected]<mailto:[email protected]>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[email protected]<mailto:[email protected]>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[email protected]<mailto:[email protected]>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to