Smalltalk › Pharo › Pharo Smalltalk Developers

About the infinite debugger

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

28 messages Options

tesonep@gmail.com

Re: [rmod] About the infinite debugger

Hello,

We have implemented a "patch" for Pharo 7, that is already integrated. I have created a slice to backport the "patch" to Pharo6.

Basically, the previous situation is the following:

- In the normal execution everything works, the problem is during the execution of over.

- To implement over the debugger uses Context >> runUntilErrorOrReturnFrom:

- This method adds a new context to handle exceptions in the stack trace. It takes the receiver and replaces the sender of the context with a new context handling the exceptions.

- This error handling (using on:do:) handles UnhandledError and Halt.

- When the MNU error gots to the nil context a UnhandledError is signal from the last signalling context of the MNU error.

- This solution works correctly when it is not debugged when running a test.

When we are running a tests there is a slight difference:

- There is one more on:do: context that catches all the Errors. This on:do just do something and pass the exception.

- As the UnhandledError is signal from the last signalling context (the one with the pass) it is not passing in the context inserted by runUntilErrorOrReturnFrom:, generating an infinite debugger as the exception is never catch.

- This only happens with the MNU, as it retries to send the same message every time.

I think the solution is to signal the UnhandledError always from the original signalling context. However, I am not sure to perform that change as it modifies the behaviour of exceptions and there are not proper tests to guarantee the expected behavior.

I hope the problem is well explained, if it is not please ask me to clarify any point.

Cheers,

On Mon, Aug 6, 2018 at 9:59 AM Guillermo Polito <[hidden email]> wrote:

Hi Steven,

The thing about your fix was mainly that it only worked for the case of running tests. We could however reproduce this bug from a playground too.

At first, replacing #pass to #debug looked like a hack to me :) Just looking at the code of runCaseForDebug:, I felt the correct thing to do there was to use #pass (and let any potential caller handle the exception if he wants).
Otherwise, we should be able to understand:
- can #pass be used? is it buggy?
- does it work on any case or it should be avoided in some cases?
- and how can we fix it (or at least document it?)?

But still, I think you were in the right direction too, because your fix shows a good intuition too: both #pass and #debug will do different things with the exception.
- #pass will **resignal** it from the current context,
- #debug will just open a debugger on it.

So that means that probably there was a problem when the exception was handled in a calling context.

On Mon, Aug 6, 2018 at 12:29 AM Steven Costiou <[hidden email]> wrote:

Hi,

i had no answer to my comments on fogbuz (one of the first) so i assumed it was not a good idea.

In the usecases i used to reproduce the bug, replacing "ex pass" by "ex debug" in runCaseForDebug:solved the problem. See the analysis on fogbuz.

Did not have any side effect, but i do not know enough about the system and maybe it does. I think i already asked about that somewhere (here or on discord) but no answers.

But maybe it is wrong to do that? I'd be happy to have feedback on that.

Steven.

Le 2018-08-05 22:27, Tim Mackinnon a écrit :

Guys - this really needs attention - I've spend hours now trying to debug some code and most of it is in closing infinite debuggers. It makes a mockery of our tagline - "awesome debugging". And the extra irony is that I'm debugging some file path stuff for exercism, to make it easier for hopefully more people to learn Pharo.

How can we get this fixed?

Tim

On 2 Aug 2018, at 21:44, Norbert Hartl <[hidden email]> wrote:

bump

Am 04.07.2018 um 02:28 schrieb Martin McClure <[hidden email]>:

On 07/03/2018 05:02 PM, Martin McClure wrote:
On 06/29/2018 07:48 AM, Guillermo Polito wrote:
I know that the exception handling/debugging has been modified several
times in the latest years (some refactorings, hiding contexts...), we
unfortunately don't have tests for it, so I'd like some more pair of
eyes on it. Ben, Martin could you take a look?

Hi Guille,
I'm just back from vacation last week, and about to go on vacation for
another week, but I'll see what I can see.
About the primitive pragmas for context-marking, I think some of those
were changed for the exception handling fix that Andres and I did a few
years back, so *could* be involved in this. I'd hate to see regression
in the exception handling in an attempt to fix this bug.

