Closed Bug 913848 Opened 6 years ago Closed 6 years ago

Intermittent OSX test_unix_domain.jsd | Test timed out | test failed (with xpcshell return code: -9)

Categories

(Core :: Networking, defect)

x86_64
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla26
Tracking Status
firefox24 --- unaffected
firefox25 --- unaffected
firefox26 --- fixed

People

(Reporter: jimb, Assigned: jimb)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

This test, recently added by bug 892114, seems to hang from time to time on OSX 10.6, in the very first test that actually exchanges data on a Unix domain socket.

TEST-INFO | $testdir/test_unix_domain.js | Starting test_echo
TEST-INFO | (xpcshell/head.js) | test test_echo pending (2)
TEST-INFO | $testdir/test_unix_domain.js | "creating socket: $tmpdir/tmpIcdYeQ/socket"
TEST-PASS | $testdir/test_unix_domain.js | [test_echo : 115] "$tmpdir/tmpIcdYeQ/socket" == "$tmpdir/tmpIcdYeQ/socket"
TEST-PASS | $testdir/test_unix_domain.js | [test_echo : 116] 0 == 0
TEST-INFO | (xpcshell/head.js) | test run_next_test 0 finished (2)
TEST-INFO | $testdir/test_unix_domain.js | "called test_echo's onSocketAccepted"
TEST-PASS | $testdir/test_unix_domain.js | [test_echo/<.onSocketAccepted : 77] [xpconnect wrapped nsIServerSocket @ 0x10687e3a0 (native @ 0x10687e108)] == [xpconnect wrapped nsIServerSocket @ 0x10687e3a0 (native @ 0x10687e108)]
TEST-PASS | $testdir/test_unix_domain.js | [test_echo/<.onSocketAccepted : 83] 3 == 3
TEST-PASS | $testdir/test_unix_domain.js | [test_echo/<.onSocketAccepted : 84] "$tmpdir/tmpIcdYeQ/socket" == "$tmpdir/tmpIcdYeQ/socket"
TEST-PASS | $testdir/test_unix_domain.js | [test_echo/<.onSocketAccepted : 88] "" == ""
TEST-PASS | $testdir/test_unix_domain.js | [test_echo/<.onSocketAccepted : 89] 0 == 0
TEST-PASS | $testdir/test_unix_domain.js | [test_echo/<.onSocketAccepted : 91] 3 == 3
TEST-PASS | $testdir/test_unix_domain.js | [test_echo/<.onSocketAccepted : 92] "" == ""
<<<<<<<
No idea if this matters, but here's a try push where the test uses asyncWait on the server side as well as the client side.

https://tbpl.mozilla.org/?tree=Try&rev=593fe8aec152
Duplicate of this bug: 913856
Summary: Intermittent OSX 10.6 test_unix_domain.jsd | Test timed out | test failed (with xpcshell return code: -9) → Intermittent OSX test_unix_domain.jsd | Test timed out | test failed (with xpcshell return code: -9)
This patch makes the tests avoid expecting data from the client to be
available to the server immediately upon accepting a connection; instead,
the server uses asyncWait to receive those first bytes. This changes both
test_echo and test_connect_permission.

I've pushed this through the try server twice, and it didn't hang. In
either case, it adds a few more do_prints to give me more clues about the
source of the problem.
Attachment #801692 - Flags: review?(honzab.moz)
Comment on attachment 801692 [details] [diff] [review]
Attempt to fix intermittent test_unix_domain.js timeout with MOAR ASYNC.

Review of attachment 801692 [details] [diff] [review]:
-----------------------------------------------------------------

r=honzab

::: netwerk/test/unit/test_unix_domain.js
@@ -374,5 @@
>      let client3Input = new ScriptableInputStream(aStream);
>  
>      do_check_eq(client3Input.readBytes(11), "Ferlingatti");
>  
> -    aStream.close();

Why is has this been removed?
Attachment #801692 - Flags: review?(honzab.moz) → review+
(In reply to Honza Bambas (:mayhemer) from comment #12)
> Comment on attachment 801692 [details] [diff] [review]
> Attempt to fix intermittent test_unix_domain.js timeout with MOAR ASYNC.
> 
> Review of attachment 801692 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> r=honzab
> 
> ::: netwerk/test/unit/test_unix_domain.js
> @@ -374,5 @@
> >      let client3Input = new ScriptableInputStream(aStream);
> >  
> >      do_check_eq(client3Input.readBytes(11), "Ferlingatti");
> >  
> > -    aStream.close();
> 
> Why is has this been removed?

In this context, aStream is client3AsyncInput, which is client3's input stream. The next line calls client3.close, which is exactly "close my input; close my output". When I wrote the test I thought nsISocketTransport::close did something more than that; but it turns out the two are completely redundant.
One more paranoid try push (I made one of the other tests moar async, after my prior try):

https://tbpl.mozilla.org/?tree=Try&rev=428ffadbafea
(In reply to TBPL Robot from comment #28)

See how this tastes:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4268c777e3c5
Flags: in-testsuite+
Target Milestone: --- → mozilla26
https://hg.mozilla.org/mozilla-central/rev/4268c777e3c5
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.