Closed Bug 758713 Opened 9 years ago Closed 8 years ago
crash in ns
IDocument::Get Root Element
This bug was filed from the Socorro interface and is report bp-403e60ee-31c4-4b0d-b342-08c372120525 . ============================================================= STR: 1. Open http://jamessocol.com/irclogs/sumodev-2011-4-27.txt 2. CRASH! This crash is 100% reproducible on my MacBook Pro running Mac OS X 10.7.4, but is NOT reproducible on my older MacBook Pro running Mac OS X 10.6.8.
Component: General → Disability Access APIs
QA Contact: general → accessibility-apis
This crash is a regression because it is 100% reproducible in Nightly 2012-05-25, but NOT in Nightly 2012-05-24.
Uh oh... sounds like OSX IME instantiates a11y... davidb: thanks for finding that crasher davidb: do you know why a11y was instantiated for you? (do you use VoiceOver?) cpeterson: davidb, I'm not sure why. I do have multi-language input enabled on this Mac to test IME for different languages. davidb: interesting davidb: have you noticed FF is a lot slower in the last week or two? (on mac) davidb: (or a little slower) cpeterson: I just disabled multi-language input on my Mac and the crash "went away"!
To enable Mac IME, go to System Preferences > Language & Text > Input Sources and check one or more languages in addition to your default locale's input source. My default locale is "U.S."
I'll have a look at it.
Assignee: nobody → hub
So, it seems like what's going on is a document of some sort is going away, so we shut itand all of its children down, but when we go to shutdown a accessible in that document the mac accessible that's been created for it goes to get its parent to clear its parents children cache, but the parent doesn't have a pltform object yet, so we go to create, nd so end up calling methods on an accessible that should be defunct. The easiest fix is to rework expire() so it doesn't force the creation of platform objects. However its not completely clear to me that the accessible should ever still have a parent.
I saw bp-8c0cec4a-106e-4500-9ad4-c62c42120525 and bp-1485688a-a09d-4ffb-beb0-ebf422120525 on Nightly when quitting the browser today. The latter is a different signature but it's in nsDocAccessible so maybe it's related?
I just got hit by this 3 times in a row. TBPL triggers this when trying to retrigger a build.
(In reply to Trevor Saunders (:tbsaunde) from comment #5) > So, it seems like what's going on is a document of some sort is going away, > so we shut itand all of its children down, but when we go to shutdown a > accessible in that document the mac accessible that's been created for it > goes to get its parent to clear its parents children cache, but the parent > doesn't have a pltform object yet, so we go to create, nd so end up calling > methods on an accessible that should be defunct. The easiest fix is to > rework expire() so it doesn't force the creation of platform objects. > However its not completely clear to me that the accessible should ever still > have a parent. so, it occurs to me that its also important that ClearCache() doesn't shutdown the accessibles in any given order, so it won't be top down, which seems sort of bad. I'm tempted to call the super classes Shutdown() before clearing the cache that way we impose an order in which shutdown is called. Thoughts on what that might break?
on the theory its better to ask forgiveness than permission and since bug 758304 is only an issue in debug builds I backed out the part of it I'm pretty sure caused this bug in https://hg.mozilla.org/integration/mozilla-inbound/rev/133aa3a2ef0a of course that isn't a perminant fix, but it should stop the crashes.
Merged in https://hg.mozilla.org/mozilla-central/rev/133aa3a2ef0a but I don't have any idea what ought to be done with which bugs as a result, so I'll let you decide.
(In reply to Phil Ringnalda (:philor) from comment #12) > Merged in https://hg.mozilla.org/mozilla-central/rev/133aa3a2ef0a but I > don't have any idea what ought to be done with which bugs as a result, so > I'll let you decide. I thought about reopening bug 758304, and then decided it was easier just to plan and fix it here, but if someone feels strongly we can reopen it.
The crash in bug 758304 *should* be fixed still, so let's use this one for the rest of the work.
8 years ago
Priority: -- → P1
Removing P1 status as the bleeding should be stopped via comment 11.
Priority: P1 → --
I locally backed out Trevor change, and I haven't been able to reproduce the crash. (not saying it does not exist)
(In reply to Trevor Saunders (:tbsaunde) from comment #11) > I backed out the part of it I'm pretty sure caused this bug in > https://hg.mozilla.org/integration/mozilla-inbound/rev/133aa3a2ef0a > of course that isn't a perminant fix, but it should stop the crashes. There are no crashes in 15.0a1/20120528.
Filed bug 759412 as for the proper implementation. Marking the crash fixed.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla15
Why is Nightly getting so crashy with a11y patches?
(In reply to Jeff Balogh (:jbalogh) from comment #21) > Why is Nightly getting so crashy with a11y patches? not taking into account this crash since it's special we do code cleaning up and correctness what usually discover underlying problems.
(In reply to Jeff Balogh (:jbalogh) from comment #21) > Why is Nightly getting so crashy with a11y patches? We just enabled a11y for Mac this cycle. It was not enabled before, so it is like a new feature that needs more testing. Granted that it looks like a11y code is called more often than not compared to the other platforms, due to the design of Universal Access API.
The testcase in the URL field of this bug is 404. Can QA get a new testcase to verify this fix?
James, do you have a copy of the testcase?
You need to log in before you can comment on or make changes to this bug.