Last Comment Bug 758713 - crash in nsIDocument::GetRootElement
: crash in nsIDocument::GetRootElement
Status: RESOLVED FIXED
[qa-]
: crash, regression, reproducible, topcrash
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: All Mac OS X
: -- critical (vote)
: mozilla15
Assigned To: Hubert Figuiere [:hub]
:
Mentors:
http://jamessocol.com/irclogs/sumodev...
: 758770 758851 758947 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-25 11:33 PDT by Chris Peterson [:cpeterson]
Modified: 2015-10-16 11:50 PDT (History)
19 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
+
fixed


Attachments

Description Chris Peterson [:cpeterson] 2012-05-25 11:33:53 PDT
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.
Comment 1 Chris Peterson [:cpeterson] 2012-05-25 11:40:29 PDT
This crash is a regression because it is 100% reproducible in Nightly 2012-05-25, but NOT in Nightly 2012-05-24.
Comment 2 David Bolter [:davidb] 2012-05-25 11:47:47 PDT
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"!
Comment 3 Chris Peterson [:cpeterson] 2012-05-25 11:52:00 PDT
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."
Comment 4 Hubert Figuiere [:hub] 2012-05-25 12:53:24 PDT
I'll have a look at it.
Comment 5 Trevor Saunders (:tbsaunde) 2012-05-25 13:25:22 PDT
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.
Comment 6 Jeff Balogh (:jbalogh) 2012-05-25 15:10:57 PDT
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?
Comment 7 Trevor Saunders (:tbsaunde) 2012-05-25 21:13:17 PDT
*** Bug 758770 has been marked as a duplicate of this bug. ***
Comment 8 Scoobidiver (away) 2012-05-26 11:34:07 PDT
It's #1 top crasher in today's build.
Comment 9 Rob Campbell [:rc] (:robcee) 2012-05-26 13:06:21 PDT
I just got hit by this 3 times in a row. TBPL triggers this when trying to retrigger a build.
Comment 10 Trevor Saunders (:tbsaunde) 2012-05-26 18:48:44 PDT
(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?
Comment 11 Trevor Saunders (:tbsaunde) 2012-05-26 19:19:42 PDT
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.
Comment 12 Phil Ringnalda (:philor) 2012-05-26 21:39:20 PDT
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.
Comment 13 Trevor Saunders (:tbsaunde) 2012-05-26 21:52:07 PDT
(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.
Comment 14 Hubert Figuiere [:hub] 2012-05-26 21:54:10 PDT
The crash in bug 758304 *should* be fixed still, so let's use this one for the rest of the work.
Comment 15 Jim Jeffery not reading bug-mail 1/2/11 2012-05-27 03:50:46 PDT
*** Bug 758947 has been marked as a duplicate of this bug. ***
Comment 16 David Bolter [:davidb] 2012-05-28 07:09:04 PDT
Removing P1 status as the bleeding should be stopped via comment 11.
Comment 17 Hubert Figuiere [:hub] 2012-05-28 10:17:27 PDT
*** Bug 758851 has been marked as a duplicate of this bug. ***
Comment 18 Hubert Figuiere [:hub] 2012-05-28 17:54:25 PDT
I locally backed out Trevor change, and I haven't been able to reproduce the crash.

(not saying it does not exist)
Comment 19 Scoobidiver (away) 2012-05-29 01:49:20 PDT
(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.
Comment 20 Hubert Figuiere [:hub] 2012-05-29 11:10:46 PDT
Filed bug 759412 as for the proper implementation.

Marking the crash fixed.
Comment 21 Jeff Balogh (:jbalogh) 2012-05-29 22:37:07 PDT
Why is Nightly getting so crashy with a11y patches?
Comment 22 alexander :surkov 2012-05-29 23:00:08 PDT
(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.
Comment 23 Hubert Figuiere [:hub] 2012-05-30 14:15:16 PDT
(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.
Comment 24 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-06-22 15:07:43 PDT
The testcase in the URL field of this bug is 404. Can QA get a new testcase to verify this fix?
Comment 25 Jesse Ruderman 2012-06-22 15:25:48 PDT
James, do you have a copy of the testcase?

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