The MapCache is not registered for finalization, IIRC. The new WeakKeyDictionary does not work reliably without being registered. See also http://code.google.com/p/pharo/issues/detail?id=1628. I remember wanting to retract some parts of comment #2 after further investigation, but I no longer remember which :) Should give some pointers though. Cheers, Henry On 31.12.2009 17:41, Martin McClure wrote:
Stéphane Ducasse wrote:
Probably the changes of Martin von Lowis. I imagine that when marcus is bad from holidays he can tell us more.
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 ?
Where did you get your image from? If you had an older image and applied updates the corruption may not be there.
For me, it reproduces 100% in a downloaded pharo1.1-11112-alphadev09.12.2 image, and it also reproduced it in that image with all updates applied, and I may have also had this problem in the latest core download.
Regards,
-Martin
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project