Hey thanks - this is Pharo 6.1, with a zero conf downloaded yesterday, and a second image from a week ago. I guess its possible that I don’t have those changes - is there an easy way to check?
I’m happy to try applying them - or use a different image to test with - as it seems that certain conditions really rear their head and then you just get the problem over and over. On the plus side - its rare that you crash you image and then have to recover changes - but its just annoying when it gets in the way of debugging. ITs not just all the windows, its also the fact that none of the debugger windows actually puts you in a useful stack where you can see the problem - they are all stuck on DNU with a single line stack. Tim > On 6 Aug 2018, at 09:46, Guillermo Polito <guillermopol...@gmail.com> wrote: > > Hi Tim, > > Are you on Pharo 6 or 7? If in 7, what build are you using? > > Pablo and Santi have made a fix 2 fridays ago (that I presume got integrated > last week). The fix consists on changing a bit the exception handling during > exception handling. > > https://github.com/pharo-project/pharo/pull/1621/files > <https://github.com/pharo-project/pharo/pull/1621/files> > > The fix seems simple, but it has a lot of information contained on it (like > the fact that the system introduces exception handlers in the middle of the > stack transparently to manage errors while stepping, or the fact that > UnhandledError does another traversal of the stack but needs to start at the > good place...). The Exception tests we had are still green, and we can now do > stepping on code that raises exceptions. When stepping inside the DNU > multiple times the debugging experience is not as smooth as the one in Pharo > 3 (before it got broken) but this is FAR BETTER than Pharo7 since we have not > experienced new infinite debuggers anymore :)... > > I'll let Pablo and Santi answer more properly with the technical details. > > On my side, I think we need to better document and do some more unit tests on > that dark part of the system :). > > On Mon, Aug 6, 2018 at 8:50 AM Stéphane Ducasse <stephane.duca...@inria.fr > <mailto:stephane.duca...@inria.fr>> wrote: > Hi tim > > We know and we made huge progress because before we could not even reproduce > it. > We spent some times on it. I thought the solution found by pablo and santiago > got integrated. > > Stef > >> 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 >>>> >>> >> > > -------------------------------------------- > Stéphane Ducasse > http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> > http://www.synectique.eu <http://www.synectique.eu/> / http://www.pharo.org > <http://www.pharo.org/> > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, Bât.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > > > -- > > 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
