[log] MSVC 9 build hangs
Hi, Many test results for Boost.Log on teeks99-03b-win2008-64on64 [1] show that the build aborts due to timeout. From the test setup description (2 GiB of RAM, 2 CPUs, 4 build jobs) it seems that the problem could be in the insufficient system resources. 4 jobs building Boost.Log can easily exceed 2 gigs of RAM, especially considering some of the memory is reserved by OS and other programs. If there isn't any swap, the build may be just aborting, and if there is, it's probably performing dead slow. And 2 cores might also be too limiting. Could the tester take a look what is happening on that setup? If it's not a resource problem, then I would appreciate any information on the problem. [1] http://www.boost.org/development/tests/trunk/developer/log.html
On Saturday 31 August 2013 10:18:52 Tom Kent wrote:
Hmm, then lack of memory should not be an issue. Is CPU count actual? Also, is the timeout applied to the whole library compilation or some particular stage? Or the whole Boost?
As to the 4 jobs, are you referring to the -j4 option?
Yes.
On Wed, Sep 4, 2013 at 4:01 PM, Tom Kent <lists@teeks99.com> wrote:
I think you should be able to run tests by simply invoking b2 in the tests directory. I.e.: cd libs\log\test b2 --toolset=msvc-11.0 -j4 address-model=64 if the command line on the test stand info page [1] is accurate. This command won't check for timeout though. I'm not sure how to measure time from the command line on Windows. [1] http://www.boost.org/development/tests/trunk/teeks99-03d-win2008-64on64.html
Ok, so I just looked at this some more and discovered something that I had previously overlooked. It isn't the tests that are timing out, it is the *linker*. I'm assuming this is due to the rediculously large library sizes for log on windows. If we can't substanitally trim down the size of this library, then we should probably look for a way to increase the test timeout value (hopefully just for this linker step and nothing else). Tom On Tue, Sep 10, 2013 at 10:25 PM, Andrey Semashev <andrey.semashev@gmail.com
wrote:
On Wed, Sep 11, 2013 at 5:28 PM, Tom Kent <lists@teeks99.com> wrote:
I did some refactoring to reduce library sizes several weeks ago. The static library sizes went down ~50%, AFAIR. Ironically, I don't remember seeing such test failures before the refactoring. I'm not sure I will be able to shrink it any further without disabling portions of the library or building some customized version just for tests. And I'd like to avoid it since the tests will be run on a non-default version, which will not be what is shipped to users. I tried building the library and tests on my local machine many times and I've never seen linking to take 5 minutes. I have another setup though. Did you notice any other abnormal behavior, such as memory growth or swapping or compiler/linker crashes maybe? Does linking ever complete?
On Mon, Sep 30, 2013 at 6:10 PM, Tom Kent <lists@teeks99.com> wrote:
So, apparently it is something other than the timeout (or the timeout is longer than 10) because they are still failing with --timeout=10: http://www.boost.org/development/tests/trunk/developer/output/teeks99-03d-wi...
On 10/2/2013 8:43 PM, Tom Kent wrote: [ ...]
I found some recent change in Boost.Concept will cause a compilation error, which will cause fails in several libs, including Log, Graph, etc. I'm not sure if it is what being discussed here. A small script code to demo it: // Begin test_code.cpp #include <boost/concept_check.hpp> #include <boost/concept/detail/concept_def.hpp> namespace boost { BOOST_concept(ReadableIterator, (Iterator)) : boost::Assignable<Iterator> , boost::CopyConstructible<Iterator> { }; } int main(int argc, char* argv[]) { return 0; } // End test_code.cpp Supposed boost trunk is in c:\boost, then open a VS2012/VS2013RC command line and run: cl /EHsc -I c:\boost test_code.cpp will get: test_code.cpp(7) : error C2065: 'ReadableIterator' : undeclared identifier The similar error will happen while compiling Log, Graph, etc. -- cg
On Thu, Oct 3, 2013 at 6:11 AM, cg <chengang31@gmail.com> wrote:
I'm not seeing this error in testing reports (the latest MSVC-11 builds are 86133 on Goonland and 86125 on teeks99). The problem we're facing is build timeouts, with no other errors. I'll try to build the latest trunk this evening, but my guess is that your problem is not related to timeouts.
On Wed, Oct 2, 2013 at 7:43 AM, Tom Kent <lists@teeks99.com> wrote:
So are you sure the flag is just --timeout=10? I have that in my script, but it doesn't seem to be picking it up...aka when the command is put at the bottom of the html page for the test runner, it shows the command correctly, but without that part of it. Is it possible that it is getting thrown out by run.py somehow? http://www.boost.org/development/tests/trunk/teeks99-03a-win2008-64on64.html The actual command I'm running: python run.py --runner=teeks99-03a-win2008-64on64 --force-update --toolsets=msvc-8.0 --bjam-options="-j2 address-model=64" --timeout=10 --comment=..\info.html --timeout=10 2>&1 | ..\wtee output.log The one that shows up in the above link: run.py --runner=teeks99-03a-win2008-64on64 --force-update --toolsets=msvc-8.0 \ "--bjam-options=\"-j4 address-model=64\"" --comment=..\\info.html Any ideas what is going on here? Tom
On Thursday 03 October 2013 16:37:45 Tom Kent wrote:
I don't know, I've never set up a testing machine for Boost before. The parameter does seem to be present for some other testers, for instance: http://www.boost.org/development/tests/trunk/VC8%20jc-bell-com.html
On Friday 04 October 2013 01:56:10 you wrote:
Tom, is it possible that multiple builds are run simultaneously on the same machine, and because each build tries to utilize all CPUs the whole system becomes overutilized? Just an idea of a possible cause of such long builds. Also, I've committed a change yesterday, which may save a few seconds of building (at least it did save as much on my setup).
participants (3)
-
Andrey Semashev -
cg -
Tom Kent