On 11 January 2014 22:55, Frank Shearar frank.shearar@gmail.com wrote:
On 11 January 2014 19:19, tim Rowledge tim@rowledge.org wrote:
On 11-01-2014, at 6:29 AM, Frank Shearar frank.shearar@gmail.com wrote:
A bunch of the Trait tests fail, despite no one having worked on the Traits code in quite a while. The symptom is that the tests time out [1]. I've tried to debug some, only to find that they pass. For instance, <timeout: 60> sometimes "fixes" the tests.
But the tests shouldn't be failing. Any takers?
I noticed similar issues when running test on a Pi; being a relatively slow machine it takes longer to do some things and needed a larger timeout value.
If tests that used to run within the time are now taking longer but still pass if given enough time, that implies to me that either a) the tests are being run on a slower machine due to some system configuration change (are other jobs also running and taking time?) b) something has changed in the execution path to slow down the tested code. Which obviously, ought not be the case.
They time out on my beefy work laptop: a 2.7 GHz machine. That's probably a higher spec machine than the build server.
If I was a betting man I'd be inclined to put my money on (b).
Attached is the output of MessageTally spyOn: [[TraitCompositionTest debug: #testAliasCompositions] on: TestFailure do: [#fail]], after adding <timeout: 60> to the test.
The leaves are very interesting:
**Leaves** 43.1% {28650ms} CompiledMethod>>originalTraitMethod: 36.9% {24505ms} Text>>size 9.7% {6425ms} Delay>>wait 3.4% {2239ms} SecurityManager class>>default 1.1% {749ms} CompiledMethod>>checkOKToAdd:at:
_24 seconds_ in Text >> #size ?! Also, CompiledMethod>>originalTraitMethod: hasn't changed in 4 years. In fact the only things that have changed, that I can see, in the code path are Chris Muller's fixing of TestCase >> #debug and Nicolas Cellier's cleanup of the Compiler API. Nothing looks even remotely capable of slowing stuff down this dramatically.
frank