Last Comment Bug 782167 - Downgrade MOZ_ASSERT(win->IsClosedOrClosing()) to an NS_ASSERTION until it stops happening so often
: Downgrade MOZ_ASSERT(win->IsClosedOrClosing()) to an NS_ASSERTION until it st...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: All All
: -- critical (vote)
: mozilla17
Assigned To: Phil Ringnalda (:philor)
:
Mentors:
Depends on:
Blocks: 777875 778424 781078
  Show dependency treegraph
 
Reported: 2012-08-12 17:18 PDT by Phil Ringnalda (:philor)
Modified: 2012-08-13 11:18 PDT (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
downgrade (1.41 KB, patch)
2012-08-12 17:18 PDT, Phil Ringnalda (:philor)
khuey: review+
Details | Diff | Review

Description Phil Ringnalda (:philor) 2012-08-12 17:18:45 PDT
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
Comment 2 Ed Morley [:emorley] 2012-08-13 01:11:29 PDT
Thank you for changing this :-)
Comment 3 Bobby Holley (busy) 2012-08-13 01:44:01 PDT
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!
Comment 4 Ed Morley [:emorley] 2012-08-13 11:10:56 PDT
https://hg.mozilla.org/mozilla-central/rev/9e0799cf1096
Comment 5 Phil Ringnalda (:philor) 2012-08-13 11:18:49 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.