Closed Bug 795254 Opened 12 years ago Closed 10 years ago

Intermittent test_private_necko_channel.js | test failed (with xpcshell return code: 0) | -1 == 1 | Error in closure function: 2147500036

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla22

People

(Reporter: emorley, Assigned: jduell.mcbugs)

References

Details

(Keywords: intermittent-failure)

Attachments

(2 files, 1 obsolete file)

fix test to respond with 200, not 400 HTTP status
1.49 KB, patch
jdm
: review+
Details | Diff | Splinter Review
rename test_private_channel.js
1.12 KB, patch
jdm
: review+
Details | Diff | Splinter Review 
Rev3 WINNT 6.1 mozilla-inbound opt test xpcshell on 2012-09-26 09:09:22 PDT for push 745b5180e4eb

slave: talos-r3-w7-072

https://tbpl.mozilla.org/php/getParsedLog.php?id=15559333&tree=Mozilla-Inbound

{
TEST-INFO | C:\talos-slave\test\build\xpcshell\tests\netwerk\test\unit\test_private_channel.js | running test ...
TEST-UNEXPECTED-FAIL | C:\talos-slave\test\build\xpcshell\tests\netwerk\test\unit\test_private_channel.js | test failed (with xpcshell return code: 0), see following log:
>>>>>>>

TEST-INFO | (xpcshell/head.js) | test 1 pending

TEST-INFO | (xpcshell/head.js) | test 2 pending

TEST-INFO | (xpcshell/head.js) | test 2 finished

TEST-INFO | (xpcshell/head.js) | running event loop

TEST-PASS | C:/talos-slave/test/build/xpcshell/tests/netwerk/test/unit/head_channels.js | [null : 147] 321 == 321

TEST-PASS | C:/talos-slave/test/build/xpcshell/tests/netwerk/test/unit/test_private_channel.js | [checkRequest : 47] 0 == 0

TEST-UNEXPECTED-FAIL | C:/talos-slave/test/build/xpcshell/tests/netwerk/test/unit/test_private_channel.js | -1 == 1 - See following stack:
JS frame :: C:\talos-slave\test\build\xpcshell\head.js :: do_throw :: line 451
JS frame :: C:\talos-slave\test\build\xpcshell\head.js :: _do_check_eq :: line 545
JS frame :: C:\talos-slave\test\build\xpcshell\head.js :: do_check_eq :: line 566
JS frame :: C:/talos-slave/test/build/xpcshell/tests/netwerk/test/unit/test_private_channel.js :: checkRequest :: line 48
JS frame :: C:/talos-slave/test/build/xpcshell/tests/netwerk/test/unit/head_channels.js :: <TOP_LEVEL> :: line 152
native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0

TEST-INFO | (xpcshell/head.js) | exiting test

TEST-UNEXPECTED-FAIL | C:/talos-slave/test/build/xpcshell/tests/netwerk/test/unit/head_channels.js | Error in closure function: 2147500036 - See following stack:
JS frame :: C:\talos-slave\test\build\xpcshell\head.js :: do_throw :: line 451
JS frame :: C:/talos-slave/test/build/xpcshell/tests/netwerk/test/unit/head_channels.js :: <TOP_LEVEL> :: line 154
native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0

TEST-INFO | (xpcshell/head.js) | exiting test
!!! error running onStopped callback: TypeError: callback is not a function
<<<<<<<
}
OS: All → Windows 7
Hardware: All → x86
Rev3 WINNT 6.1 mozilla-inbound opt test xpcshell on 2012-09-27 10:13:58 PDT for push c5a7b7544f12

slave: talos-r3-w7-039

https://tbpl.mozilla.org/php/getParsedLog.php?id=15600132&tree=Mozilla-Inbound
Whiteboard: [orange]
Please can you find an owner for this intermittent-failure - the current overall tree intermittent failure rate is spiralling out of control & the majority of bugs are unowned (see dev.platform thread).
Flags: needinfo?(bsmith)
ehsan is the original test author.
Assignee: nobody → ehsan
Flags: needinfo?(bsmith)
The errors in the log here are weird:

  INFO -  !!! error running onStopped callback: TypeError: callback is not a function

This is httpd.js, and the callback in question gets set by 

   httpserver.stop(do_test_finished);

The callback should == do_test_finished, which is a function, so not sure what's up.

  TEST-UNEXPECTED-FAIL | C:/talos-slave/test/build/tests/xpcshell/tests/image/test/unit/test_private_channel.js | 1 == 2 

All the tests I see put a constant on the right, and it's never 2, so I don't know where this line is.

Maybe my little typo fix will miraculously cure this.
Attachment #721502 - Flags: review?(ehsan)
If the server shuts down uncleanly we can also set the callback to an empty function:

  http://mxr.mozilla.org/mozilla-central/source/netwerk/test/httpserver/httpd.js#1155

