Regressions: timeout for compile and run
CW 9 and Intel 8 regressions did not run (better: finish) for some days because I've been away and had no chance to confirm the popups of assertion failures which were produced by some test cases!@!@! Is there no possibility to set a timeout after the compile/run process is killed by bjam? I don't see any sense behind giving a test case more than 5 minutes to run! Stefan
Stefan Slapeta writes:
CW 9 and Intel 8 regressions did not run (better: finish) for some days because I've been away and had no chance to confirm the popups of assertion failures which were produced by some test cases!@!@!
Is there no possibility to set a timeout after the compile/run process is killed by bjam? I don't see any sense behind giving a test case more than 5 minutes to run!
Stefan, Please see my reply to Rob Lievaart for our solution to this -- http://article.gmane.org/gmane.comp.lib.boost.devel/106555. -- Aleksey Gurtovoy MetaCommunications Engineering
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Aleksey Gurtovoy
Stefan,
Please see my reply to Rob Lievaart for our solution to this -- http://article.gmane.org/gmane.comp.lib.boost.devel/106555.
Oh, seems I've missed this posting! (And I would have been very surprised if you had no a solution yet :) Stefan
Stefan Slapeta writes:
Stefan,
Please see my reply to Rob Lievaart for our solution to this -- http://article.gmane.org/gmane.comp.lib.boost.devel/106555.
Oh, seems I've missed this posting! (And I would have been very surprised if you had no a solution yet :)
A caveat: please replace your 'regression.py' with the attached revision which contains a relevant bug fix. -- Aleksey Gurtovoy MetaCommunications Engineering
Stefan Slapeta writes:
Aleksey Gurtovoy wrote:
A caveat: please replace your 'regression.py' with the attached revision which contains a relevant bug fix.
Aleksey, this script does not download the tarball, after the cleanup it attemps to begin with the decompression!
Ouch, sorry, should have tested the whole cycle. Please take the attached one instead. -- Aleksey Gurtovoy MetaCommunications Engineering
I picked this up also and am running it now. I had to make a change to the vc8.0 file as the directory name has changed for the beta AND, more importantly, the _drive_ I installed it on isn't the same as most of the rest of my programs. I hard coded it to start with, but possibly we need to discuss how to handle multiple compilers in wildly differing paths (on Windows, of course, we still have those insane drive letters). Oh, and the reason for the weird timestamp is that there's no timestamp file created...I manually made one before this run. There appears to be yet another "crash dialog box" created by one of the tests in vc8.0 (thought not in vc7.1... I'll try to capture it on this run) I also added --user=vawjr to most of the "separate commands" you have me using, I hope that was the right thing to do At Monday 2004-07-26 03:27, you wrote:
Stefan Slapeta writes:
Aleksey Gurtovoy wrote:
A caveat: please replace your 'regression.py' with the attached revision which contains a relevant bug fix.
Aleksey, this script does not download the tarball, after the cleanup it attemps to begin with the decompression!
Ouch, sorry, should have tested the whole cycle. Please take the attached one instead.
-- Aleksey Gurtovoy MetaCommunications Engineering
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
At Monday 2004-07-26 12:34, you wrote:
Victor A. Wagner Jr. wrote:
I picked this up also and am running it now.
Great! (the test, not the result, unfortunately...) Seems to me that this compiler is quite unstable at the moment.
well, all of the errors originally reported were due to the assumption on the part of the script as to where the latest beta would be located. That's fixed, and I just captured the "show stopper" error 9e2a6bf.jpg I've continued on from that point and will likely have a better result set shortly
Stefan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Aleksey Gurtovoy wrote:
Please see my reply to Rob Lievaart for our solution to this -- http://article.gmane.org/gmane.comp.lib.boost.devel/106555.
I think it should be sufficient to set a "lower than normal" process priority for build_monitor.exe. Otherwise the permanent context switching between the monitoring and the build process itself leads to a substantial overall decrease of performance for regression tests! Stefan
Stefan Slapeta writes:
Aleksey Gurtovoy wrote:
Please see my reply to Rob Lievaart for our solution to this -- http://article.gmane.org/gmane.comp.lib.boost.devel/106555.
I think it should be sufficient to set a "lower than normal" process priority for build_monitor.exe. Otherwise the permanent context switching between the monitoring and the build process itself leads to a substantial overall decrease of performance for regression tests!
Fixed in the CVS and the attached revision of the script. -- Aleksey Gurtovoy MetaCommunications Engineering
At Monday 2004-07-26 17:49, you wrote:
Stefan Slapeta writes:
Aleksey Gurtovoy wrote:
Please see my reply to Rob Lievaart for our solution to this -- http://article.gmane.org/gmane.comp.lib.boost.devel/106555.
I think it should be sufficient to set a "lower than normal" process priority for build_monitor.exe. Otherwise the permanent context switching between the monitoring and the build process itself leads to a substantial overall decrease of performance for regression tests!
Fixed in the CVS and the attached revision of the script.
ok, picked up the script (changed ext to ssh again.... then updated my cvs client to purportedly have an ext protocol that defaults to ssh, but it requires a re-boot and I'm still running tests). the install for vc7.1,vc8.0 created this in the (boost target directory)/include 2004-02-12 07:11 <DIR> boost-1_31 2004-05-29 21:03 <DIR> boost-1__1 the 2nd directory has NO files in it, just all the relevant directories that the includes SHOULD go in. the lib directory seems to be fine
-- Aleksey Gurtovoy MetaCommunications Engineering
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Aleksey Gurtovoy wrote:
Fixed in the CVS and the attached revision of the script.
Seems not to be perfect: - the build monitor is not started at all now - the upload does not work anymore: Traceback (most recent call last): File "regression.py", line 658, in ? commands[ command ]( **accept_args( args ) ) File "regression.py", line 536, in regression upload_logs( tag, runner, user ) File "regression.py", line 501, in upload_logs upload_logs( runner, tag, user ) TypeError: upload_logs() takes exactly 4 arguments (3 given) Stefan
Stefan Slapeta wrote:
- the build monitor is not started at all now
Ah, just seen that there is a new option --monitored. However, the upload does not work anyway, I've now uploaded the results manually to ftp://fx.meta-comm.com/boost-regression/CVS-HEAD/ Is this the right directory? Stefan
Stefan Slapeta writes:
Stefan Slapeta wrote:
- the build monitor is not started at all now
Ah, just seen that there is a new option --monitored.
However, the upload does not work anyway,
I hope updating to the new version of the script solved all this.
I've now uploaded the results manually to ftp://fx.meta-comm.com/boost-regression/CVS-HEAD/ Is this the right directory?
Yep. -- Aleksey Gurtovoy MetaCommunications Engineering
Stefan Slapeta writes:
Aleksey Gurtovoy wrote:
Fixed in the CVS and the attached revision of the script.
Seems not to be perfect:
- the build monitor is not started at all now
Hmm, given that you are not using the latest version of the script, it's unclear why this could be the case. What does the log say?
- the upload does not work anymore:
Sorry! That's due to the incompatibility between your version of script and newer components from the downloaded sources it tries to use -- something I totally overlooked when checking in the changes. Replacing your 'regression.py' with the attached revision will fix this. To upload the already collected logs, simply do python regression.py upload-logs --runner=<your-runner-id> Note that the attached version of script requires explicit '--monitored' flag to enable build monitoring: python regression.py --runner=<your-runner-id> --monitored Instructions are updated accordingly -- http://www.meta-comm.com/engineering/regression_setup/instructions.html#adva.... -- Aleksey Gurtovoy MetaCommunications Engineering
participants (1)
-
Aleksey Gurtovoy -
Stefan Slapeta -
Stefan Slapeta -
Victor A. Wagner Jr.