Hi Steven, I'll take a look at this later this week, no time now, but: did you check that the debugger makes a copy of the UI process when there is an exception in the UI process? Because that is also part of the problem I believe.
On Mon, Jun 11, 2018 at 2:18 PM, Steven Costiou <[email protected]> wrote: > Hi, > > Is that normal that in the following method we do "*ex pass*" (at the > end)? > > > runCaseForDebug: aTestCase > [ aTestCase announce: TestCaseStarted withResult: self. > aTestCase runCaseManaged. > aTestCase announce: TestCaseEnded withResult: self. > "To not affect performance of big test suites following logic is not > inside addPass: method" > errors remove: aTestCase ifAbsent: [ ]. > failures remove: aTestCase ifAbsent: [ ]. > self addPass: aTestCase ] > on: self class failure , self class skip , self class warning , > self class error > do: [ :ex | > ex sunitAnnounce: aTestCase toResult: self. > * ex pass* ] > > > I think it is the source of the infinite crazy debugger bug (maybe i'm > wrong) https://pharo.fogbugz.com/f/cases/22085/Infinite-debugger > > Doing "ex debug" solves the problem but i do not know the impact (pharo 5 > - 6 - 7, but not previous versions). > > > > For what i understand, it happens because : > > - when you got an error in a test, it goes through the ex pass > > - but when you got a doesNotUnderstand, it first goes into: > > doesNotUnderstand: aMessage > <debuggerCompleteToSender> > > | exception resumeValue | > (exception := MessageNotUnderstood new) > message: aMessage; > receiver: self. > * resumeValue := exception signal.* > ^exception reachedDefaultHandler > ifTrue: [*aMessage sentTo: self*] > ifFalse: [resumeValue] > > > > In normal cases (class of the receiver is not a test case), when you step > in the debugger the *exception signal *blocks the execution right away. > > In subclasses of *TestCase*, it does *ex pass* each time you signal the > exception and so it continues in the doesNotUnderstand. > > Then it enters the *aMessage sentTo: self* in the doesNotUnderstand, > which is still not understood and goes again into the "ex pass", then you > can wait a long time... > > > > I'm not really sure though why it does not open another debugger and why > it gets stuck. Maybe that is the real bug: it should open another debugger > and not loop and pop one million debugging windows after a user > interruption. > > Another side effect is that the watchdog of the TestExecutionEnvironment > also gets stuck and stops counting for the timeout, because a debugging > session was open and never closed (because its looping). > > See TestExecutionEnvironment>>watchDogLoopFor:. > > > > Replacing *ex pass* by *ex debug* seems to work and reproduce the > standard behavior of the debugger for classes that are not subclasses of > TestCase. But i do not know if the "pass" was explicitly intended and if > there will be side effects... > > > > Steven. > -- 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
