630202 - Crash [@ nsDocAccessible::UpdateTreeInternal(nsAccessible*, nsIContent*, nsIContent*, int) ][@ nsDocAccessible::UpdateTreeInternal(nsIContent*, nsIContent*, int) ]

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Scoobidiver (away)]

It is a new crash signature. Crashes first appeared in 4.0b10pre/20110121 and have been discontinuous according to builds.
It is #103 top crasher in 4.0b11pre over the last week.

Comments say:
"I had just changed the settings on a few of my monitors, and I was moving the window and was trying to resize it."
"refresed grooveshark then opened a new browser tab at same time and then highlighted and started typing url...crash"

Signature	nsDocAccessible::UpdateTreeInternal(nsAccessible*, nsIContent*, nsIContent*, int)
UUID	f596a7fa-1888-4ff9-9ca3-f96e22110131
Time 	2011-01-31 06:38:00.621689
Uptime	358
Last Crash	362 seconds (6.0 minutes) before submission
Install Age	6893 seconds (1.9 hours) since version was first installed.
Product	Firefox
Version	4.0b11pre
Build ID	20110130030342
Branch	2.0
OS	Windows NT
OS Version	6.0.6002 Service Pack 2
CPU	x86
CPU Info	GenuineIntel family 6 model 23 stepping 10
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x0
App Notes 	AdapterVendorID: 8086, AdapterDeviceID: 29c2, AdapterDriverVersion: 7.14.10.1504

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsDocAccessible::UpdateTreeInternal 	accessible/src/base/nsDocAccessible.cpp:2032
1 	xul.dll 	nsDocAccessible::UpdateTree 	accessible/src/base/nsDocAccessible.cpp:1902
2 	xul.dll 	nsDocAccessible::ContentRemoved 	accessible/src/base/nsDocAccessible.cpp:1427
3 	xul.dll 	nsAccessibilityService::ContentRemoved 	accessible/src/base/nsAccessibilityService.cpp:528
4 	xul.dll 	nsCSSFrameConstructor::ContentRemoved 	
5 	xul.dll 	nsEventStateManager::ContentRemoved 	content/events/src/nsEventStateManager.cpp:4502
6 	xul.dll 	XPC_WN_Helper_NewResolve 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1120
7 	xul.dll 	nsAccessNode::Release 	accessible/src/base/nsAccessNode.cpp:106
8 	xul.dll 	nsDocument::BeginUpdate 	content/base/src/nsDocument.cpp:3968
9 	xul.dll 	mozAutoSubtreeModified::UpdateTarget 	
10 	xul.dll 	nsGenericHTMLElement::SetInnerHTML 	content/html/content/src/nsGenericHTMLElement.cpp:745
11 	mozjs.dll 	JS_DHashTableRawRemove 	js/src/jsdhash.cpp:712
12 	xul.dll 	xpc_qsDOMString::xpc_qsDOMString 	js/src/xpconnect/src/xpcquickstubs.cpp:700
13 	xul.dll 	nsIDOMNSHTMLElement_SetInnerHTML 	obj-firefox/js/src/xpconnect/src/dom_quickstubs.cpp:20722
14 	xul.dll 	nsIDOMNSHTMLElement_SetInnerHTML 	obj-firefox/js/src/xpconnect/src/dom_quickstubs.cpp:20726
15 	mozjs.dll 	js::Shape::set 	js/src/jsscopeinlines.h:275
16 	mozjs.dll 	js_SetPropertyHelper 	js/src/jsobj.cpp:5550
17 	xul.dll 	xul.dll@0x11616f 	
18 	xul.dll 	xul.dll@0x16c6af 	
19 	mozjs.dll 	GetAtomFromBytecode 	js/src/jspropertycache.cpp:316
20 	mozjs.dll 	js::PropertyCache::fullTest 	js/src/jspropertycache.cpp:409
21 	mozjs.dll 	js::mjit::stubs::SetName<0> 	js/src/methodjit/StubCalls.cpp:261

More reports at:
https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=&range_value=4&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsDocAccessible%3A%3AUpdateTreeInternal%28nsAccessible*%2C%20nsIContent*%2C%20nsIContent*%2C%20int%29

Comment 1

[alexander :surkov (:asurkov)]

Attachment: patch

No idea why this may happen, I think we should tighten accessibility rules of tree invalidation.

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 508744 [details] [diff] [review]
patch

OK.

The Linux stack from the 21st fails on:
if (aIsInsert && !node->GetPrimaryFrame())

How about also adding a node check near the top of the loop since we iterate on node = node->GetNextSibling()? (Should probably assert too)

Would be great to have STR but I'm not hopeful.

Comment 3

[David Bolter [:davidb] (NeedInfo me for attention)]

Could we be updated the a11y tree at a bad time?

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

Actually in the Linux case it looks like the node was going bad. That might be fixed now.

Comment 5

[alexander :surkov (:asurkov)]

(In reply to comment #2)
> Comment on attachment 508744 [details] [diff] [review]
> patch
> 
> OK.
> 
> The Linux stack from the 21st fails on:
> if (aIsInsert && !node->GetPrimaryFrame())
> 
> How about also adding a node check near the top of the loop since we iterate on
> node = node->GetNextSibling()? (Should probably assert too)

it should be done before content insertion processing is scheduled.

(In reply to comment #3)
> Could we be updated the a11y tree at a bad time?

refresh observer call must be a good time or what do you keep in mind?

Comment 6

[alexander :surkov (:asurkov)]

(In reply to comment #4)
> Actually in the Linux case it looks like the node was going bad. That might be
> fixed now.

ok.

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

> (In reply to comment #3)
> > Could we be updated the a11y tree at a bad time?
> 
> refresh observer call must be a good time or what do you keep in mind?

Yes of course that's the promise I'm just not 100% sure there aren't edge cases where the gecko is not ready for us.

Comment 8

[alexander :surkov (:asurkov)]

landed on 2.0 - http://hg.mozilla.org/mozilla-central/rev/19bdf0a54cce

Comment 9

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Shouldn't that assertion be removed, as it clearly isn't always true?

Comment 10

[alexander :surkov (:asurkov)]

(In reply to comment #9)
> Shouldn't that assertion be removed, as it clearly isn't always true?

Assertion points that something quite bad happened (i.e. we got a broken tree). I want to keep it if somebody finds testcase eventually or I can see in real life and debug it.