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