Our regression testing from poly's master branch with sources that are fine on 5.5.2 is showing repeated "random" failures on OSX.
You can see the build history at
https://travis-ci.org/HOL-Theorem-Prover/HOL/builds
(ignore the k11-release-prep branch failures). In all of the recent failures of HOL's master, you'll see that it is the "GITPOLY" build on OSX failing. The GITPOLY build on Linux is fine. Unfortunately, the failures are happening at different times in the build.
The only thing they seem to have in common is that there is a test (using OS.Process.isSuccess) of the result of another execution ultimately set up with OS.Process.system. The output even somewhat suggests that the child process terminated successfully; could it be that the return code is being randomly mis-interpreted?
Michael
________________________________
The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.
I can't reproduce this. I don't have a Mac myself but I have access to some Macs at TUM. Building the current HOL git (commit e43e318034c861ce15abde434b9261f227e3bf51) with the current Poly/ML git (commit ee26375edd3d530818241ad8f4d5dce43df3ba6e) it runs to completion with no apparent errors. Just to be sure it was run successfully three times. This was on Darwin Kernel Version 13.4.0.
There's not much that can be done unless it's possible to narrow down the problem further.
David
On 08/01/2016 08:53, Michael Norrish wrote:
Our regression testing from poly's master branch with sources that are fine on 5.5.2 is showing repeated "random" failures on OSX.
You can see the build history at
https://travis-ci.org/HOL-Theorem-Prover/HOL/builds
(ignore the k11-release-prep branch failures). In all of the recent failures of HOL's master, you'll see that it is the "GITPOLY" build on OSX failing. The GITPOLY build on Linux is fine. Unfortunately, the failures are happening at different times in the build.
The only thing they seem to have in common is that there is a test (using OS.Process.isSuccess) of the result of another execution ultimately set up with OS.Process.system. The output even somewhat suggests that the child process terminated successfully; could it be that the return code is being randomly mis-interpreted?
Michael
Thanks for experimenting! Perhaps the problem is with Travis's virtual machine setup.
Michael
On 9 Jan 2016, at 00:51, David Matthews <David.Matthews at prolingua.co.uk> wrote:
I can't reproduce this. I don't have a Mac myself but I have access to some Macs at TUM. Building the current HOL git (commit e43e318034c861ce15abde434b9261f227e3bf51) with the current Poly/ML git (commit ee26375edd3d530818241ad8f4d5dce43df3ba6e) it runs to completion with no apparent errors. Just to be sure it was run successfully three times. This was on Darwin Kernel Version 13.4.0.
There's not much that can be done unless it's possible to narrow down the problem further.
David
On 08/01/2016 08:53, Michael Norrish wrote: Our regression testing from poly's master branch with sources that are fine on 5.5.2 is showing repeated "random" failures on OSX.
You can see the build history at
https://travis-ci.org/HOL-Theorem-Prover/HOL/builds
(ignore the k11-release-prep branch failures). In all of the recent failures of HOL's master, you'll see that it is the "GITPOLY" build on OSX failing. The GITPOLY build on Linux is fine. Unfortunately, the failures are happening at different times in the build.
The only thing they seem to have in common is that there is a test (using OS.Process.isSuccess) of the result of another execution ultimately set up with OS.Process.system. The output even somewhat suggests that the child process terminated successfully; could it be that the return code is being randomly mis-interpreted?
Michael
________________________________
The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.