On May 18, 2005, at 9:49 AM, Jonathan Wakely wrote:

On Wed, May 18, 2005 at 08:59:54AM -0500, Douglas Gregor wrote:

...

The iostreams example_test and newline_test seem to be looping. I've killed them on the OSL tester, but now symmetric_filter_test is currently taking a really long time to run... with the exception of newline_test (which has been failing for a while), all of these tests were passing before yesterday's flurry of iostream modifications.

I was seeing newline_test loop when testing with GCC 3.4 at least 5 days ago. It completed OK when using GCC 4.0 and 4.1

Today, all of the iostreams tests seem to be looping for me. Any idea what happened? Doug

On May 18, 2005, at 11:20 AM, Martin Wille wrote:

Douglas Gregor wrote:

...

Today, all of the iostreams tests seem to be looping for me. Any idea what happened?

The same happens here.

I suggest we add something like

ulimit -m 524288; ulimit -d 524288; ulimit -v 523288; ulimit -t 600

to the script that runs the tests on Unix systems to make problems like this not break the testing procedure for everyone. (This sets memory limits to 512 MB and the CPU time limit to 600 seconds. There's no easy way of limiting the wall clock time taken.) Perhaps, the limits should be set even lower.

300 seconds should be sufficient. We can't just do this in regression.py, because we don't want it to apply to the entire bjam run. Instead, we need to set the ulimits when bjam invokes individual test cases. If a bjam expert doesn't pop up with help, I'll take a shot at it later today. Doug

From: Martin Wille <mw8329@yahoo.com.au>

Douglas Gregor wrote:

...

Today, all of the iostreams tests seem to be looping for me. Any idea what happened?

The same happens here.

I suggest we add something like

ulimit -m 524288; ulimit -d 524288; ulimit -v 523288; ulimit -t 600

to the script that runs the tests on Unix systems to make problems like this not break the testing procedure for everyone. (This sets memory limits to 512 MB and the CPU time limit to 600 seconds. There's no easy way of limiting the wall clock time taken.) Perhaps, the limits should be set even lower.

Managing the wall time of a task isn't hard: #!/bin/bash kill_if_still_alive() { sleep $1; kill $2 2>/dev/null } invoke_long_running_process& kill_if_still_alive 600 $!& wait %1 kill %2 -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;

On May 18, 2005, at 10:13 AM, Martin Wille wrote:

Douglas Gregor wrote:

...

The iostreams example_test and newline_test seem to be looping. I've killed them on the OSL tester, but now symmetric_filter_test is currently taking a really long time to run... with the exception of newline_test (which has been failing for a while), all of these tests were passing before yesterday's flurry of iostream modifications.

We need something in the build/test system that limits the amount of time and memory taken by the execution of tests. Without that, the tests can't be run unattended.

Yep. Perhaps we could teach Boost.Build about "ulimit" on *nix systems. Doug

On May 18, 2005, at 12:02 PM, Jonathan Turkanis wrote:

I'll try to address the problems reported in this thread, but if they turn out to be specific to Darwin or Linux I may need help. My suggestion is to wait until tomorrow, since some of the testers may have caught Iostreams in an inconsistent state.

Thanks for the quick response. My primary development platform is darwin, so if you need help running any tests just e-mail me privately. iostreams are rather opaque to me, but I'm good for compiles and backtraces :) Doug

Jonathan Turkanis wrote:

As for long running times, I doubled the number of times certain tests are run, with WOULD_BLOCK indicators occuring at different points in each iteration. Still, on my system no test takes more than about two second to run. Most run in less than a second.

Here are my local results:

[...]

I'll try to address the problems reported in this thread, but if they turn out to be specific to Darwin or Linux I may need help. My suggestion is to wait until tomorrow, since some of the testers may have caught Iostreams in an inconsistent state.

Symptoms on Linux: several tests, including bzip2, gzip and newline, get stuck in a busy loop. No system calls are executed in that loop. Waiting won't work, since I'll have to kill the hanging tests manually (for a couple of toolsets). I'll restart the whole test cycle here. Results will get published within 12-24 hours if everything goes well. Regards, m

Martin Wille wrote:

...

Symptoms on Linux: several tests, including bzip2, gzip and newline, get stuck in a busy loop. No system calls are executed in that loop.

Waiting won't work, since I'll have to kill the hanging tests manually (for a couple of toolsets). I'll restart the whole test cycle here. Results will get published within 12-24 hours if everything goes well.

No improvement after a cvs update. symmetric_filter_test shows the same symptoms.

Okay, I've temporarily commented out compression test, symmetric_filter_test and newline_test. I'll try to figue out what's wrong later tonight. Jonathan

Jonathan Turkanis wrote:

I'm now testing the hypothesis that the problem is std::rand behaving badly on these platforms. I've switched to Boost.Random, and have left just one of the problem tests, newline_test.cpp, uncommented.

newline_test passes now (intel 8.1/Linux) taking only 1.2 seconds here when I run it manually. Regards, m

Douglas Gregor wrote:

On May 19, 2005, at 2:21 AM, Martin Wille wrote:

...

Jonathan Turkanis wrote:

...

I'm now testing the hypothesis that the problem is std::rand behaving badly on these platforms. I've switched to Boost.Random, and have left just one of the problem tests, newline_test.cpp, uncommented.

newline_test passes now (intel 8.1/Linux) taking only 1.2 seconds here when I run it manually.

Works on gcc-3_3-darwin, too. Thanks Jonathan!

No problem -- I'm glad it turned out to be something simple. Jonathan