Downgrade MOZ_ASSERT(win->IsClosedOrClosing()) to an NS_ASSERTION until it stops happening so often

RESOLVED FIXED in mozilla17

Status

()

Core
XUL
--
critical
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: philor, Assigned: philor)

Tracking

Trunk
mozilla17
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
Created attachment 651242 [details] [diff] [review]
downgrade

Between them, bug 777875 and bug 778424 and bug 781078 are amounting to around 15% of our test failures, though that undercounts their effect, since hitting a MOZ_ASSERT effectively means that we didn't run that test suite.

This is Gecko 17, as in what will become esr17, so we can't just say "oh, well, if it gets fixed for 18 in a way that can't jump trains, we can just live with it for 18 weeks on release branches." This Gecko's going to be around until after Gecko 25, in December 2013. AFAIK, nobody has looked at it so nobody can say whether or not it'll be fixed in a train-jumpable way.

Dropping down to an NS_ASSERTION lets us not crash mochitest runs, while still making it possible for someone looking into the problem to debug. If someone fixes the problem, great, they can revert to MOZ_ASSERT, but if not, we won't wind up having to retrigger and retrigger mochitest-1 and mochitest-oth from now until December 2013 just to get a run where every test gets a chance to be run.

Try run (including https://tbpl.mozilla.org/php/getParsedLog.php?id=14327884&tree=Try hitting the NS_ASSERTION): https://tbpl.mozilla.org/?tree=Try&rev=2f0c4a1feda9
Attachment #651242 - Flags: review?(bobbyholley+bmo)
Attachment #651242 - Flags: review?(bobbyholley+bmo) → review+
(Assignee)

Comment 1

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/9e0799cf1096
Thank you for changing this :-)
FWIW, I have been looking into this - working with QA to try to find STR over in bug 776497, which I think is the version of this bug in the wild.

Regardless though, I totally agree with this course of action. Thanks for fixing that Philor!
https://hg.mozilla.org/mozilla-central/rev/9e0799cf1096
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
(Assignee)

Comment 5

5 years ago
STR may well involve triggering a tooltip - every instance I've seen with the NS_ASSERTION, after the busted stacks from failing to download symbols, winds up with a "JavaScript error: chrome://browser/content/browser.xul, line 1: NS_ERROR_FAILURE: Failure arg 0 [nsIDOMXULDocument.tooltipNode]" which I'm guessing is the returned NS_ERROR_FAILURE after the assertion.
You need to log in before you can comment on or make changes to this bug.