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��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
>