After a look at at the pull request, I'm quite sure that removing the
prim 199 marker is the wrong thing to do. Thanks, Pablo, for restoring
it! The start of execution of exception handlers must be marked in order
for #findNextHandlerContext to work correctly. If these contexts are not
marked, exceptions signaled from inside an exception handler can find
the wrong handler. See the code and comment in #findNextHandlerContext.

I'm afraid that I cannot immediately help with the debugger problem,
since I don't know the debugger nearly as well as I do the exception
handling code, and I'm going on vacation for a week in 20 minutes. :-)
Perhaps when I get back I can take a look at it if it is still a problem
by then.

Regards,
-Martin

--

Guille Polito
Research Engineer
Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Pablo Tesone.
[hidden email]

Tim Mackinnon

Re: [rmod] About the infinite debugger

This is a good writeup - however I get infinite debuggers when not running tests too? So I’m wondering if there are multiple problems - or if this hints at a wider issue?

Its not all of the time - but when you get it it, it seems to happen over and over again. Its possible its when using step-over though - so I will keep an eye on that.

Tim

On 7 Aug 2018, at 10:51, [hidden email] wrote:

Hello,
We have implemented a "patch" for Pharo 7, that is already integrated. I have created a slice to backport the "patch" to Pharo6.

Basically, the previous situation is the following:

- In the normal execution everything works, the problem is during the execution of over.
- To implement over the debugger uses Context >> runUntilErrorOrReturnFrom:
- This method adds a new context to handle exceptions in the stack trace. It takes the receiver and replaces the sender of the context with a new context handling the exceptions.
- This error handling (using on:do:) handles UnhandledError and Halt.
- When the MNU error gots to the nil context a UnhandledError is signal from the last signalling context of the MNU error.
- This solution works correctly when it is not debugged when running a test.

When we are running a tests there is a slight difference:

- There is one more on:do: context that catches all the Errors. This on:do just do something and pass the exception.
- As the UnhandledError is signal from the last signalling context (the one with the pass) it is not passing in the context inserted by runUntilErrorOrReturnFrom:, generating an infinite debugger as the exception is never catch.
- This only happens with the MNU, as it retries to send the same message every time.

I think the solution is to signal the UnhandledError always from the original signalling context. However, I am not sure to perform that change as it modifies the behaviour of exceptions and there are not proper tests to guarantee the expected behavior.

I hope the problem is well explained, if it is not please ask me to clarify any point.

Cheers,

On Mon, Aug 6, 2018 at 9:59 AM Guillermo Polito <[hidden email]> wrote:
Hi Steven,

The thing about your fix was mainly that it only worked for the case of running tests. We could however reproduce this bug from a playground too.

At first, replacing #pass to #debug looked like a hack to me :) Just looking at the code of runCaseForDebug:, I felt the correct thing to do there was to use #pass (and let any potential caller handle the exception if he wants).
Otherwise, we should be able to understand:
- can #pass be used? is it buggy?
- does it work on any case or it should be avoided in some cases?
- and how can we fix it (or at least document it?)?

But still, I think you were in the right direction too, because your fix shows a good intuition too: both #pass and #debug will do different things with the exception.
- #pass will **resignal** it from the current context,
- #debug will just open a debugger on it.

So that means that probably there was a problem when the exception was handled in a calling context.

On Mon, Aug 6, 2018 at 12:29 AM Steven Costiou <[hidden email]> wrote:
Hi,
i had no answer to my comments on fogbuz (one of the first) so i assumed it was not a good idea.
In the usecases i used to reproduce the bug, replacing "ex pass" by "ex debug" in runCaseForDebug:solved the problem. See the analysis on fogbuz.
Did not have any side effect, but i do not know enough about the system and maybe it does. I think i already asked about that somewhere (here or on discord) but no answers.
But maybe it is wrong to do that? I'd be happy to have feedback on that.
Steven.
Le 2018-08-05 22:27, Tim Mackinnon a écrit :

Guys - this really needs attention - I've spend hours now trying to debug some code and most of it is in closing infinite debuggers. It makes a mockery of our tagline - "awesome debugging". And the extra irony is that I'm debugging some file path stuff for exercism, to make it easier for hopefully more people to learn Pharo.

How can we get this fixed?

Tim

On 2 Aug 2018, at 21:44, Norbert Hartl <[hidden email]> wrote:

bump

Am 04.07.2018 um 02:28 schrieb Martin McClure <[hidden email]>:

