crash in nsIDocument::GetRootElement

RESOLVED FIXED in Firefox 15

Status

()

Core
Disability Access APIs
--
critical
RESOLVED FIXED
5 years ago
2 years ago

People

(Reporter: cpeterson, Assigned: hub)

Tracking

(4 keywords)

Trunk
mozilla15
All
Mac OS X
crash, regression, reproducible, topcrash
Points:
---

Firefox Tracking Flags

(firefox14 unaffected, firefox15+ fixed)

Details

(Whiteboard: [qa-], crash signature, URL)

(Reporter)

Description

5 years ago
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
(Reporter)

Comment 1

5 years ago
This crash is a regression because it is 100% reproducible in Nightly 2012-05-25, but NOT in Nightly 2012-05-24.
(Reporter)

Updated

5 years ago
status-firefox14: --- → unaffected
status-firefox15: --- → affected
Version: unspecified → Trunk
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"!
status-firefox14: unaffected → ---
status-firefox15: affected → ---
Version: Trunk → unspecified
(Reporter)

Comment 3

5 years ago
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."
status-firefox14: --- → unaffected
status-firefox15: --- → affected
Version: unspecified → Trunk
(Assignee)

Comment 4

5 years ago
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?
Duplicate of this bug: 758770

Updated

5 years ago
Keywords: regression
Version: Trunk → 15 Branch

Comment 8

5 years ago
It's #1 top crasher in today's build.
tracking-firefox15: --- → ?
Keywords: topcrash
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.
(Assignee)

Comment 14

5 years ago
The crash in bug 758304 *should* be fixed still, so let's use this one for the rest of the work.
Duplicate of this bug: 758947
Priority: -- → P1
Removing P1 status as the bleeding should be stopped via comment 11.
Priority: P1 → --
(Assignee)

Updated

5 years ago
Duplicate of this bug: 758851
(Assignee)

Comment 18

5 years ago
I locally backed out Trevor change, and I haven't been able to reproduce the crash.

(not saying it does not exist)
tracking-firefox15: ? → ---
Version: 15 Branch → Trunk

Comment 19

5 years ago
(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.
(Assignee)

Comment 20

5 years ago
Filed bug 759412 as for the proper implementation.

Marking the crash fixed.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla15
Why is Nightly getting so crashy with a11y patches?

Comment 22

5 years ago
(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.

Updated

5 years ago
tracking-firefox15: --- → +
(Assignee)

Comment 23

5 years ago
(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.

Updated

5 years ago
status-firefox15: affected → fixed
The testcase in the URL field of this bug is 404. Can QA get a new testcase to verify this fix?
Keywords: testcase-wanted
Whiteboard: [qa?]

Comment 25

5 years ago
James, do you have a copy of the testcase?

Updated

5 years ago
Whiteboard: [qa?] → [qa-]
Keywords: testcase-wanted
You need to log in before you can comment on or make changes to this bug.