Ah that’s interesting- it’s happened to me 4 or 5 tines in the last 2 days. Recent enough that maybe I can figure out a test case.... I’ll try.
Sent from my iPhone > On 8 Jun 2018, at 18:57, Steven Costiou <steven.cost...@kloum.io> wrote: > > Concerning the bug 22085, i commented on fogbuzz: > >> I believe it is because when running test cases, it runs through: >> >> runCaseForDebug: aTestCase >> [...call test code...] >> on: self class failure , self class skip, self class warning, self >> class error >> do: [:ex | ex sunitAnnounce: aTestCase toResult: self. ex pass] >> >> So when you reach a doesNotUnderstand, you have: >> >> doesNotUnderstand: aMessage >> [...stuff...] >> >> 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 get to this line, then >> it enters the aMessage sentTo: self, which is not understood, then you can >> wait a long time... >> >> >> It is equivalent to doing this in a playground: >> >> [ Object new doStuff ] on: Exception do:[:ex| ex pass] >> >> Then step in the debugger and bye bye. But then it seems to be expected >> behavior... or maybe not ? I mean voluntarily passing on an exception in a >> doesNotUnderstand would lead to such problems. >> > > > I have heard at least three different stories about this bug : yours, the one > from fogbuzz and one other a bit different from Guille. > > They seem to be different but all of them end up looping ad vitam eternam > after a debugger step. > > I am looking for ways to reproduce any of this bugs (well except 22085), but > so far i have no success on my own images :'( (pharo 6.1 & 7). > > > > Steven.