But that shouldn't give us "not a function" either.
So there's 4 (!) different copies in the tree of http.js (why?).  Which one do we run for xpcshell tests?
Flags: needinfo?(jwalden+bmo)
Comment on attachment 721502 [details] [diff] [review]
fix a typo that /might/ fix this?

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

We run netwerk/test/httpserver/httpd.js, and there are four copies because Mozilla has a culture of copying rather than sharing when there's a slight roadbump in the way of doing so.  :-(

This isn't the right fix.  Whoever wrote this test didn't grok the interface.  A handler, by default, synchronously produces its entire response.  It's totally legal to have an entirely empty handler that does nothing -- gives you 200 OK and no content, if I remember right.  You have to opt into asynchronous behavior.  And if you don't opt into it, finish() will throw an error.  That in turn, for sync handlers, will cause a (usually) 500 response to be returned.

This is all documented in nsIHttpResponse::finish (and maybe processAsync/seizePower too, although finish notes it throws if sync) and nsIHttpRequestHandler::handle.  I'm not sure how this ever was supposed to work, or why it might ever work now.
Attachment #721502 - Flags: review?(ehsan)
Flags: needinfo?(jwalden+bmo)
Comment on attachment 721502 [details] [diff] [review]
fix a typo that /might/ fix this?

Yeah I think you should just remove this line...  The test should work fine without it.
In order to determine why this test fails intermittently though, I think you should add some debug output to dump the URLs found in get_device_entry_count to see what URLs we see in the cache when this test fails...
Let's see if this gets rid of the orange.  If not, I'll try ehsan's suggestion and print out cache entries.
Assignee: ehsan → jduell.mcbugs
Attachment #721502 - Attachment is obsolete: true
Attachment #721862 - Flags: review?(jwalden+bmo)
I think there is some confusion here. The TBPL logs point to test_private_channel.js in image/test/unit, not netwerk/test/unit. jdm wrote the one in image/test/unit, and it looks like it's failing on the HTTP response count at line http://mxr.mozilla.org/mozilla-central/source/image/test/unit/test_private_channel.js#89.

This test is already providing a non-empty response.

05:27:47  WARNING -  TEST-UNEXPECTED-FAIL | c:/talos-slave/test/build/tests/xpcshell/tests/image/test/unit/test_private_channel.js | 1 == 2 - See following stack:
05:27:47  WARNING -  This is a harness error.
05:27:47     INFO -  JS frame :: c:\talos-slave\test\build\tests\xpcshell\head.js :: do_throw :: line 461
05:27:47     INFO -  JS frame :: c:\talos-slave\test\build\tests\xpcshell\head.js :: do_report_result :: line 563
05:27:47     INFO -  JS frame :: c:\talos-slave\test\build\tests\xpcshell\head.js :: _do_check_eq :: line 573
05:27:47     INFO -  JS frame :: c:\talos-slave\test\build\tests\xpcshell\head.js :: do_check_eq :: line 580
05:27:47     INFO -  JS frame :: c:/talos-slave/test/build/tests/xpcshell/tests/image/test/unit/test_private_channel.js :: <TOP_LEVEL> :: line 89
05:27:47     INFO -  JS frame :: image_load_helpers.js :: onLoadcomplete :: line 56
05:27:47     INFO -  native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0
Flags: needinfo?(josh)
Glorious.
We're actually getting failures in both the netwerk and image test_private_channel tests, and they're both being starred here. The netwerk test is failing when there are no memory cache entries in existence. The image test is failing when we only hit the network once, which is not good.
Flags: needinfo?(josh)
Hmm.  How about we review and land this patch in this bug and see if it fixes the /netwerk test, and we can fork a new bug for the image_load failure?  

(maybe we could even rename test_private_channel.js in one location so this doesn't happen again?)
Filed bug 848621 for the image test_private_channel.js.   

This patch renames the /netwerk one so we stop confusing people.
Attachment #721962 - Flags: review?(josh)
Attachment #721962 - Flags: review?(josh) → review+
Attachment #721862 - Flags: review?(jwalden+bmo) → review?(josh)
Attachment #721862 - Flags: review?(josh) → review+
https://hg.mozilla.org/mozilla-central/rev/fed3eba78414
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
Sneaky McSneakypants, renaming it but not changing the bug summary - I was 99% of the way through refiling it when my memory kicked in.

https://tbpl.mozilla.org/php/getParsedLog.php?id=20730152&tree=Mozilla-Inbound
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: Intermittent test_private_channel.js | test failed (with xpcshell return code: 0) | -1 == 1 | Error in closure function: 2147500036 → Intermittent test_private_necko_channel.js | test failed (with xpcshell return code: 0) | -1 == 1 | Error in closure function: 2147500036
Closing inactive keywords:intermittent-failure bugs where the TBPLbot has previously commented and the test isn't marked as disabled; filter on orange-cleanup-201401.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: