I can confirm that changing #styleInBackgroundProcess: to #style: fixes the problem on my machine.

I had tracked down a version of GTInspector-Core (StefanReichhart.310) that exhibited the problem while the immediate ancestor didn���t. Unfortunately the number of changes are huge in that version.

Still, making the above change makes that version also work. My guess is, that this version leads to more of these styling requests.

I logged the number of processes after running the examples:

without the fix:��937

with the fix: 17

Sounds pretty compelling to me that this will mess with process scheduling���

Cheers,

Max

On 17 Nov 2015, at 22:56, Andrei Chis <chisvasileandrei@gmail.com> wrote:

We investigated more with Max and Aliaksey, and managed to reduce the bug to executing just two tests.

Just it would great if somebody else could reproduce it. You need to run commands only from console and save and quit the image after a change.

The tests that need to be executed are��GTInspectorExamplesTest>>#testAllExamples and��BlockClosureTest>>#testBenchFor.

Download the latest pharo image and remove GTInspectorExamplesTest>>#testGlobals, so that GTInspectorExamplesTest has one single test.

In GTInspectorExamplesTest>>#testAllExamples replace 'Object withAllSubclasses' with 'Dictionary asOrderedCollection' (it's not the actual examples that cause problems).

If you execute now the tests, BlockClosureTest>>#testBenchFor will block for around 20 seconds.

./pharo Pharo.image eval "CommandLineTestRunner runClasses: {GTInspectorExamplesTest} named: 'x'. CommandLineTestRunner runClasses: {BlockClosureTest} named: 'y'"

Now go to��SHTextStyler>>styleInBackgroundProcess: and in the only��onTimeout: block from the method add ��--> 'timeoute done' logCr. <--.

Run again the tests and now the string 'timeoute done' is printed 4 times after 20 seconds.��

Replace in��RubShoutStylerDecorator>>style: the call to #styleInBackgroundProcess: with #style:

Running again the tests has no delay on BlockClosureTest>>#testBenchFor.

Reverting the changes to GTInspectorExamplesTest>>#testAllExamples and running all examples again leads to no delay on BlockClosureTest>>#testBenchFor (testing all examples can take a few minutes).

Running all the tests as on the CI also does not block in BlockClosureTest>>#testBenchFor.

./pharo Pharo.image test --junit-xml-output '^(?!Metacello)[A-L].*'

(ignore the output about GTDummyExamplesInvalid which will disappear when the new version is integrated)

(running the tests takes a bit of time)

I get the same behaviour if I first load��issue 16957

If anybody else can reproduce this behaviour then the zombie processes that appear while styling in rubric are somehow interfering with the delay scheduling mechanism.��

Cheers,

Andrei

On Mon, Nov 16, 2015 at 2:45 PM, Andrei Chis <chisvasileandrei@gmail.com> wrote:

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