Recovery project hanging after recursive error in debugger

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Recovery project hanging after recursive error in debugger

Jakob Reschke-2
Hi,

Recently, it occurs quite frequently in my image that something goes
so wrong that the Debugger fails to open and I am bumped out to the
parent Project. However, the debugger for the crippled Process does
not open there either, because the ErrorRecursionGuard Mutex is still
held by the suspended Process that wants to be debugged.

Interrupting with Cmd+. and terminating the suspended process usually
works to get going again, but this seems not like something I should
have to do manually. Is something broken with the recovery mechanism?

More details from the stack (extracted with the Process Browser):
- some UnhandledError is raised
- ToolSet class>>debugError: is called
- Debugger class>>morphicOpenOn:context:label:contents:fullView: is
reached, the ErrorRecursionGuard Mutex is acquired
- ErrorRecursion is true there for some reason unknown to me, no
further debuggers are on that particular stack
- Project current handleFatalDrawingError:
- Project class>>tryOtherProjectForRecovery:
- SomeProjectType(Project)>>enterForEmergencyRecovery
- MorphicProject>>suspendProcessForDebug

Now it is waiting to be picked up by the 'FATAL PROJECT ERROR!'
debugger, but it cannot because that Mutex is still held, so the
debugger waits for the suspended process that it should debug.

- reproduce the hanging by ProcessBrowser>>debugProcess on the suspended Process
- Process>>debugWithTitle: ...
- Debugger class>>morphicOpenOn:context:label:contents:fullView: is
reached, wants to enter the critical section with ErrorRecursionGuard,
but has to wait ...

Kind regards,
Jakob

Reply | Threaded
Open this post in threaded view
|

Re: Recovery project hanging after recursive error in debugger

David T. Lewis
Is anyone else experiencing this problem? I have not seen it, but I have
not recently been doing things that could lead to an emergency evaluator,
so it is not surprising that I would not have seen it. Anyone else?

The ErrorRecursionGuard mutex is a relatively new addition (Tools-cmm.755
added in April), so it certainly seems possible the we may have a problem
related to the mutex.

Dave

On Sun, Jul 30, 2017 at 08:42:43PM +0200, Jakob Reschke wrote:

> Hi,
>
> Recently, it occurs quite frequently in my image that something goes
> so wrong that the Debugger fails to open and I am bumped out to the
> parent Project. However, the debugger for the crippled Process does
> not open there either, because the ErrorRecursionGuard Mutex is still
> held by the suspended Process that wants to be debugged.
>
> Interrupting with Cmd+. and terminating the suspended process usually
> works to get going again, but this seems not like something I should
> have to do manually. Is something broken with the recovery mechanism?
>
> More details from the stack (extracted with the Process Browser):
> - some UnhandledError is raised
> - ToolSet class>>debugError: is called
> - Debugger class>>morphicOpenOn:context:label:contents:fullView: is
> reached, the ErrorRecursionGuard Mutex is acquired
> - ErrorRecursion is true there for some reason unknown to me, no
> further debuggers are on that particular stack
> - Project current handleFatalDrawingError:
> - Project class>>tryOtherProjectForRecovery:
> - SomeProjectType(Project)>>enterForEmergencyRecovery
> - MorphicProject>>suspendProcessForDebug
>
> Now it is waiting to be picked up by the 'FATAL PROJECT ERROR!'
> debugger, but it cannot because that Mutex is still held, so the
> debugger waits for the suspended process that it should debug.
>
> - reproduce the hanging by ProcessBrowser>>debugProcess on the suspended Process
> - Process>>debugWithTitle: ...
> - Debugger class>>morphicOpenOn:context:label:contents:fullView: is
> reached, wants to enter the critical section with ErrorRecursionGuard,
> but has to wait ...
>
> Kind regards,
> Jakob
>

Reply | Threaded
Open this post in threaded view
|

Re: Recovery project hanging after recursive error in debugger

Chris Muller-3
ErrorRecursionGuard is a _patch_ to a relatively new addition, the
introduction of Debugger>>'ErrorRecursion' which resulted in the
Emergency Evaluator being opened too eagerly (and unable to be
closed!) -- even when there was no recursion.

