Closed Bug 738334 Opened 12 years ago Closed 12 years ago

Intermittent dom/workers/test/test_xhr_timeout.html | application timed out after 330 seconds with no output after Assertion failure: !IsNull() (Cannot compute with a null value) in TimeStamp.h and ASSERTION: nsScriptCacheCleaner not thread-safe

Categories

(Core :: DOM: Workers, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla14
Tracking Status
firefox11 --- wontfix
firefox12 --- affected
firefox13 --- affected
firefox-esr10 13+ fixed

People

(Reporter: philor, Assigned: khuey)

References

Details

(Keywords: assertion, intermittent-failure, Whiteboard: [qa-])

Attachments

(1 file)

https://tbpl.mozilla.org/php/getParsedLog.php?id=10263952&tree=Mozilla-Inbound
Rev3 WINNT 5.1 mozilla-inbound debug test mochitests-3/5 on 2012-03-21 19:51:37 PDT for push 2943b3d6edfe

11060 INFO TEST-START | /tests/dom/workers/test/test_xhr_timeout.html
++DOMWINDOW == 3452 (05047380) [serial = 7879] [outer = 057957A0]
--DOMWINDOW == 3451 (24FF9F98) [serial = 7870] [outer = 00000000] [url = http://mochi.test:8888/tests/dom/workers/test/test_terminate.html]
--DOMWINDOW == 3450 (14126F68) [serial = 7871] [outer = 00000000] [url = http://mochi.test:8888/tests/dom/workers/test/test_threadErrors.html]
11061 INFO TEST-PASS | /tests/dom/workers/test/test_xhr_timeout.html | no time out scheduled, load fires normally, timeout scheduled at 0 - "load" should equal "load"
Assertion failure: !IsNull() (Cannot compute with a null value), at e:\builds\moz2_slave\m-in-w32-dbg\build\obj-firefox\dist\include\mozilla/TimeStamp.h:223
nsStringStats
 => mAllocCount:        2851842
 => mReallocCount:       253490
 => mFreeCount:         2693190  --  LEAKED 158652 !!!
 => mShareCount:        6660501
 => mAdoptCount:         352655
 => mAdoptFreeCount:     352646  --  LEAKED 9 !!!
###!!! ASSERTION: nsScriptCacheCleaner not thread-safe: '_mOwningThread.GetThread() == PR_GetCurrentThread()', file e:/builds/moz2_slave/m-in-w32-dbg/build/content/base/src/nsFrameMessageManager.cpp, line 906
TEST-UNEXPECTED-FAIL | /tests/dom/workers/test/test_xhr_timeout.html | application timed out after 330 seconds with no output
args: ['C:\\talos-slave\\test\\build\\bin\\screenshot.exe', 'c:\\docume~1\\cltbld\\locals~1\\temp\\mozilla-test-fail_suvj7f']
(screenshot)
command timed out: 1200 seconds without output, attempting to kill
Assignee: nobody → khuey
Component: DOM → DOM: Workers
QA Contact: general → workers
(In reply to Phil Ringnalda (:philor) from comment #1)
> https://tbpl.mozilla.org/php/getParsedLog.php?id=10270841&tree=Mozilla-
> Inbound

Rev3 WINNT 5.1 mozilla-inbound debug test mochitests-3/5 on 2012-03-22 00:44:17 PDT for push dd6e82e5edac

*****

SeaMonkey has it a little differently, like:

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1332050249.1332054389.23291.gz&fulltext=1
WINNT 5.2 comm-central-trunk debug test mochitests-3/5 on 2012/03/17 22:57:29
s: cb-seamonkey-win32-03

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1332447525.1332451645.23137.gz&fulltext=1
WINNT 5.2 comm-central-trunk debug test mochitests-3/5 on 2012/03/22 13:18:45
s: cb-seamonkey-win32-01
{
9665 INFO TEST-START | /tests/dom/workers/test/test_xhr_timeout.html

###!!! ASSERTION: Must have a proxy here!: 'mProxy', file e:/builds/slave/comm-cen-trunk-w32-dbg/build/mozilla/dom/workers/XMLHttpRequestPrivate.cpp, line 2166
...

9666 INFO TEST-PASS | /tests/dom/workers/test/test_xhr_timeout.html | no time out scheduled, load fires normally, timeout scheduled at 0 - "load" should equal "load"

###!!! ASSERTION: You can't dereference a NULL nsRefPtr with operator->().: 'mRawPtr != 0', file e:\builds\slave\comm-cen-trunk-w32-dbg\build\objdir\mozilla\dist\include\nsAutoPtr.h, line 1056
...

###!!! ASSERTION: nsScriptCacheCleaner not thread-safe: '_mOwningThread.GetThread() == PR_GetCurrentThread()', file e:/builds/slave/comm-cen-trunk-w32-dbg/build/mozilla/content/base/src/nsFrameMessageManager.cpp, line 906
TEST-UNEXPECTED-FAIL | /tests/dom/workers/test/test_xhr_timeout.html | application timed out after 330 seconds with no output
}
Blocks: 731266
(In reply to Serge Gautherie (:sgautherie) from comment #2)
> (In reply to Phil Ringnalda (:philor) from comment #1)
> > https://tbpl.mozilla.org/php/getParsedLog.php?id=10270841&tree=Mozilla-
> > Inbound
> 
> Rev3 WINNT 5.1 mozilla-inbound debug test mochitests-3/5 on 2012-03-22
> 00:44:17 PDT for push dd6e82e5edac
> 
> *****
> 
> SeaMonkey has it a little differently, like:
> 
> http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1332050249.1332054389.
> 23291.gz&fulltext=1
> WINNT 5.2 comm-central-trunk debug test mochitests-3/5 on 2012/03/17 22:57:29
> s: cb-seamonkey-win32-03
> 
> http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1332447525.1332451645.
> 23137.gz&fulltext=1
> WINNT 5.2 comm-central-trunk debug test mochitests-3/5 on 2012/03/22 13:18:45
> s: cb-seamonkey-win32-01
> {
> 9665 INFO TEST-START | /tests/dom/workers/test/test_xhr_timeout.html
> 
> ###!!! ASSERTION: Must have a proxy here!: 'mProxy', file
> e:/builds/slave/comm-cen-trunk-w32-dbg/build/mozilla/dom/workers/
> XMLHttpRequestPrivate.cpp, line 2166
> ...
> 
> 9666 INFO TEST-PASS | /tests/dom/workers/test/test_xhr_timeout.html | no
> time out scheduled, load fires normally, timeout scheduled at 0 - "load"
> should equal "load"
> 
> ###!!! ASSERTION: You can't dereference a NULL nsRefPtr with operator->().:
> 'mRawPtr != 0', file
> e:\builds\slave\comm-cen-trunk-w32-
> dbg\build\objdir\mozilla\dist\include\nsAutoPtr.h, line 1056
> ...
> 
> ###!!! ASSERTION: nsScriptCacheCleaner not thread-safe:
> '_mOwningThread.GetThread() == PR_GetCurrentThread()', file
> e:/builds/slave/comm-cen-trunk-w32-dbg/build/mozilla/content/base/src/
> nsFrameMessageManager.cpp, line 906
> TEST-UNEXPECTED-FAIL | /tests/dom/workers/test/test_xhr_timeout.html |
> application timed out after 330 seconds with no output
> }

That's something else.
Attached patch PatchSplinter Review
Attachment #608760 - Flags: review?(bent.mozilla)
Attachment #608760 - Flags: review?(bent.mozilla) → review+
http://hg.mozilla.org/mozilla-central/rev/d41503780635
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment on attachment 608760 [details] [diff] [review]
Patch

This is a pretty rare race condition but the results are quite bad.  We'd like to take this wherever drivers will let us.

[Approval Request Comment]
Regression caused by (bug #): Worker rewrite (several months ago)
User impact if declined: a rare race condition that results in bad things.
Testing completed (on m-c, etc.): on m-c
Risk to taking this patch (and alternatives if risky): risk is low
String changes made by this patch: N/A
Attachment #608760 - Flags: approval-mozilla-esr10?
Attachment #608760 - Flags: approval-mozilla-beta?
Attachment #608760 - Flags: approval-mozilla-aurora?
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #3)
> > SeaMonkey has it a little differently, like:
> 
> That's something else.

Should I file a separate bug? Any idea about whet the cause could be?
Target Milestone: --- → mozilla14
Yes.  Not off the top of my head, but I'll try to find some time to look into it.
(In reply to Serge Gautherie (:sgautherie) from comment #7)
> (In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #3)
> > > SeaMonkey has it a little differently, like:
> > 
> > That's something else.
> 
> Should I file a separate bug? Any idea about whet the cause could be?

I filed bug 739037.
No longer blocks: 731266
Comment on attachment 608760 [details] [diff] [review]
Patch

[Triage Comment]
Since the associated risk is low and this gets rid of some orange, approved for Aurora 13. Since it's rare and requires a change in code, we'll delay the landing and skip Beta 12.

As for the ESR - is this orange common enough to take for sake of dev sanity? If not, it doesn't seem as if it meets the criteria for ESR from the user perspective.
Attachment #608760 - Flags: approval-mozilla-beta?
Attachment #608760 - Flags: approval-mozilla-beta-
Attachment #608760 - Flags: approval-mozilla-aurora?
Attachment #608760 - Flags: approval-mozilla-aurora+
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
[Triage Comment]
Tracking for ESR-next, so we get some bake time on Aurora.
Comment on attachment 608760 [details] [diff] [review]
Patch

[Triage Comment]
Time has come, please land to ESR (Firefox 13)
Attachment #608760 - Flags: approval-mozilla-esr10? → approval-mozilla-esr10+
I don't think this is anything QA needs to explicitly verify, flagging [qa-]. Please correct me if I am wrong.
Whiteboard: [orange] → [orange][qa-]
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Whiteboard: [orange][qa-] → [qa-]
You need to log in before you can comment on or make changes to this bug.