On 27 Feb 2013, at 09:31, Marcus Denker <marcus.denker@inria.fr> wrote:
On Feb 27, 2013, at 8:53 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On Feb 27, 2013, at 12:57 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
we still get very undeterministic results from our build server. I relaunched the Pharo-2.0-Tests several times with the exact same VM & Image configuration.
BUT, the outcome of the test results varies each time a little bit |(
https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/176/testReport/ (windows crashed) https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/177/testReport/ (windows crashed, KernelTests.Chronology.DateTest.testDateAndTimeNow failing...) https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/178/testReport/ (KernelTests.Chronology.DateTest.testDateAndTimeNow on all) https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/179/testReport/ (!BOOM!) https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/180/testReport/ ... ditto ... https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/181/testReport/ (!BOOM! plus windows crash) https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/182/testReport/ (!BOOM! plus windows AND linux crash) https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/183/testReport/ (lots of failures all systems running, no chronology tests failing) ...
so we still have to investigate this instability...
It is strange. Form the image side:
Even stranger
https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/
My theory: strange clock related issues due to virtualisation?
To rule out clock problems, you should check the SNTP client that I announced - this was exactly why I wrote it. The ZTimestamp unit tests will only pass if the clock difference is not greater than 2 seconds. If the clock is wrong on the machine, on Linux you can do sudo ntpdate pool.ntp.org to manually force a date/time sync.
But then why did it fail on the mac?
Marcus