Eliot fixed the symptom described by Jakob with Morphic-eem.1334.

On Tue, Aug 1, 2017 at 7:18 AM, David T. Lewis <[hidden email]> wrote:

> Is anyone else experiencing this problem? I have not seen it, but I have
> not recently been doing things that could lead to an emergency evaluator,
> so it is not surprising that I would not have seen it. Anyone else?
>
> The ErrorRecursionGuard mutex is a relatively new addition (Tools-cmm.755
> added in April), so it certainly seems possible the we may have a problem
> related to the mutex.
>
> Dave
>
> On Sun, Jul 30, 2017 at 08:42:43PM +0200, Jakob Reschke wrote:
>> Hi,
>>
>> Recently, it occurs quite frequently in my image that something goes
>> so wrong that the Debugger fails to open and I am bumped out to the
>> parent Project. However, the debugger for the crippled Process does
>> not open there either, because the ErrorRecursionGuard Mutex is still
>> held by the suspended Process that wants to be debugged.
>>
>> Interrupting with Cmd+. and terminating the suspended process usually
>> works to get going again, but this seems not like something I should
>> have to do manually. Is something broken with the recovery mechanism?
>>
>> More details from the stack (extracted with the Process Browser):
>> - some UnhandledError is raised
>> - ToolSet class>>debugError: is called
>> - Debugger class>>morphicOpenOn:context:label:contents:fullView: is
>> reached, the ErrorRecursionGuard Mutex is acquired
>> - ErrorRecursion is true there for some reason unknown to me, no
>> further debuggers are on that particular stack
>> - Project current handleFatalDrawingError:
>> - Project class>>tryOtherProjectForRecovery:
>> - SomeProjectType(Project)>>enterForEmergencyRecovery
>> - MorphicProject>>suspendProcessForDebug
>>
>> Now it is waiting to be picked up by the 'FATAL PROJECT ERROR!'
>> debugger, but it cannot because that Mutex is still held, so the
>> debugger waits for the suspended process that it should debug.
>>
>> - reproduce the hanging by ProcessBrowser>>debugProcess on the suspended Process
>> - Process>>debugWithTitle: ...
>> - Debugger class>>morphicOpenOn:context:label:contents:fullView: is
>> reached, wants to enter the critical section with ErrorRecursionGuard,
>> but has to wait ...
>>
>> Kind regards,
>> Jakob
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Recovery project hanging after recursive error in debugger

David T. Lewis
Cool, thanks Chris.

Jakob, I'm assuming you are working with a trunk image. Can you confirm if
the issue is resolved after updating your image to the latest?

Dave

