- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #1038: 22107-DockingBarMorph-should-have-its-own-entry-in-the-theme-to-define-the-border-width

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1038 was: FAILURE. The Pull Request #1514 was integrated: "22107-DockingBarMorph-should-have-its-own-entry-in-the-theme-to-define-the-border-width" Pull request url: https://github.com/pharo-project/pharo/pull/1514 Issue Url: https://pharo.fogbugz.com/f/cases/22107 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 11, 2018

Re: [Pharo-dev] About infinite debuggers in tests (https://pharo.fogbugz.com/f/cases/22085/Infinite-debugger)

by Guillermo Polito

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(a)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

June 11, 2018

About infinite debuggers in tests (https://pharo.fogbugz.com/f/cases/22085/Infinite-debugger)

by Steven Costiou

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.

June 11, 2018