Closed Bug 400392 Opened 15 years ago Closed 14 years ago

necko unit test test_reopen.js fails randomly on qm-centos5-01

Categories

(Core :: Networking, defect)

x86
Linux
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: ted, Assigned: sylvain.pasche)

References

()

Details

Attachments

(1 file)

The test_reopen.js unit test fails randomly on qm-centos5-01:

../../_tests/xpcshell-simple/test_necko/unit/test_reopen.js: FAIL
../../_tests/xpcshell-simple/test_necko/unit/test_reopen.js.log:
>>>>>>>
*** test pending
*** test pending
*** test finished
*** running event loop
*** exiting
*** CHECK FAILED: 2152398863 == 2152398921
JS frame :: /builds/slave/trunk_centos5/mozilla/tools/test-harness/xpcshell-simple/head.js :: do_throw :: line 99
JS frame :: /builds/slave/trunk_centos5/mozilla/tools/test-harness/xpcshell-simple/head.js :: do_check_eq :: line 114
JS frame :: ../../_tests/xpcshell-simple/test_necko/unit/test_reopen.js :: check_throws :: line 43
JS frame :: ../../_tests/xpcshell-simple/test_necko/unit/test_reopen.js :: check_async_open_throws :: line 58
JS frame :: ../../_tests/xpcshell-simple/test_necko/unit/test_reopen.js :: test_channel :: line 95
JS frame :: ../../_tests/xpcshell-simple/test_necko/unit/test_reopen.js :: test_http_channel :: line 111
JS frame :: ../../_tests/xpcshell-simple/test_necko/unit/test_reopen.js :: run_next_test :: line 87
JS frame :: ../../_tests/xpcshell-simple/test_necko/unit/test_reopen.js :: after_channel_closed :: line 83
JS frame :: /builds/slave/trunk_centos5/mozilla/tools/test-harness/xpcshell-simple/head.js :: anonymous :: line 62
JS frame :: /builds/slave/trunk_centos5/mozilla/tools/test-harness/xpcshell-simple/head.js :: anonymous :: line 62
*** FAIL ***

<<<<<<<

This just happened, and it's happened before, seemingly randomly.
FWIW, the test here is failing:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/test/unit/test_reopen.js&rev=1.2#95

It's getting NS_ERROR_IN_PROGRESS when it expects NS_ERROR_ALREADY_OPENED.
Depends on: 372486
Looks like a timing issue:

In the test, the channel is opened, and then reopened async a bit later. The test assumes that mPending will be set to false in the meantime. On my system, this is done by the nsHttpChannel::OnStopRequest which happens before the asyncOpen is reached. I guess that sometimes the OnStopRequest comes after the second asyncOpen call, so that both mPending and mWasOpened are sill true when that second asyncOpen is reached, which makes it return NS_ERROR_IN_PROGRESS.

I propose to check against both NS_ERROR_ALREADY_OPENED or NS_ERROR_IN_PROGRESS there.
Attached patch patchSplinter Review
Attachment #285516 - Flags: review?(cbiesinger)
It may be preferable to reset mPending in AsyncOpen in case of errors rather than wait for OnStopRequest to do so; that's probably what I'd do if I were fixing this.
Bumping severity because this confuses people and makes the unit tests less reliable.
Assignee: nobody → sylvain.pasche
Severity: normal → major
Attachment #285516 - Flags: review?(cbiesinger) → review+
Attachment #285516 - Flags: approval1.9?
Comment on attachment 285516 [details] [diff] [review]
patch

Tests don't need approval.
Attachment #285516 - Flags: approval1.9?
Keywords: checkin-needed
Landed tonight before all the big landings tomorrow that might be impacted by this annoying problem.

Checking in netwerk/test/unit/test_reopen.js;
/cvsroot/mozilla/netwerk/test/unit/test_reopen.js,v  <--  test_reopen.js
new revision: 1.3; previous revision: 1.2
done

Thanks for the patch!
Status: NEW → RESOLVED
Closed: 14 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.