On 07/03/2018 05:02 PM, Martin McClure wrote:
On 06/29/2018 07:48 AM, Guillermo Polito wrote:
I know that the exception handling/debugging has been modified several
times in the latest years (some refactorings, hiding contexts...), we
unfortunately don't have tests for it, so I'd like some more pair of
eyes on it. Ben, Martin could you take a look?

Hi Guille,
I'm just back from vacation last week, and about to go on vacation for
another week, but I'll see what I can see.
About the primitive pragmas for context-marking, I think some of those
were changed for the exception handling fix that Andres and I did a few
years back, so *could* be involved in this. I'd hate to see regression
in the exception handling in an attempt to fix this bug.

After a look at at the pull request, I'm quite sure that removing the
prim 199 marker is the wrong thing to do. Thanks, Pablo, for restoring
it! The start of execution of exception handlers must be marked in order
for #findNextHandlerContext to work correctly. If these contexts are not
marked, exceptions signaled from inside an exception handler can find
the wrong handler. See the code and comment in #findNextHandlerContext.

I'm afraid that I cannot immediately help with the debugger problem,
since I don't know the debugger nearly as well as I do the exception
handling code, and I'm going on vacation for a week in 20 minutes. :-)
Perhaps when I get back I can take a look at it if it is still a problem
by then.

Regards,
-Martin

--

Guille Polito
Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - http://www.cnrs.fr

Web: http://guillep.github.io
Phone: +33 06 52 70 66 13

--
Pablo Tesone.
[hidden email]

tesonep@gmail.com

Re: [rmod] About the infinite debugger

Also, we have found that once the problem starts the image will present bad behavior from that on.

Sometimes it can be fixed by restarting the UIProcess, but it is a brute force process. You have to do it many times.

It is true that we cannot assert that the bug is not in other places.

On Tue, Aug 7, 2018 at 11:14 AM Tim Mackinnon <[hidden email]> wrote:

This is a good writeup - however I get infinite debuggers when not running tests too? So I’m wondering if there are multiple problems - or if this hints at a wider issue?

Its not all of the time - but when you get it it, it seems to happen over and over again. Its possible its when using step-over though - so I will keep an eye on that.

Tim

On 7 Aug 2018, at 10:51, [hidden email] wrote:

Hello,
We have implemented a "patch" for Pharo 7, that is already integrated. I have created a slice to backport the "patch" to Pharo6.

Basically, the previous situation is the following:

- In the normal execution everything works, the problem is during the execution of over.
- To implement over the debugger uses Context >> runUntilErrorOrReturnFrom:
- This method adds a new context to handle exceptions in the stack trace. It takes the receiver and replaces the sender of the context with a new context handling the exceptions.
- This error handling (using on:do:) handles UnhandledError and Halt.
- When the MNU error gots to the nil context a UnhandledError is signal from the last signalling context of the MNU error.
- This solution works correctly when it is not debugged when running a test.

When we are running a tests there is a slight difference:

- There is one more on:do: context that catches all the Errors. This on:do just do something and pass the exception.
- As the UnhandledError is signal from the last signalling context (the one with the pass) it is not passing in the context inserted by runUntilErrorOrReturnFrom:, generating an infinite debugger as the exception is never catch.
- This only happens with the MNU, as it retries to send the same message every time.

I think the solution is to signal the UnhandledError always from the original signalling context. However, I am not sure to perform that change as it modifies the behaviour of exceptions and there are not proper tests to guarantee the expected behavior.

I hope the problem is well explained, if it is not please ask me to clarify any point.

Cheers,

On Mon, Aug 6, 2018 at 9:59 AM Guillermo Polito <[hidden email]> wrote:
Hi Steven,

The thing about your fix was mainly that it only worked for the case of running tests. We could however reproduce this bug from a playground too.

At first, replacing #pass to #debug looked like a hack to me :) Just looking at the code of runCaseForDebug:, I felt the correct thing to do there was to use #pass (and let any potential caller handle the exception if he wants).
Otherwise, we should be able to understand:
- can #pass be used? is it buggy?
- does it work on any case or it should be avoided in some cases?
- and how can we fix it (or at least document it?)?

But still, I think you were in the right direction too, because your fix shows a good intuition too: both #pass and #debug will do different things with the exception.
- #pass will **resignal** it from the current context,
- #debug will just open a debugger on it.

