Re: [Pharo-dev] About the infinite debugger

[teso...@gmail.com]

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 
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 :
>
>> 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 :
>>
>>> 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...
>>>
>>> ND, 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.
teso...@gmail.com

Re: [Pharo-dev] About the infinite debugger

[Denis Kudriashov]

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 :

> 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 :
>
>> 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...
>>
>> ND, 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
>>
>
>

Re: [Pharo-dev] About the infinite debugger

[Denis Kudriashov]

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 :

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

Re: [Pharo-dev] About the infinite debugger

[Guillermo Polito]

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 
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  wrote:
>
> bump
>
> Am 04.07.2018 um 02:28 schrieb Martin McClure :
>
> 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

Re: [Pharo-dev] About the infinite debugger

[Esteban A. Maringolo]

El dom., 5 de ago. de 2018 17:28, Tim Mackinnon  escribió:

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


We can change the tagline to "limitless debugging".

Re: [Pharo-dev] About the infinite debugger

[Steven Costiou]

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  wrote:
> 
> bump
> 
> Am 04.07.2018 um 02:28 schrieb Martin McClure :
> 
> 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

  

Re: [Pharo-dev] About the infinite debugger

[Tim Mackinnon]

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  wrote:
> 
> bump
> 
>> Am 04.07.2018 um 02:28 schrieb Martin McClure :
>> 
>>> 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
>> 
> 

Re: [Pharo-dev] About the infinite debugger

[Norbert Hartl]

bump

> Am 04.07.2018 um 02:28 schrieb Martin McClure :
> 
>> 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
> 

Re: [Pharo-dev] About the infinite debugger

[Martin McClure]

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

Re: [Pharo-dev] About the infinite debugger

[Martin McClure]

On 06/29/2018 07:48 AM, Guillermo Polito wrote:
> 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...
>
> ND, 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?
>

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.

Regards,
-Martin

Re: [Pharo-dev] About the infinite debugger

[Marcus Denker]

> On 30 Jun 2018, at 02:56, Eliot Miranda  wrote:
> 
> Hi Guille,
> 
> On Jun 29, 2018, at 7:48 AM, Guillermo Polito  > wrote:
> 
>> 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...
> 
> This is frustrating.  I can’t see the issue cuz I can’t login to fogbugz.  
> Having to login to read an issue is a major flaw.  I can see it makes sense 
> for submitting, but fir merely browsing it should be unacceptable.  That 
> said...
> 
> The pragma  actually sets the primitive number in the method, 
> so it it not merely a pragma; it alters bits in the method that the VM uses 
> to search for handler contexts.  So why one would do that for evaluateSignal: 
> makes no sense to me. The primitive should be set only in on:do: or something 
> very similar (for example one could imagine adding on:or:do: instead of using 
> , to construct an ExceptionSet).  So I think removing it from evaluateSignal: 
> is definitely the right thing to do.
> 
> As far as tests for findNextHandlerFrom:, this is tested implicitly by any 
> nested exception test so I expect you have several tests affected.  Clément 
> points to a test that fails when not including  in 
> evaluateSignal: so more investigation is necessary.  Difficult to do while 
> bugs are hidden in fogbugz.  When are they going to migrate the github where 
> they belong?

Yes, the idea was to move the issue tracker to GitHub… but after the release is 
done (as it requires changing again some things).
The closed-ness of fugbugz is really annoying.

Marcus

Re: [Pharo-dev] About the infinite debugger

[Eliot Miranda]

Hi Guille,

> On Jun 29, 2018, at 7:48 AM, Guillermo Polito  
> wrote:
> 
> 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...

This is frustrating.  I can’t see the issue cuz I can’t login to fogbugz.  
Having to login to read an issue is a major flaw.  I can see it makes sense for 
submitting, but fir merely browsing it should be unacceptable.  That said...