> ErrorRecursionGuard is a _patch_ to a relatively new addition, the
> introduction of Debugger>>'ErrorRecursion' which resulted in the
> Emergency Evaluator being opened too eagerly (and unable to be
> closed!) -- even when there was no recursion.
>
> Eliot fixed the symptom described by Jakob with Morphic-eem.1334.
>
> On Tue, Aug 1, 2017 at 7:18 AM, David T. Lewis <[hidden email]>
> wrote:
>> Is anyone else experiencing this problem? I have not seen it, but I have
>> not recently been doing things that could lead to an emergency
>> evaluator,
>> so it is not surprising that I would not have seen it. Anyone else?
>>
>> The ErrorRecursionGuard mutex is a relatively new addition
>> (Tools-cmm.755
>> added in April), so it certainly seems possible the we may have a
>> problem
>> related to the mutex.
>>
>> Dave
>>
>> On Sun, Jul 30, 2017 at 08:42:43PM +0200, Jakob Reschke wrote:
>>> Hi,
>>>
>>> Recently, it occurs quite frequently in my image that something goes
>>> so wrong that the Debugger fails to open and I am bumped out to the
>>> parent Project. However, the debugger for the crippled Process does
>>> not open there either, because the ErrorRecursionGuard Mutex is still
>>> held by the suspended Process that wants to be debugged.
>>>
>>> Interrupting with Cmd+. and terminating the suspended process usually
>>> works to get going again, but this seems not like something I should
>>> have to do manually. Is something broken with the recovery mechanism?
>>>
>>> More details from the stack (extracted with the Process Browser):
>>> - some UnhandledError is raised
>>> - ToolSet class>>debugError: is called
>>> - Debugger class>>morphicOpenOn:context:label:contents:fullView: is
>>> reached, the ErrorRecursionGuard Mutex is acquired
>>> - ErrorRecursion is true there for some reason unknown to me, no
>>> further debuggers are on that particular stack
>>> - Project current handleFatalDrawingError:
>>> - Project class>>tryOtherProjectForRecovery:
>>> - SomeProjectType(Project)>>enterForEmergencyRecovery
>>> - MorphicProject>>suspendProcessForDebug
>>>
>>> Now it is waiting to be picked up by the 'FATAL PROJECT ERROR!'
>>> debugger, but it cannot because that Mutex is still held, so the
>>> debugger waits for the suspended process that it should debug.
>>>
>>> - reproduce the hanging by ProcessBrowser>>debugProcess on the
>>> suspended Process
>>> - Process>>debugWithTitle: ...
>>> - Debugger class>>morphicOpenOn:context:label:contents:fullView: is
>>> reached, wants to enter the critical section with ErrorRecursionGuard,
>>> but has to wait ...
>>>
>>> Kind regards,
>>> Jakob
>>>
>>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Recovery project hanging after recursive error in debugger

Jakob Reschke-2
In reply to this post by Chris Muller-3
My image is as updated as can be, but Eliot's fix does not help for
the "fatal drawing error" case because that still suspends from inside
the critical block, as my "stack trace" shows.

I noticed that the recovery project detection queries the class of the
project. I run an AnimMorphicProject (from the Animations [1] package,
inherits from MorphicProject) that is a child of a MorphicProject, so
the classes are different, otherwise the outer project would not be
tried. That might explain why nobody of you runs into the issue --
that is, in addition to not producing "fatal" errors all the time,
unlike me ;-)

[1] https://github.com/hpi-swa/Animations


2017-08-01 20:47 GMT+02:00 David T. Lewis <[hidden email]>:

> Cool, thanks Chris.
>
> Jakob, I'm assuming you are working with a trunk image. Can you confirm if
> the issue is resolved after updating your image to the latest?
>
> Dave
>
>> ErrorRecursionGuard is a _patch_ to a relatively new addition, the
>> introduction of Debugger>>'ErrorRecursion' which resulted in the
>> Emergency Evaluator being opened too eagerly (and unable to be
>> closed!) -- even when there was no recursion.
>>
>> Eliot fixed the symptom described by Jakob with Morphic-eem.1334.
>>
>> On Tue, Aug 1, 2017 at 7:18 AM, David T. Lewis <[hidden email]>
>> wrote:
>>> Is anyone else experiencing this problem? I have not seen it, but I have
>>> not recently been doing things that could lead to an emergency
>>> evaluator,
>>> so it is not surprising that I would not have seen it. Anyone else?
>>>
>>> The ErrorRecursionGuard mutex is a relatively new addition
>>> (Tools-cmm.755
>>> added in April), so it certainly seems possible the we may have a
>>> problem
>>> related to the mutex.
>>>
>>> Dave
>>>
>>> On Sun, Jul 30, 2017 at 08:42:43PM +0200, Jakob Reschke wrote:
>>>> Hi,
>>>>
>>>> Recently, it occurs quite frequently in my image that something goes
>>>> so wrong that the Debugger fails to open and I am bumped out to the
>>>> parent Project. However, the debugger for the crippled Process does
>>>> not open there either, because the ErrorRecursionGuard Mutex is still
>>>> held by the suspended Process that wants to be debugged.
>>>>
>>>> Interrupting with Cmd+. and terminating the suspended process usually
>>>> works to get going again, but this seems not like something I should
>>>> have to do manually. Is something broken with the recovery mechanism?
>>>>
>>>> More details from the stack (extracted with the Process Browser):
>>>> - some UnhandledError is raised
>>>> - ToolSet class>>debugError: is called
>>>> - Debugger class>>morphicOpenOn:context:label:contents:fullView: is
>>>> reached, the ErrorRecursionGuard Mutex is acquired
>>>> - ErrorRecursion is true there for some reason unknown to me, no
>>>> further debuggers are on that particular stack
>>>> - Project current handleFatalDrawingError:
>>>> - Project class>>tryOtherProjectForRecovery:
>>>> - SomeProjectType(Project)>>enterForEmergencyRecovery
>>>> - MorphicProject>>suspendProcessForDebug
>>>>
>>>> Now it is waiting to be picked up by the 'FATAL PROJECT ERROR!'
>>>> debugger, but it cannot because that Mutex is still held, so the
>>>> debugger waits for the suspended process that it should debug.
>>>>
>>>> - reproduce the hanging by ProcessBrowser>>debugProcess on the
>>>> suspended Process
>>>> - Process>>debugWithTitle: ...
>>>> - Debugger class>>morphicOpenOn:context:label:contents:fullView: is
>>>> reached, wants to enter the critical section with ErrorRecursionGuard,
>>>> but has to wait ...
>>>>
>>>> Kind regards,
>>>> Jakob
>>>>
>>>
>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Recovery project hanging after recursive error in debugger

