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 <steven.costiou@kloum.io> 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