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