Smalltalk › Pharo › Pharo Smalltalk Developers

Can't debug in 1.1

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

Martin McClure-2

Can't debug in 1.1

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stéphane Ducasse

Re: Can't debug in 1.1

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 ?

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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

Marcus Denker-4

Re: Can't debug in 1.1

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.

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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

Stéphane Ducasse

Re: Can't debug in 1.1

On Dec 31, 2009, at 11:33 AM, Marcus Denker 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.
>
> 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.

If you need tools let me know ;)

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

Martin McClure-2

Re: Can't debug in 1.1

In reply to this post by Stéphane Ducasse

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Henrik Sperre Johansen

Re: Can't debug in 1.1

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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>

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

Stéphane Ducasse

Re: Can't debug in 1.1

In reply to this post by Martin McClure-2

I took 11106 and press updates....

> 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

Excellent!

> 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.

in 11117-core I could not reproduce it.
But in 11112-alphadev it nicely crash!

Stef

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

Martin McClure-2

Re: Can't debug in 1.1

In reply to this post by Henrik Sperre Johansen

Henrik Sperre Johansen wrote:
> 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.

I *think* it's OK for MapCache to not be registered, because before each
potential add or remove, DebuggerMethodMap sends #finalizeValues to it.

And I also had some doubts about the code described in issue 1628, but I
don't see how it could have caused this particular corruption, where the
array is all nils yet tally is > 0.

Regards,

-Martin

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

Eliot Miranda-2

Re: Can't debug in 1.1

In reply to this post by Marcus Denker-4

On Thu, Dec 31, 2009 at 2:33 AM, Marcus Denker <[hidden email]> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

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

Schwab,Wilhelm K

Re: Can't debug in 1.1

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.

Bill

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

On Thu, Dec 31, 2009 at 2:33 AM, Marcus Denker <[hidden email]> 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.

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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

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

Schwab,Wilhelm K

Re: Can't debug in 1.1

Eliot,

The promised code. Again, this is not groomed for release, but you are welcome to use/improve as you see fit.

Bill

________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Schwab,Wilhelm K [[hidden email]]
Sent: Saturday, January 02, 2010 6:57 PM
To: [hidden email]
Subject: Re: [Pharo-project] Can't debug in 1.1

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.

Bill

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

On Thu, Dec 31, 2009 at 2:33 AM, Marcus Denker <[hidden email]<mailto:[hidden email]>> 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
>> [hidden email]<mailto:[hidden email]>
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]<mailto:[hidden email]>
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

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

SharedLookupTable.st (5K) Download Attachment

Levente Uzonyi-2

Re: Can't debug in 1.1

In reply to this post by Schwab,Wilhelm K

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: [hidden email] [mailto:[hidden email]] On Behalf Of Eliot Miranda
> Sent: Saturday, January 02, 2010 6:08 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] Can't debug in 1.1
>
>
>
> On Thu, Dec 31, 2009 at 2:33 AM, Marcus Denker <[hidden email]<mailto:[hidden email]>> 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
>>> [hidden email]<mailto:[hidden email]>
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]<mailto:[hidden email]>
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]<mailto:[hidden email]>
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>

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

Stéphane Ducasse

Re: [Pharo-project] Can't debug in 1.1

In reply to this post by Martin McClure-2

Hi martin

the last release 11174 got the fix in (sorry for the delay).
Could you let us know if this is ok?

Stef

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

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