Nov. 16, 2015
1:12 p.m.
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
>> >
>>
>>
>>
>
>