David T. Lewis
Jakob,

I just committed a small update in System-dtl.961 that I think will address
the issue you are seeing. The assumption is that a fatal error in an AniMorphic
project is likely to be fatal also in a Morphic project, and therefore the
error handling logic should treat them similarly, hence an #isKindOf: test
rather than a test for equal classes.

Subclasses of MorphicProject will hopefully be a common case some day, and
we can easily imagine having things like ScratchProject and EtoysProject in
addition to AniMorphicProject. So it is important for the error recovery to
work in those cases.

Dave


On Tue, Aug 01, 2017 at 08:59:14PM +0200, Jakob Reschke wrote:

> My image is as updated as can be, but Eliot's fix does not help for
> the "fatal drawing error" case because that still suspends from inside
> the critical block, as my "stack trace" shows.
>
> I noticed that the recovery project detection queries the class of the
> project. I run an AnimMorphicProject (from the Animations [1] package,
> inherits from MorphicProject) that is a child of a MorphicProject, so
> the classes are different, otherwise the outer project would not be
> tried. That might explain why nobody of you runs into the issue --
> that is, in addition to not producing "fatal" errors all the time,
> unlike me ;-)
>
> [1] https://github.com/hpi-swa/Animations
>
>
> 2017-08-01 20:47 GMT+02:00 David T. Lewis <[hidden email]>:
> > Cool, thanks Chris.
> >
> > Jakob, I'm assuming you are working with a trunk image. Can you confirm if
> > the issue is resolved after updating your image to the latest?
> >
> > Dave
> >
> >> ErrorRecursionGuard is a _patch_ to a relatively new addition, the
> >> introduction of Debugger>>'ErrorRecursion' which resulted in the
> >> Emergency Evaluator being opened too eagerly (and unable to be
> >> closed!) -- even when there was no recursion.
> >>
> >> Eliot fixed the symptom described by Jakob with Morphic-eem.1334.
> >>
> >> On Tue, Aug 1, 2017 at 7:18 AM, David T. Lewis <[hidden email]>
> >> wrote:
> >>> Is anyone else experiencing this problem? I have not seen it, but I have
> >>> not recently been doing things that could lead to an emergency
> >>> evaluator,
> >>> so it is not surprising that I would not have seen it. Anyone else?
> >>>
> >>> The ErrorRecursionGuard mutex is a relatively new addition
> >>> (Tools-cmm.755
> >>> added in April), so it certainly seems possible the we may have a
> >>> problem
> >>> related to the mutex.
> >>>
> >>> Dave
> >>>
> >>> On Sun, Jul 30, 2017 at 08:42:43PM +0200, Jakob Reschke wrote:
> >>>> Hi,
> >>>>
> >>>> Recently, it occurs quite frequently in my image that something goes
> >>>> so wrong that the Debugger fails to open and I am bumped out to the
> >>>> parent Project. However, the debugger for the crippled Process does
> >>>> not open there either, because the ErrorRecursionGuard Mutex is still
> >>>> held by the suspended Process that wants to be debugged.
> >>>>
> >>>> Interrupting with Cmd+. and terminating the suspended process usually
> >>>> works to get going again, but this seems not like something I should
> >>>> have to do manually. Is something broken with the recovery mechanism?
> >>>>
> >>>> More details from the stack (extracted with the Process Browser):
> >>>> - some UnhandledError is raised
> >>>> - ToolSet class>>debugError: is called
> >>>> - Debugger class>>morphicOpenOn:context:label:contents:fullView: is
> >>>> reached, the ErrorRecursionGuard Mutex is acquired
> >>>> - ErrorRecursion is true there for some reason unknown to me, no
> >>>> further debuggers are on that particular stack
> >>>> - Project current handleFatalDrawingError:
> >>>> - Project class>>tryOtherProjectForRecovery:
> >>>> - SomeProjectType(Project)>>enterForEmergencyRecovery
> >>>> - MorphicProject>>suspendProcessForDebug
> >>>>
> >>>> Now it is waiting to be picked up by the 'FATAL PROJECT ERROR!'
> >>>> debugger, but it cannot because that Mutex is still held, so the
> >>>> debugger waits for the suspended process that it should debug.
> >>>>
> >>>> - reproduce the hanging by ProcessBrowser>>debugProcess on the
> >>>> suspended Process
> >>>> - Process>>debugWithTitle: ...
> >>>> - Debugger class>>morphicOpenOn:context:label:contents:fullView: is
> >>>> reached, wants to enter the critical section with ErrorRecursionGuard,
> >>>> but has to wait ...
> >>>>
> >>>> Kind regards,
> >>>> Jakob
> >>>>
> >>>
> >>
> >>
> >
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: Recovery project hanging after recursive error in debugger