So that means that probably there was a problem when the exception was handled in a calling context.

On Mon, Aug 6, 2018 at 12:29 AM Steven Costiou <[hidden email]> wrote:
Hi,
i had no answer to my comments on fogbuz (one of the first) so i assumed it was not a good idea.
In the usecases i used to reproduce the bug, replacing "ex pass" by "ex debug" in runCaseForDebug:solved the problem. See the analysis on fogbuz.
Did not have any side effect, but i do not know enough about the system and maybe it does. I think i already asked about that somewhere (here or on discord) but no answers.
But maybe it is wrong to do that? I'd be happy to have feedback on that.
Steven.
Le 2018-08-05 22:27, Tim Mackinnon a écrit :

Guys - this really needs attention - I've spend hours now trying to debug some code and most of it is in closing infinite debuggers. It makes a mockery of our tagline - "awesome debugging". And the extra irony is that I'm debugging some file path stuff for exercism, to make it easier for hopefully more people to learn Pharo.

How can we get this fixed?

Tim

On 2 Aug 2018, at 21:44, Norbert Hartl <[hidden email]> wrote:

bump

Am 04.07.2018 um 02:28 schrieb Martin McClure <[hidden email]>:

On 07/03/2018 05:02 PM, Martin McClure wrote:
On 06/29/2018 07:48 AM, Guillermo Polito wrote:
I know that the exception handling/debugging has been modified several
times in the latest years (some refactorings, hiding contexts...), we
unfortunately don't have tests for it, so I'd like some more pair of
eyes on it. Ben, Martin could you take a look?

Hi Guille,
I'm just back from vacation last week, and about to go on vacation for
another week, but I'll see what I can see.
About the primitive pragmas for context-marking, I think some of those
were changed for the exception handling fix that Andres and I did a few
years back, so *could* be involved in this. I'd hate to see regression
in the exception handling in an attempt to fix this bug.

After a look at at the pull request, I'm quite sure that removing the
prim 199 marker is the wrong thing to do. Thanks, Pablo, for restoring
it! The start of execution of exception handlers must be marked in order
for #findNextHandlerContext to work correctly. If these contexts are not
marked, exceptions signaled from inside an exception handler can find
the wrong handler. See the code and comment in #findNextHandlerContext.

I'm afraid that I cannot immediately help with the debugger problem,
since I don't know the debugger nearly as well as I do the exception
handling code, and I'm going on vacation for a week in 20 minutes. :-)
Perhaps when I get back I can take a look at it if it is still a problem
by then.

Regards,
-Martin

--

Guille Polito
Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - http://www.cnrs.fr

Web: http://guillep.github.io
Phone: +33 06 52 70 66 13

--
Pablo Tesone.
[hidden email]

Pablo Tesone.
[hidden email]

Paul DeBruicker

Re: [rmod] About the infinite debugger

In reply to this post by Tim Mackinnon

Hi Tim,

Just in the event you didn't know there is an option in the World menu to
close all the open debuggers.

Its in the "Windows" section, about half way down.

Paul

Tim Mackinnon wrote

> ...
>
> On the plus side - its rare that you crash you image and then have to
> recover changes - but its just annoying when it gets in the way of
> debugging. ITs not just all the windows, its also the fact that none of
> the debugger windows actually puts you in a useful stack where you can see
> the problem - they are all stuck on DNU with a single line stack.
>
> Tim
>
> ...

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Tim Mackinnon

Re: [rmod] About the infinite debugger

Thanks Paul - I’d forgotten about that option (been using the close all to right option).

It’s just jarring - but worse is that none of the debuggers (even the first one) having anything useful in them... other than the error msg in the title. So you have to start all over again.

Still, it sounds like we are honing in on something.

Tim

Sent from my iPhone

> On 7 Aug 2018, at 19:38, Paul DeBruicker <[hidden email]> wrote:
>
> Hi Tim,
>
> Just in the event you didn't know there is an option in the World menu to
> close all the open debuggers.
>
> Its in the "Windows" section, about half way down.
>
>
> Paul
>
>
>
> Tim Mackinnon wrote
>> ...
>>
>> On the plus side - its rare that you crash you image and then have to
>> recover changes - but its just annoying when it gets in the way of
>> debugging. ITs not just all the windows, its also the fact that none of
>> the debugger windows actually puts you in a useful stack where you can see
>> the problem - they are all stuck on DNU with a single line stack.
>>
>> Tim
>>
>> ...
>
>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

