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