Closed Bug 600785 Opened 14 years ago Closed 14 years ago

TM: intermittent failure in browser_bug471404.js | Test timed out after JavaScript Error: "dirSvc.unregisterProvider is not a function"

Categories

(Toolkit :: Crash Reporting, defect)

Product:
Toolkit
Component:
Crash Reporting
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla2.0b7
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: orangereporter, Assigned: dbaron)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

patch
1.08 KB, patch
ted
: review+
Details | Diff | Splinter Review 
Not immediately obvious to me whether this is the test doing something it shouldn't, or jseng doing something it shouldn't, but sometime today browser_bug471404.js started intermittently failing like

http://tinderbox.mozilla.org/showlog.cgi?log=TraceMonkey/1285806951.1285808484.5252.gz
Rev3 WINNT 6.1 tracemonkey opt test mochitest-other on 2010/09/29 17:35:51
s: talos-r3-w7-033

TEST-INFO | chrome://mochikit/content/browser/toolkit/crashreporter/test/browser/browser_bug471404.js | Console message: [JavaScript Error: "dirSvc.unregisterProvider is not a function" {file: "chrome://mochikit/content/browser/toolkit/crashreporter/test/browser//aboutcrashes_utils.js" line: 60}]
TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/toolkit/crashreporter/test/browser/browser_bug471404.js | Test timed out

where http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/test/browser/aboutcrashes_utils.js#58 is just

let dirSvc = Cc["@mozilla.org/file/directory_service;1"]
             .getService(Ci.nsIProperties);
dirSvc.unregisterProvider(_provider);
http://tinderbox.mozilla.org/showlog.cgi?log=TraceMonkey/1285818235.1285819726.23826.gz
Rev3 WINNT 6.1 tracemonkey opt test mochitest-other on 2010/09/29 20:43:55
s: talos-r3-w7-036

http://tinderbox.mozilla.org/showlog.cgi?log=TraceMonkey/1285823075.1285823932.10560.gz
Rev3 MacOSX Leopard 10.5.8 tracemonkey opt test mochitest-other on 2010/09/29 22:04:35
s: talos-r3-leopard-044
blocking2.0: --- → ?
http://tinderbox.mozilla.org/showlog.cgi?log=TraceMonkey/1285804558.1285806517.28133.gz
Rev3 WINNT 6.1 tracemonkey opt test mochitest-other on 2010/09/29 16:55:58
s: talos-r3-w7-045
http://tinderbox.mozilla.org/showlog.cgi?log=TraceMonkey/1285806335.1285808342.4422.gz
Rev3 MacOSX Snow Leopard 10.6.2 tracemonkey debug test mochitest-other on 2010/09/29 17:25:35
s: talos-r3-snow-012
Blocks: 600883
No longer blocks: 600883
Assignee: general → dbaron
Component: JavaScript Engine → Breakpad Integration
Product: Core → Toolkit
QA Contact: general → breakpad.integration
Attached patch patch — — Splinter Review 
Pretty sure this is a bug in the test, which is racing with GC of the wrapper.
Attachment #481861 - Flags: review?(ted.mielczarek)
Comment on attachment 481861 [details] [diff] [review]
patch

Kind of awful that we have to think about wrappers like this. :-/ Is there no sane way to make sure that the wrapper hangs around? I can see us making this mistake fairly often, since it violates my expectations.
Attachment #481861 - Flags: review?(ted.mielczarek) → review+
You can make the wrapper hang around by storing it in a global variable or property of something else; that has other dangers, though.
Perhaps the better answer is that if the object has classinfo, you don't have to mess with QI at all.
http://hg.mozilla.org/mozilla-central/rev/26291a8c4caf
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
blocking2.0: ? → -
Target Milestone: mozilla2.0b8 → mozilla2.0b7
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: