Boost Testing :
Subject: Re: [Boost-testing] [python tests] tests hang (OSX)
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2015-01-28 10:26:07
Le 27/01/15 17:00, Rene Rivera a écrit :
> On Tue, Jan 27, 2015 at 2:46 AM, Raffi Enficiaud
> <mailto:raffi.enficiaud_at_[hidden]>> wrote:
> I am experiencing some problems when I run the tests in
> $root/status/. At some point, apparently when testing the first
> python extension, the test seem to hang and I have to kill the
> process manually. I am running OSX Yosemite, XCode 5.1.1 toolchain.
> - is this a known issue?
> Not known.
I did a clean clone on master and the problem is also there.
We managed to solve it!
The solution is to add "< /dev/null" to
$root/tools/build/src/tools/testing.jam, in "actions capture-output bind
INPUT_FILES output-file". The launching line becomes then:
$(LAUNCHER) "$(>)" $(ARGS) "$(INPUT_FILES)" > "$(output-file)" 2>&1 <
The way we did to debug it, for the record:
- ps -ef | grep python when it hangs gives the full command line
- identify the jam file that contains the logic (which I did not know)
- then just try random things on pipes with lsof and this testing.jam
So apparently the python binary on my machine is trying to open a pipe
to read from stdin, which then blocks the python process.
I think "< /dev/null" is a desired behaviour for the tests anyway, what
do you think?
> - is it possible to know what is the call to the test and what is
> the test waiting for?
> You could add "-d+2" to see the commands. Although it might print those
> out after running so it might not help. And I don't remember at the
> moment if there's an option to avoid the output buffering.
This option really did not help.
> - if any of these question above have already an answer in a boost
> related web page, where should I look?
> Some of them are.. But in various places.
So what about adding "< /dev/null" to the launching line?