Closed Bug 610654 Opened 14 years ago Closed 14 years ago

TEST-UNEXPECTED-FAIL | /Users/cltbld/talos-slave/mozilla-central_leopard-o-debug_test-xpcshell/build/xpcshell/tests/netwerk/test/unit/test_bug596443.js | Response1 == Response0

Categories

(Core :: Networking: Cache, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b8

People

(Reporter: MatsPalmgren_bugz, Assigned: bjarne)

References

Details

(Keywords: intermittent-failure)

Attachments

(2 files, 1 obsolete file)

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1289303682.1289307670.30574.gz

s: talos-r3-w7-029
TEST-UNEXPECTED-FAIL | c:\talos-slave\mozilla-central_win7_test-xpcshell\build\xpcshell\tests\netwerk\test\unit\test_bug596443.js | test failed (with xpcshell return code: 0), see following log:
TEST-UNEXPECTED-FAIL | c:/talos-slave/mozilla-central_win7_test-xpcshell/build/xpcshell/tests/netwerk/test/unit/test_bug596443.js | Response1 == Response0 - See following stack:
TEST-UNEXPECTED-FAIL | c:/talos-slave/mozilla-central_win7_test-xpcshell/build/xpcshell/tests/netwerk/test/unit/test_bug596443.js | Response0 == Response1 - See following stack:
TEST-UNEXPECTED-FAIL | c:/talos-slave/mozilla-central_win7_test-xpcshell/build/xpcshell/tests/netwerk/test/unit/test_bug596443.js | Response0 == Response1 - See following stack:
Blocks: 438871
Apparently, httpd.js may swap the order of responses (despite 100ms timeout between them). This fix triggers the second response when the first finishes, enforcing the expected order. Requesting review and approval...
Assignee: nobody → bjarne
Status: NEW → ASSIGNED
Attachment #489167 - Flags: review?(bzbarsky)
Attachment #489167 - Flags: approval2.0?
Comment on attachment 489167 [details] [diff] [review]
Properly controlled response-sequence

OK, thoguh it's not clear to me why the do_timeout stuff is needed at all.
Attachment #489167 - Flags: review?(bzbarsky)
Attachment #489167 - Flags: review+
Attachment #489167 - Flags: approval2.0?
Attachment #489167 - Flags: approval2.0+
(In reply to comment #7)
> Comment on attachment 489167 [details] [diff] [review]
> Properly controlled response-sequence
> 
> OK, thoguh it's not clear to me why the do_timeout stuff is needed at all.

Requesting check-in. The do_timeout is to ensure we trigger the next step after OnStopRequest has returned, otherwise strange effects often pop up.
Keywords: checkin-needed
Backed out in http://hg.mozilla.org/mozilla-central/rev/212a391d3b79

I.e. it must be caused by something else...  will have a look.
Keywords: checkin-needed
Like before but use request-header to carry the desired response to the handler (making it independent of the order of calls to the handler). Requesting review and approval again...
Attachment #489167 - Attachment is obsolete: true
Attachment #489642 - Flags: review?(bzbarsky)
Rev3 MacOSX Leopard 10.5.8 mozilla-central debug test 
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1289428929.1289430276.4039.gz

s: talos-r3-leopard-037
TEST-UNEXPECTED-FAIL | /Users/cltbld/talos-slave/mozilla-central_leopard-o-debug_test-xpcshell/build/xpcshell/tests/netwerk/test/unit/test_bug596443.js | test failed (with xpcshell return code: 0), see following log:
TEST-UNEXPECTED-FAIL | /Users/cltbld/talos-slave/mozilla-central_leopard-o-debug_test-xpcshell/build/xpcshell/tests/netwerk/test/unit/test_bug596443.js | Response1 == Response0 - See following stack:
TEST-UNEXPECTED-FAIL | /Users/cltbld/talos-slave/mozilla-central_leopard-o-debug_test-xpcshell/build/xpcshell/tests/netwerk/test/unit/test_bug596443.js | Response0 == Response1 - See following stack:
TEST-UNEXPECTED-FAIL | /Users/cltbld/talos-slave/mozilla-central_leopard-o-debug_test-xpcshell/build/xpcshell/tests/netwerk/test/unit/test_bug596443.js | Response0 == Response1 - See following stack:
Comment on attachment 489642 [details] [diff] [review]
Listeners chained, desired return-value passed as header

r=me
Attachment #489642 - Flags: review?(bzbarsky) → review+
Keywords: checkin-needed
Comment on attachment 489642 [details] [diff] [review]
Listeners chained, desired return-value passed as header

Note that we has approval for 2.0 from the previous patch
Well, I guess "we have" would be a better way to phrase it...  :)
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1289577947.1289579633.19283.gz
Rev3 MacOSX Leopard 10.5.8 mozilla-central debug test xpcshell on 2010/11/12 08:05:47
s: talos-r3-leopard-005


TEST-INFO | /Users/cltbld/talos-slave/mozilla-central_leopard-o-debug_test-xpcshell/build/xpcshell/tests/netwerk/test/unit/test_bug596443.js | running test ...

command timed out: 1200 seconds without output, killing pid 310

I'll take straight-up failure over a no output hang any day.
I am hitting this on the newly added Win7 debug unit tests:
https://bugzilla.mozilla.org/show_bug.cgi?id=614956#c5

We need to fix this before we can do the switchover from running _debug_ unit
tests on the Win2003 machines to the Win7 Rev3 machines.

If this is not the same issue please let me know and I will file a new bug.

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1291225061.1291231409.29838.gz

TEST-UNEXPECTED-FAIL |
c:\talos-slave\mozilla-central_win7-debug_test-xpcshell\build\xpcshell\tests\netwerk\test\unit\test_bug596443.js
| test failed (with xpcshell return code: 0), see following log:
TEST-UNEXPECTED-FAIL |
c:/talos-slave/mozilla-central_win7-debug_test-xpcshell/build/xpcshell/tests/netwerk/test/unit/test_bug596443.js
| Response1 == Response0 - See following stack:
TEST-UNEXPECTED-FAIL |
c:/talos-slave/mozilla-central_win7-debug_test-xpcshell/build/xpcshell/tests/netwerk/test/unit/test_bug596443.js
| Response0 == Response1 - See following stack:
TEST-UNEXPECTED-FAIL |
c:/talos-slave/mozilla-central_win7-debug_test-xpcshell/build/xpcshell/tests/netwerk/test/unit/test_bug596443.js
| Response0 == Response1 - See following stack:
Blocks: 614956
Fun question, whether the five in a row since you turned on scraping just means Win7 is more prone to this or whether it's permaorange there.
I'm weak on terminology, but do you say that this problem can be (relatively) consistently reproduced on Win7? If so, please refer me to a binary-download which I can use to get a log on Win7...
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32-debug/1291227818/ has both the binary and the log from running it on Win7, but it may not help you much, since the reason it's failing so much on Win7 *may* be that running xpcshell on Windows is really really slow on the slaves we use - the currently visible Windows debug results run on the fast Win2K3 builder slaves and take 30-40 minutes for the whole run, the new Win7 ones are running on slower slaves and take >100 minutes (Windows opt, on the same class of slaves, takes around 70 minutes).
Attached patch Improved versionSplinter Review
The logic in previous patch was a little shaky wrt shutting down before finishing all tests, which might have caused the hang from comment #106. This version improves this.
For those (like me) wondering wtf happened, "1200 seconds without output" hangs on Win7 opt on the push itself, and on OS X 10.5 debug and Linux64 debug on the next push, and on the hidden-because-of-this Win7 debug on both pushes.
And that was the one, fixed by d3d71ad68624 :)
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
By which he means "boy, sure would be nice if TraceMonkey ever merged from mozilla-central, instead of sitting on a merge from December 6th for the last three weeks."
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: