2 tests in test-spawn fail about libuv HOT 10 CLOSED

Can you tell me how you built libuv and how you ran the test suite (and as what user)? Can you post the output of uname -a? Thanks.

EDIT: Forgot to ask: are the failures repeatable?

from libuv.

Just checked v0.11.29, and that version passes all tests just fine.

@bnoordhuis That's done by portage automatically if I set FEATIRES="test". I already ran it manually by going into BUILD_DIR, and from there running
./test/run-tests
With "root" user.

uname -a says:
Linux TP_L520 3.17.4-gentoo #1 SMP Tue Nov 25 14:20:32 CET 2014 x86_64 Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz GenuineIntel GNU/Linux

from libuv.

With "root" user.

That's probably part of the problem, the tests aren't really supposed to be run as root. What happens when you run the test suite as a regular user? You should probably do a git clean -dfx first, to clean out the test fixtures.

from libuv.

Portage uses the user "portage" to compile, as long as I don't tell it to use root (security...). And I actually copied the wrong output ;) The one I posted was when running tests as root. Portage only failed at spawn_reads_child_path
I now built libuv with my day-to-day user, and again I have that one test fail.

from libuv.

Does the test also fail when you run test/run-tests spawn_reads_child_path spawn_reads_child_path manually? Is the 'portage' user restricted in any way, like, say, having reduced capabilities? Can you post the verbatim output from the failing test?

from libuv.

./test/run-tests spawn_reads_child_path spawn_reads_child_path                                                                                                                            exit_cb
Assertion failed in test/test-spawn.c on line 66: exit_status == 1
[1]    26494 abort      ./test/run-tests spawn_reads_child_path spawn_reads_child_path

(as normal user in my $HOME)

The portage user is only in the portage group, no further gropus. AFAIK it's to allow it to access the build directory. Building is furthermore done in a sandbox, so everything is quite restricted.
But as the test also fails as normal user (not portage) in a clean git checkout I think the failure has nothing to do with Portage.

Concerning "verbatim output": The outputs I posted are verbatim. Do you mean something different?

And just in case you missed the point: All tests pass with v0.11.29 (and test-spawn.c did not change since 0.11.29 was tagged)

from libuv.

Okay, noted. Not sure what it could be, the test works okay locally and on the CI, last time I checked. Can you git bisect it?

from libuv.

Well, I really don't undertand the result :/
e524f89 is the first bad one...
Going one commit back and everything is fine. I used git clean -dfx after ech git bisect round, built from ground up, so everything should have been right. How can changing the version influence the test result of ONE single test?

from libuv.

The spawn_child fail is probably a duplicate of joyent/libuv#1539 (If relevant: I do most of my testing on Gentoo as well).

from libuv.

Tentatively closing since this seems fixed. None of the Jenkins slaves are able to reproduce it.

If it fails again, please ask and I'll reopen :-)

from libuv.