|
|
Boost Testing : |
Subject: Re: [Boost-testing] [EXTERNAL] Re: Suddenly takes > 9hours to test?
From: Steve M. Robbins (steve_at_[hidden])
Date: 2012-02-12 23:19:06
Hi Noel,
On Mon, Feb 06, 2012 at 05:56:23PM +0000, Belcourt, Kenneth wrote:
> Hi,
>
> I neglected to mention that I made a change to the trunk build tools
> in rev. 76862. I tested this change set with the Sandia testers for
> a month so I felt pretty good about it but I'm now concerned I may
> have broken FreeBSD or other unix testers. This change shouldn't be
> in release, only in trunk.
The reason it affects release is that the release testing scripts uses
the TRUNK version of boost build.
> Can you try building with an earlier
> trunk rev. and see if the behavior improves?
I have just now verified that rev 76861 is OK and 76862 behaves badly.
> I'm happy to revert the change if it's causing any problems, just let me know.
I think that's best.
I'm trying to figure out the issue. As best as I understand at
present, the "mpi-run" lines in bjam result in the command line
"mpirun -np 2 distributed_property_map_test" (etc). If run by hand,
this command finishes normally. When run by bjam, the two spawned
distributed_property_map_test processes seem to execute properly
(output is written to appropriate file) but they don't finish -- the
processes hang around as zombies. The mpirun process seems to be
stuck in a poll() loop, according to strace.
I'm looking at the diff for 76862 now. The change message reads:
Changes to get verbose compiler output down to a manageable size.
Added option, -mN to limit output to N kb. Default is to capture
all compiler generated output. Added this option to ignore massive
compiler diagnostic outout associated with some compilers. With
this change, I can increase the nightly timeout to longer than 300
seconds to give some slower compilers a change to finish compiling.
However, there is also a bunch of child process handling stuff. Is
that related to the "-mN" option in some way?
Cheers,
-Steve