Closed
Bug 1171171
Opened 9 years ago
Closed 9 years ago
Starting nightly with a custom profile causes crash
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
mozilla41
Tracking | Status | |
---|---|---|
firefox41 | --- | fixed |
People
(Reporter: marcosc, Assigned: milan)
References
Details
(Keywords: regression)
Attachments
(3 files)
2.60 KB,
text/plain
|
Details | |
1.39 KB,
patch
|
billm
:
review+
|
Details | Diff | Splinter Review |
1.02 KB,
patch
|
milan
:
review+
|
Details | Diff | Splinter Review |
Steps to reproduce: 0. build latest 1. ./mach run -P "Test" Expected: - browser to start with custom profile Actual: 0:00.20 /Users/marcos/gecko/obj-x86_64-apple-darwin14.3.0/dist/NightlyDebug.app/Contents/MacOS/firefox -P Test -no-remote -foreground [78245] WARNING: '!compMgr', file /Users/marcos/gecko/xpcom/glue/nsComponentManagerUtils.cpp, line 63 Assertion failure: SingletonExists(), at ../dist/include/gfxPrefs.h:208 #01: nsWindowWatcher::CalculateChromeFlags(nsIDOMWindow*, char const*, bool, bool, bool, bool, bool)[/Users/marcos/gecko/obj-x86_64-apple-darwin14.3.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x2ec2292] #02: nsWindowWatcher::OpenWindowInternal(nsIDOMWindow*, char const*, char const*, char const*, bool, bool, bool, nsITabParent*, nsIArray*, nsIDOMWindow**)[/Users/marcos/gecko/obj-x86_64-apple-darwin14.3.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x2ebeb1e] #03: nsWindowWatcher::OpenWindow(nsIDOMWindow*, char const*, char const*, char const*, nsISupports*, nsIDOMWindow**)[/Users/marcos/gecko/obj-x86_64-apple-darwin14.3.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x2ebdcab] #04: ShowProfileManager(nsIToolkitProfileService*, nsINativeAppSupport*)[/Users/marcos/gecko/obj-x86_64-apple-darwin14.3.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x323ba31] #05: XREMain::XRE_mainStartup(bool*)[/Users/marcos/gecko/obj-x86_64-apple-darwin14.3.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x3237ac7] #06: XREMain::XRE_main(int, char**, nsXREAppData const*)[/Users/marcos/gecko/obj-x86_64-apple-darwin14.3.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x323a566] #07: XRE_main[/Users/marcos/gecko/obj-x86_64-apple-darwin14.3.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x323aaaa] #08: main[/Users/marcos/gecko/obj-x86_64-apple-darwin14.3.0/dist/NightlyDebug.app/Contents/MacOS/firefox +0x2145]
Reporter | ||
Updated•9 years ago
|
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86
Reporter | ||
Updated•9 years ago
|
Keywords: regression,
regressionwindow-wanted
Reporter | ||
Updated•9 years ago
|
Keywords: regression
Comment 1•9 years ago
|
||
I bisected it to this push: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=5bd5921f4b3b Would be great if we could fix this soonish, it breaks my debugging workflow.
Assignee | ||
Comment 2•9 years ago
|
||
Do you have the line numbers for the stack? I can't tell what's asking for graphics preferences from nsWindowWatcher::CalculateChromeFlags, and the regression range from comment 1 points to GetFeatureStatus getting called from a different path than usual. What's special about the custom profile?
Comment 3•9 years ago
|
||
Here's a stacktrace from lldb.
Reporter | ||
Comment 4•9 years ago
|
||
(In reply to Milan Sreckovic [:milan] from comment #2) > What's special about the custom profile? Nothing. Any it crashes on any `-P whatever`.
Assignee | ||
Comment 5•9 years ago
|
||
Nasty. Doesn't happen to me, and I run with a custom profile. There is enough information here, I'll figure it out; in the meantime, if this is blocking your work on local builds, just add gfxPrefs::GetSingleton() call before https://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#4614 (call to gfxInfo->GetFeatureStatus) and it should work.
Flags: needinfo?(milan)
Assignee | ||
Comment 6•9 years ago
|
||
Without the "fix" from comment 5, if you put a breakpoint in nsRefreshDriver::ChooseTimer, does it trigger before the crash?
Assignee | ||
Comment 7•9 years ago
|
||
(In reply to Milan Sreckovic [:milan] from comment #6) > Without the "fix" from comment 5, if you put a breakpoint in > nsRefreshDriver::ChooseTimer, does it trigger before the crash? What about gfxPlatform::Init?
Flags: needinfo?(mcaceres)
Assignee | ||
Comment 8•9 years ago
|
||
Also, reproducible with e10s off? Not that I'm recommending e10s off, just triage.
Assignee | ||
Comment 9•9 years ago
|
||
(In reply to Milan Sreckovic [:milan] from comment #8) > Also, reproducible with e10s off? Not that I'm recommending e10s off, just > triage. Ignore this question, makes no sense :)
Assignee | ||
Comment 10•9 years ago
|
||
What I meant to ask about e10s - when running e10s, is this crash in the firefox or pluginContainer process?
Assignee: nobody → milan
Reporter | ||
Comment 11•9 years ago
|
||
Sorry, I'm just a javascript monkey, I don't know how to check those things :( I'm deferring to jandem.
Flags: needinfo?(mcaceres) → needinfo?(jdemooij)
Reporter | ||
Comment 12•9 years ago
|
||
Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3fd7d6a116ed
Reporter | ||
Comment 13•9 years ago
|
||
Sorry, wrong bug for the above try!
Comment 14•9 years ago
|
||
(In reply to Milan Sreckovic [:milan] from comment #6) > Without the "fix" from comment 5, if you put a breakpoint in > nsRefreshDriver::ChooseTimer, does it trigger before the crash? (In reply to Milan Sreckovic [:milan] from comment #7) > What about gfxPlatform::Init? Neither of those hit before the crash.
Flags: needinfo?(jdemooij)
Assignee | ||
Comment 15•9 years ago
|
||
OK, I can see this bug locally if I run just with -P, rather than with -P profile.
Assignee | ||
Comment 16•9 years ago
|
||
Bill, randomly picking you for the review as you've looked at a few recent changes in this file; if you aren't the right reviewer for this, let me know (together with a suggestion for somebody else if you have one.)
Attachment #8615476 -
Flags: review?(wmccloskey)
Comment on attachment 8615476 [details] [diff] [review] Initialize graphics prefs earlier. r=billm Review of attachment 8615476 [details] [diff] [review]: ----------------------------------------------------------------- If this is causing people pain I guess we should take the fix. Let's figure out a better solution though.
Attachment #8615476 -
Flags: review?(wmccloskey) → review+
Reporter | ||
Comment 18•9 years ago
|
||
Much pain here :( I basically can't debug any of my new code :( ... I'm currently using Developer Edition and polyfilling my own code using developer scratchpad - it's, um, kinda fun :)
There was a bug exactly like this a few months ago, that was caused by a race condition accessing a widget member. I can't find the bug number right now though, but the symptoms looked the same -- it could be a similar issue with a different data member.
Assignee | ||
Comment 20•9 years ago
|
||
In this case, not a race condition, just a different code path that (consistently and repeatedly) gets to GfxInfo before gfxPlatform is initialized. That's a separate issue, it may be wrong-ish that we have this different order of initialization. I've started a separate conversation on how to initialize graphics prefs in one place, we're just looking for that one place. It can't be fully lazy creation, because it must be done on the main thread (preference requirement), and some code paths cause the first graphics preference queried off main thread. Flying without a try on this simple patch. Sheriffs, let me know if you'd like one anyway.
Keywords: checkin-needed
Reporter | ||
Comment 21•9 years ago
|
||
Try, just in case: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ca86ad3447c3
Comment 22•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/a318923da99b
Keywords: checkin-needed
Comment 23•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/a318923da99b
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Comment 24•9 years ago
|
||
This gave me the following build error, locally:
> toolkit/xre/nsAppRunner.cpp:2158:5: error: use of undeclared identifier 'gfxPrefs'
...because the #include for gfxPrefs.h here is in a "#ifdef XP_WIN" section.
(Not sure why it didn't bust TreeHerder - we might be getting the #include out of luck there due to a different mozconfig setup than what I have locally, or due to differences in unified-build groupings.)
Followup patch (just moving the #include) coming up.
Comment 25•9 years ago
|
||
Attachment #8617450 -
Flags: review?(milan)
Updated•9 years ago
|
Attachment #8617450 -
Attachment description: followup → followup to fix local bustage on linux
Assignee | ||
Comment 26•9 years ago
|
||
Comment on attachment 8617450 [details] [diff] [review] followup to fix local bustage on linux Yikes.
Attachment #8617450 -
Attachment is patch: true
Attachment #8617450 -
Flags: review?(milan) → review+
Comment 27•9 years ago
|
||
Landed followup: https://hg.mozilla.org/integration/mozilla-inbound/rev/5c0eae0ada8d
You need to log in
before you can comment on or make changes to this bug.
Description
•