Re: [Boost-testing] [python tests] tests hang (OSX)

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
> <raffi.enficiaud_at_[hidden]
> <mailto:raffi.enficiaud_at_[hidden]>> wrote:
>
>     Hi,
>
>     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.
>
>
>
>     """
>     darwin.compile.c++
>     ../bin.v2/libs/python/build/__darwin-4.2.1/debug/object/__function_doc_signature.o
>     darwin.link.dll
>     ../bin.v2/libs/python/build/__darwin-4.2.1/debug/libboost___python.dylib
>     darwin.link.dll
>     ../bin.v2/libs/parameter/test/__python_test.test/darwin-4.2.1/__debug/python_test_ext.so
>     """
>
>
>
>     Questions:
>     - 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 < 
/dev/null

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 
script.

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.

>[snip]
>
>     - 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.
>

Any pointers?

So what about adding "< /dev/null" to the launching line?

Best,
Raffi Enficiaud