Jakob Reschke-2
In reply to this post by Jakob Reschke-2
Thank you, Dave. Now I will have to wait until "it" happens again and
see whether things have gotten better or worse in the situation. ;-)

If the symptom is gone now, I still have that bogus "fatal" error
lurking around. Which is usually not so fatal after all because I can
simply reenter the project. But that is another story for another day.

For those of you who like guessing games or may actually find it
plausible: the situation that raises the "fatal" error is usually when
something goes wonky while debugging test cases. Sometimes when
pressing one of the stepping buttons a second debugger with only a
single context on the stack appears and it tells me that the context
is gone or not in the sender chain or something in that direction, I
don't remember the exact message right now. Pressing the wrong buttons
in the wrong debugger (which are "wrong" and which are harmless I
could not exactly sort out yet either) can then trigger the "fatal"
error. Another situation is when I build something with the
ToolBuilder, but have not implemented all the methods (e. g., fetching
tree node children or item labels) in advance. I find it convenient to
just open the tool and then use the "Create" button in the debugger to
start implementing it, but this approach got me drawing errors in the
tool and also several times a "fatal" error after (!) eventually
adding a particular method, so I have stopped doing that...

2017-08-02 15:38 GMT+02:00 David T. Lewis <[hidden email]>:

> Jakob,
>
> I just committed a small update in System-dtl.961 that I think will address
> the issue you are seeing. The assumption is that a fatal error in an AniMorphic
> project is likely to be fatal also in a Morphic project, and therefore the
> error handling logic should treat them similarly, hence an #isKindOf: test
> rather than a test for equal classes.
>
> Subclasses of MorphicProject will hopefully be a common case some day, and
> we can easily imagine having things like ScratchProject and EtoysProject in
> addition to AniMorphicProject. So it is important for the error recovery to
> work in those cases.
>
> Dave
>
>
> On Tue, Aug 01, 2017 at 08:59:14PM +0200, Jakob Reschke wrote:
>> My image is as updated as can be, but Eliot's fix does not help for
>> the "fatal drawing error" case because that still suspends from inside
>> the critical block, as my "stack trace" shows.
>>
>> I noticed that the recovery project detection queries the class of the
>> project. I run an AnimMorphicProject (from the Animations [1] package,
>> inherits from MorphicProject) that is a child of a MorphicProject, so
>> the classes are different, otherwise the outer project would not be
>> tried. That might explain why nobody of you runs into the issue --
>> that is, in addition to not producing "fatal" errors all the time,
>> unlike me ;-)
>>
>> [1] https://github.com/hpi-swa/Animations
>>
>>
>> 2017-08-01 20:47 GMT+02:00 David T. Lewis <[hidden email]>:
>> > Cool, thanks Chris.
>> >
>> > Jakob, I'm assuming you are working with a trunk image. Can you confirm if
>> > the issue is resolved after updating your image to the latest?
>> >
>> > Dave
>> >
>> >> ErrorRecursionGuard is a _patch_ to a relatively new addition, the
>> >> introduction of Debugger>>'ErrorRecursion' which resulted in the
>> >> Emergency Evaluator being opened too eagerly (and unable to be
>> >> closed!) -- even when there was no recursion.
>> >>
>> >> Eliot fixed the symptom described by Jakob with Morphic-eem.1334.
>> >>
>> >> On Tue, Aug 1, 2017 at 7:18 AM, David T. Lewis <[hidden email]>
>> >> wrote:
>> >>> Is anyone else experiencing this problem? I have not seen it, but I have
>> >>> not recently been doing things that could lead to an emergency
>> >>> evaluator,
>> >>> so it is not surprising that I would not have seen it. Anyone else?
>> >>>
>> >>> The ErrorRecursionGuard mutex is a relatively new addition
>> >>> (Tools-cmm.755
>> >>> added in April), so it certainly seems possible the we may have a
>> >>> problem
>> >>> related to the mutex.
>> >>>
>> >>> Dave
>> >>>
>> >>> On Sun, Jul 30, 2017 at 08:42:43PM +0200, Jakob Reschke wrote:
>> >>>> Hi,
>> >>>>
>> >>>> Recently, it occurs quite frequently in my image that something goes
>> >>>> so wrong that the Debugger fails to open and I am bumped out to the
>> >>>> parent Project. However, the debugger for the crippled Process does
>> >>>> not open there either, because the ErrorRecursionGuard Mutex is still
>> >>>> held by the suspended Process that wants to be debugged.
>> >>>>
>> >>>> Interrupting with Cmd+. and terminating the suspended process usually
>> >>>> works to get going again, but this seems not like something I should
>> >>>> have to do manually. Is something broken with the recovery mechanism?
>> >>>>
>> >>>> More details from the stack (extracted with the Process Browser):
>> >>>> - some UnhandledError is raised
>> >>>> - ToolSet class>>debugError: is called
>> >>>> - Debugger class>>morphicOpenOn:context:label:contents:fullView: is
>> >>>> reached, the ErrorRecursionGuard Mutex is acquired
>> >>>> - ErrorRecursion is true there for some reason unknown to me, no
>> >>>> further debuggers are on that particular stack
>> >>>> - Project current handleFatalDrawingError:
>> >>>> - Project class>>tryOtherProjectForRecovery:
>> >>>> - SomeProjectType(Project)>>enterForEmergencyRecovery
>> >>>> - MorphicProject>>suspendProcessForDebug
>> >>>>
>> >>>> Now it is waiting to be picked up by the 'FATAL PROJECT ERROR!'
>> >>>> debugger, but it cannot because that Mutex is still held, so the
>> >>>> debugger waits for the suspended process that it should debug.
>> >>>>
>> >>>> - reproduce the hanging by ProcessBrowser>>debugProcess on the
>> >>>> suspended Process
>> >>>> - Process>>debugWithTitle: ...
>> >>>> - Debugger class>>morphicOpenOn:context:label:contents:fullView: is
>> >>>> reached, wants to enter the critical section with ErrorRecursionGuard,
>> >>>> but has to wait ...
>> >>>>
>> >>>> Kind regards,
>> >>>> Jakob
>> >>>>
>> >>>
>> >>
>> >>
>> >
>> >
>> >
>>
>