Nov. 16, 2015
1:45 p.m.
Also you do not have to run it from the command line to reproduce the error.
You can just execute in a playground:
CommandLineTestRunner runClasses: {GLMPagerMorphTest . GLMTreeMorphicTest.
GLMWatcherMorphicTest} named: 'x'. CommandLineTestRunner runPackages:
#('Kernel-Tests').
But if you run the same tests using a script then there is no block:
suite := TestSuite named: 'x'.
classes := {GLMPagerMorphTest . GLMTreeMorphicTest. GLMWatcherMorphicTest}
asSortedCollection: [ :a :b | a name <= b name ].
classes
do: [ :each | each addToSuiteFromSelectors: suite ].
runner := TestRunner new .
Author uniqueInstance
ifUnknownAuthorUse: 'hudson'
during: [ runner
runSuite: suite ].
On Mon, Nov 16, 2015 at 2:25 PM, Max Leske <maxleske@gmail.com> wrote:
> Interestingly, if I change the delay in that method from 400 to 0 I get
> the same effect (namely, it doesnât hang). So maybe itâs a problem with
> delay scheduling from low priority processes?
>
>
> On 16 Nov 2015, at 14:12, Andrei Chis <chisvasileandrei@gmail.com> wrote:
>
> Hi,
>
> Any news on this?
>
> Might be totally unrelated but I went back and searched for the the first
> version where [1] blocks.
> In my case the first version where it blocks is Pharo-40520.
> In Pharo-40519 it works ok.
> 40520 integrated https://pharo.fogbugz.com/f/cases/14993 which does a lot
> of changes, but one changed that this issue did is introduced an async
> tasks for updating the scrolling in inspector.
>
> Next if in the latest version I change in
> GLMScrollPaneBandBrick>>onChildrenLayouted the priority of asyncTask from
> 'Processor lowestPriority' to 'Processor userBackgroundPriority + 1'
> then #testBenchFor does not block. If I change the priority to the initial
> one it blocks again. At least on my machine this is consistent.
>
> Not sure if this fixes the bug on the CI but I updated issue 16957
> <https://pharo.fogbugz.com/f/cases/16957/Update-GTools-version-3-1> to
> include this change.
> Can you try to integrate the issue and see if it still blocks.
>
> Cheers,
> Andrei
>
>
>
> [1] ./pharo Pharo.image eval "CommandLineTestRunner runClasses:
> {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'.
> CommandLineTestRunner runPackages: #('Kernel-Tests')"
>
>
>
> On Thu, Nov 12, 2015 at 9:21 PM, Max Leske <maxleske@gmail.com> wrote:
>
>> I found a single test method I could use to narrow down the problem (be
>> aware that this might not work for you. I have other (fresh) images where
>> the issue never occurs). The method I used
>> is EpRedoAndUndoVisitorTest>>testClassModification.
>>
>> I was able to mitigate the hang by making a small modification to the
>> method EpUndoVisitor>>visitClassModification: Simply add
>>
>> 2 seconds asDelay wait. Smalltalk garbageCollect.
>>
>> or
>>
>> Smalltalk garbageCollect. 2 seconds asDelay wait.
>>
>> after the compilation phase. My guess is, that announcements build up (a
>> simple printout showed 1 announcement instance before and 74 instances
>> after the #evaluate:) and do stuff in the system that influence the process
>> scheduling. For instance, a lot of those announcements will probably be
>> weak and need to be finalized at some point.
>>
>> I donât have enough experience with the ClassBuilder to go on hunting but
>> this should hopefully give you a good head start.
>>
>
>
>>
>>
>> For testing I used the following command line:
>>
>> ./pharo found_case.image eval "CommandLineTestRunner runPackages:
>> #('Epicea' 'Kernel-Testsâ)"
>>
>> Install Epicea with
>>
>> ./pharo Pharo.image get Epicea 6.5
>>
>>
>> To isolate the test case I simply moved test classes from Epicea to a
>> differently named package and once I had found the class I started
>> excluding methods (e.g. with âself fail.â at the beginning).
>>
>>
>> HTH,
>> Max
>>
>>
>>
>>
>> On 12 Nov 2015, at 18:57, Martin Dias <tinchodias@gmail.com> wrote:
>>
>> Yes! with Max Leske we have been isolating the problem and we realized
>> that a fresh image was enough:
>>
>> 1)
>> curl get.pharo.org/50+vm | bash
>>
>> 2)
>> ./pharo Pharo.image eval "CommandLineTestRunner runClasses:
>> {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'.
>> CommandLineTestRunner runPackages: #('Kernel-Tests')"
>>
>> Martin
>>
>> On Thu, Nov 12, 2015 at 6:42 PM, Sven Van Caekenberghe <sven@stfx.eu>
>> wrote:
>>
>>> Then it must be that waiting on the delay never ends, which is probably
>>> a problem all by itself.
>>>
>>> > On 12 Nov 2015, at 18:39, Marcus Denker <marcus.denker@inria.fr>
>>> wrote:
>>> >
>>> > The fun thing is that I now get the same problem when integrating the
>>> GT Tools update.
>>> >
>>> > After doing the update for issue 16957, the test run hangs with
>>> >
>>> > starting testcase: BlockClosureTest>>testBenchFor ...
>>> >
>>> >
>>> >> On 11 Nov 2015, at 22:42, Martin Dias <tinchodias@gmail.com> wrote:
>>> >>
>>> >> Hello,
>>> >>
>>> >> I'm trying to understand why this method hangs in certain
>>> conditions*. What happens is that the #whileTrue: in the following method
>>> is never cut.
>>> >>
>>> >> benchFor: duration
>>> >> "Run me for duration and return a BenchmarkResult"
>>> >>
>>> >> "[ 100 factorial ] benchFor: 2 seconds"
>>> >>
>>> >> | count run started |
>>> >> count := 0.
>>> >> run := true.
>>> >> [ duration wait. run := false ] forkAt: Processor timingPriority
>>> - 1.
>>> >> started := Time millisecondClockValue.
>>> >> [ run ] whileTrue: [ self value. count := count + 1 ].
>>> >> ^ BenchmarkResult new
>>> >> iterations: count;
>>> >> elapsedTime: (Time millisecondsSince: started)
>>> milliSeconds;
>>> >> yourself
>>> >>
>>> >> Strangely, I verified with several #logCr that the forked block
>>> starts, but the #wait never ends.
>>> >> ---> Maybe you see something I don't in the code. Any clue?
>>> >>
>>> >> I will continue trying to isolate the problem, but maybe you have
>>> some idea.
>>> >>
>>> >> * the conditions to reproduce are:
>>> >> 1) curl get.pharo.org/50+vm | bash
>>> >> 2) ./pharo Pharo.image get Epicea 6.5
>>> >> 3) ./pharo Pharo.image test '^(?!Metacello)[A-L].*'
>>> >>
>>> >> Notes:
>>> >> - It doesn't hang when running from UI
>>> >> - it doesn't hang when running less tests, like:
>>> >> pharo Pharo.image test '^(?!Metacello)[E-L].*'
>>> >> - it *does* hang even when removing all Epicea tests
>>> >> - Epicea doesn't extend or override "kernel" behavior...
>>> >>
>>> >> Regards,
>>> >> Martin
>>> >
>>>
>>>
>>>
>>
>>
>
>