Hello everyone, Our last nightly build on RHEL linux x64 failed because the test dxtbx/tests/tst_dxtbx.py , which normally takes roughly 3 seconds to run on the build machine, got stuck for over 5 minutes. All the other tests (cctbx/scitbx/libtbx/iotbx/rstbx and remaining dxtbx) completed successfully. Tests were run via libtbx.run_tests_parallel with nproc=4. As far as I can tell there is no debug output. The libtbx testing suite does not support timeouts like some timeout decorators on python unittest? As far as I can tell tst_dxtbx.py at the moment runs 5 separate tests, so for future debugging it may make sense to split these up. -Markus -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
HI Markus If you run this test in isolation does it take as long? Quite possible someone has added a test file which is not properly interpreted by dxtbx but which takes a long time to find this out… I’ll run the same to see if I can reproduce the error. Also could be a local issue, what happens if you rerun the tests? Thanks Graeme On 25 Mar 2015, at 09:06, [email protected]mailto:[email protected] wrote: Hello everyone, Our last nightly build on RHEL linux x64 failed because the test dxtbx/tests/tst_dxtbx.py , which normally takes roughly 3 seconds to run on the build machine, got stuck for over 5 minutes. All the other tests (cctbx/scitbx/libtbx/iotbx/rstbx and remaining dxtbx) completed successfully. Tests were run via libtbx.run_tests_parallel with nproc=4. As far as I can tell there is no debug output. The libtbx testing suite does not support timeouts like some timeout decorators on python unittest? As far as I can tell tst_dxtbx.py at the moment runs 5 separate tests, so for future debugging it may make sense to split these up. -Markus -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom _______________________________________________ cctbxbb mailing list [email protected]mailto:[email protected] http://phenix-online.org/mailman/listinfo/cctbxbb
Hi Graeme, As I said, the test in isolation takes about 3 seconds. Reruns on the same machine were fine. We had a similar timeout build failure on the same machine two days ago, which I haven't investigated. Sounds to me like a possible race condition or reliance on random numbers leading to a non-converging loop somewhere. Test data are all local to the machine, so no network interference. -Markus -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: 25 March 2015 09:13 To: [email protected] Subject: Re: [cctbxbb] dxtbx test failure HI Markus If you run this test in isolation does it take as long? Quite possible someone has added a test file which is not properly interpreted by dxtbx but which takes a long time to find this out… I’ll run the same to see if I can reproduce the error. Also could be a local issue, what happens if you rerun the tests? Thanks Graeme On 25 Mar 2015, at 09:06, [email protected]mailto:[email protected] wrote: Hello everyone, Our last nightly build on RHEL linux x64 failed because the test dxtbx/tests/tst_dxtbx.py , which normally takes roughly 3 seconds to run on the build machine, got stuck for over 5 minutes. All the other tests (cctbx/scitbx/libtbx/iotbx/rstbx and remaining dxtbx) completed successfully. Tests were run via libtbx.run_tests_parallel with nproc=4. As far as I can tell there is no debug output. The libtbx testing suite does not support timeouts like some timeout decorators on python unittest? As far as I can tell tst_dxtbx.py at the moment runs 5 separate tests, so for future debugging it may make sense to split these up. -Markus -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom _______________________________________________ cctbxbb mailing list [email protected]mailto:[email protected] http://phenix-online.org/mailman/listinfo/cctbxbb _______________________________________________ cctbxbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/cctbxbb
participants (2)
-
Graeme.Winter@diamond.ac.uk
-
markus.gerstel@diamond.ac.uk