On 17 Nov 2015, at 23:50, Andrei Chis <chisvasileandrei@gmail.com> wrote:
On Tue, Nov 17, 2015 at 11:44 PM, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote: 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
Is this the number of processes for running all examples?
Yes.
If yes can you also measure it when running just a single example, as testBenchFor also blocks in that case.
Thereâs no facility for running a single example, so I just created this method: GTInspectorExamplesTest>>testSingleExample self checkAllPresentationsOf: Collection gtExamples first Then, when I run this command line: ./pharo Pharo.image eval "| suite | suite := TestSuite named: 'x'. suite addTest: (GTInspectorExamplesTest new setTestSelector: #testSingleExample; yourself). CommandLineTestRunner runSuite: suite. suite := TestSuite named: 'y'. suite addTest: (BlockClosureTest new setTestSelector: #testBenchFor; yourself). CommandLineTestRunner runSuite: suite.â I get 17 with the fix and 19 without. Which example did you run to have #testBenchFor block? Because it didnât block for me...
Cheers, Andrei
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 <mailto: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 <https://pharo.fogbugz.com/f/cases/16957/Update-GTools-version-3-1>
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 <mailto: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 <mailto: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 <mailto: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 <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 <mailto: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 <mailto: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 <http://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 <mailto: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 <mailto: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 <mailto: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 <http://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