Denis Kudriashov

Re: About the infinite debugger

In reply to this post by Guillermo Polito

Hi.

Good job guys. I just checked my case 19848. And it is now fixed.

Thanks

2018-06-29 15:48 GMT+01:00 Guillermo Polito <[hidden email]>:

Hi all,

during today's sprint we have been working with lots of people on the infinite debugger problem (https://pharo.fogbugz.com/f/cases/22085/). We have checked the emails sent in the latest month. Then, together with Quentin, Pablo, Pavel, Yoan we have been discussing and testing hypothesis all day. We have been also comparing the debuggers code between pharo 3/4 (where the bug was is present) and pharo 7, but this was not necessarily straight forward as the code is not the same and there is no easy diff...

AAAAND, we have found that the problem may come from a wrong pragma marker. Just removing that pragma gives us back the same behaviour as in Pharo 3/4. :D

https://github.com/pharo-project/pharo/pull/1621

I know that the exception handling/debugging has been modified several times in the latest years (some refactorings, hiding contexts...), we unfortunately don't have tests for it, so I'd like some more pair of eyes on it. Ben, Martin could you take a look?

Thanks all for the fish,
Guille

Denis Kudriashov

Re: About the infinite debugger

I have more special cases where debugger hangs:

19662, 19928, 20274.

They are still relevant

2018-08-07 22:01 GMT+01:00 Denis Kudriashov <[hidden email]>:

Hi.

Good job guys. I just checked my case 19848. And it is now fixed.

Thanks

2018-06-29 15:48 GMT+01:00 Guillermo Polito <[hidden email]>:
Hi all,

during today's sprint we have been working with lots of people on the infinite debugger problem (https://pharo.fogbugz.com/f/cases/22085/). We have checked the emails sent in the latest month. Then, together with Quentin, Pablo, Pavel, Yoan we have been discussing and testing hypothesis all day. We have been also comparing the debuggers code between pharo 3/4 (where the bug was is present) and pharo 7, but this was not necessarily straight forward as the code is not the same and there is no easy diff...

AAAAND, we have found that the problem may come from a wrong pragma marker. Just removing that pragma gives us back the same behaviour as in Pharo 3/4. :D

https://github.com/pharo-project/pharo/pull/1621

I know that the exception handling/debugging has been modified several times in the latest years (some refactorings, hiding contexts...), we unfortunately don't have tests for it, so I'd like some more pair of eyes on it. Ben, Martin could you take a look?

Thanks all for the fish,
Guille

tesonep@gmail.com

Re: About the infinite debugger

Yes, we have to check all the scenarios.

The problems with the UI process is not resolved at all.

On Tue, Aug 7, 2018 at 11:11 PM Denis Kudriashov <[hidden email]> wrote:

I have more special cases where debugger hangs:
19662, 19928, 20274.
They are still relevant

2018-08-07 22:01 GMT+01:00 Denis Kudriashov <[hidden email]>:
Hi.

Good job guys. I just checked my case 19848. And it is now fixed.

Thanks

2018-06-29 15:48 GMT+01:00 Guillermo Polito <[hidden email]>:
Hi all,

during today's sprint we have been working with lots of people on the infinite debugger problem (https://pharo.fogbugz.com/f/cases/22085/). We have checked the emails sent in the latest month. Then, together with Quentin, Pablo, Pavel, Yoan we have been discussing and testing hypothesis all day. We have been also comparing the debuggers code between pharo 3/4 (where the bug was is present) and pharo 7, but this was not necessarily straight forward as the code is not the same and there is no easy diff...

AAAAND, we have found that the problem may come from a wrong pragma marker. Just removing that pragma gives us back the same behaviour as in Pharo 3/4. :D

https://github.com/pharo-project/pharo/pull/1621

I know that the exception handling/debugging has been modified several times in the latest years (some refactorings, hiding contexts...), we unfortunately don't have tests for it, so I'd like some more pair of eyes on it. Ben, Martin could you take a look?

Thanks all for the fish,
Guille

Pablo Tesone.
[hidden email]