The pragma  actually sets the primitive number in the method, 
so it it not merely a pragma; it alters bits in the method that the VM uses to 
search for handler contexts.  So why one would do that for evaluateSignal: 
makes no sense to me. The primitive should be set only in on:do: or something 
very similar (for example one could imagine adding on:or:do: instead of using , 
to construct an ExceptionSet).  So I think removing it from evaluateSignal: is 
definitely the right thing to do.

As far as tests for findNextHandlerFrom:, this is tested implicitly by any 
nested exception test so I expect you have several tests affected.  Clément 
points to a test that fails when not including  in 
evaluateSignal: so more investigation is necessary.  Difficult to do while bugs 
are hidden in fogbugz.  When are they going to migrate the github where they 
belong?

> 
> ND, 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

Re: [Pharo-dev] About the infinite debugger

[Esteban A. Maringolo]

Great news!

I hope this fixes it once and for all.

For some reason this bug bit me several times in several Pharo releases.

Thank you all for your dedication.

On 29/06/2018 11:48, Guillermo Polito wrote:
> 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...
> 
> ND, 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

-- 
Esteban A. Maringolo

Re: [Pharo-dev] About the infinite debugger

[Guillermo Polito]

On Fri, Jun 29, 2018 at 5:58 PM Ben Coman  wrote:

>
>
> On 29 June 2018 at 22:48, Guillermo Polito 
> wrote:
>
>> 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...
>>
>> ND, 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
>>
>
> I'm just about to fly out for a family vacation, so I'm not sure when I'll
> get a chance to have a good look.
> But I read the issue on Fogbugz and it echos some things I've been
> thinking recently,
> though I hadn't come close to that particular fix.
>
> I think my following comments are probably unrelated, but just sharing
> some thoughts that crossed my mind when I was looking into my own similar
> trouble.
> This is an area I'm not clear on and would like to understand better...
>
> When the UI thread (UI1) needs to be debugged (e.g. code run from
> Playground, or a test)
> and is suspended and a new UI thread (UI2) is started, which thread does
> the debugger run in?
>

Yes


> I guess it must run in UI2 but sometimes I got the vague feeling some
> parts of it were caught in UI1 and affected by UI1 being suspended.
>
But perhaps I got the wrong impression - its a complex interplay to follow.
>

Nope.. Actually, UI2 will simulate code of UI1 as it was running in UI1.
There is some machinery (look at #effectiveProcess) so that

Processor activeProcess

yields UI1 when stepping over UI2 code.


>
> The other vague notion I had was when thread UI1 is resumed, it seems to
> replace thread UI2 where the World keeps its,
> and wondered if  on the suspended-debug-UI1 thread somehow made
> it "resume" and so replace UI2 as the main thread,
> but then UI1 gets suspended again and the display freezes.
>
> Thanks for everyones efforts on this.
> cheers -ben
>


-- 



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

Re: [Pharo-dev] About the infinite debugger

[Ben Coman]

On 29 June 2018 at 22:48, Guillermo Polito 
wrote:

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

I'm just about to fly out for a family vacation, so I'm not sure when I'll
get a chance to have a good look.
But I read the issue on Fogbugz and it echos some things I've been thinking
recently,
though I hadn't come close to that particular fix.

I think my following comments are probably unrelated, but just sharing some
thoughts that crossed my mind when I was looking into my own similar
trouble.
This is an area I'm not clear on and would like to understand better...

When the UI thread (UI1) needs to be debugged (e.g. code run from
Playground, or a test)
and is suspended and a new UI thread (UI2) is started, which thread does
the debugger run in?
I guess it must run in UI2 but sometimes I got the vague feeling some parts
of it were caught in UI1 and affected by UI1 being suspended.
But perhaps I got the wrong impression - its a complex interplay to follow.

The other vague notion I had was when thread UI1 is resumed, it seems to
replace thread UI2 where the World keeps its,
and wondered if  on the suspended-debug-UI1 thread somehow made
it "resume" and so replace UI2 as the main thread,
but then UI1 gets suspended again and the display freezes.

Thanks for everyones efforts on this.
cheers -ben

[Pharo-dev] About the infinite debugger

[Guillermo Polito]

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

ND, 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