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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> wrote: >> >> bump >> >> Am 04.07.2018 um 02:28 schrieb Martin McClure <[email protected]>: >> >> 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 > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 > -- Pablo Tesone. [email protected]
