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, teso...@gmail.com 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 <guillermopol...@gmail.com > <mailto:guillermopol...@gmail.com>> 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 <steven.cost...@kloum.io > <mailto:steven.cost...@kloum.io>> 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 <norb...@hartl.name >>> <mailto:norb...@hartl.name>> wrote: >>> >>> bump >>> >>>> Am 04.07.2018 um 02:28 schrieb Martin McClure <mar...@hand2mouse.com >>>> <mailto:mar...@hand2mouse.com>>: >>>> >>>>> 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. > teso...@gmail.com <mailto:teso...@gmail.com>
