Closed Bug 628603 Opened 13 years ago Closed 13 years ago

Crash in nsDocAccessible::CacheChildrenInSubtree [@ nsAccessNode::IsContent() ]

Categories

(Core :: Disability Access APIs, defect)

x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla5
Tracking Status
blocking2.0 --- .x+

People

(Reporter: scoobidiver, Assigned: surkov)

References

Details

(Keywords: crash, regression, Whiteboard: [safe nullcheck])

Crash Data

Attachments

(1 file, 1 obsolete file)

It is a new crash signature that first appeared in 4.0b10pre/20110116.
It is #47 top crasher in 4.0b10pre over the last 3 days.

Signature	nsAccessNode::IsContent()
UUID	4d4311c1-1703-4d53-9e29-108222110124
Time 	2011-01-24 17:49:12.694291
Uptime	1282
Last Crash	1288 seconds (21.5 minutes) before submission
Install Age	8450 seconds (2.3 hours) since version was first installed.
Product	Firefox
Version	4.0b10pre
Build ID	20110124030332
Branch	2.0
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 6 model 15 stepping 6
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x0
App Notes 	AdapterVendorID: 1002, AdapterDeviceID: 7145, AdapterDriverVersion: 8.383.1.1000

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsAccessNode::IsContent 	obj-firefox/dist/include/nsAccessNode.h:167
1 	xul.dll 	nsDocAccessible::CacheChildrenInSubtree 	accessible/src/base/nsDocAccessible.cpp:2037
2 	xul.dll 	nsDocAccessible::CacheChildrenInSubtree 	accessible/src/base/nsDocAccessible.cpp:2038
3 	xul.dll 	nsDocAccessible::CacheChildrenInSubtree 	accessible/src/base/nsDocAccessible.cpp:2038
4 	xul.dll 	nsDocAccessible::CacheChildrenInSubtree 	accessible/src/base/nsDocAccessible.cpp:2038
5 	xul.dll 	NotificationController::WillRefresh 	accessible/src/base/NotificationController.cpp:189
6 	xul.dll 	nsRefreshDriver::Notify 	layout/base/nsRefreshDriver.cpp:254
7 	xul.dll 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:428
8 	xul.dll 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:517
9 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:633
10 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
11 	xul.dll 	xul.dll@0xb26953 	
12 	xul.dll 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:219
13 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:202
14 	mozcrt19.dll 	mozcrt19.dll@0x1804a 	
15 	xul.dll 	xul.dll@0x35a4bd 	
16 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:176
17 	nspr4.dll 	PR_GetThreadPrivate 	nsprpub/pr/src/threads/prtpd.c:232
18 	xul.dll 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:195
19 	xul.dll 	nsAppShell::Run 	widget/src/windows/nsAppShell.cpp:258
20 		@0x126ffff 	
21 	d3d10_1.dll 	d3d10_1.dll@0x2656a 	
22 		@0x75c3ffff 	
23 	atiumdag.dll 	atiumdag.dll@0x254552 	
24 	atiumdag.dll 	atiumdag.dll@0x253364 	
25 		@0x60b4ffff 	
26 	xul.dll 	SplitCubicBezier 	content/svg/content/src/SVGPathSegUtils.cpp:162
27 	atiumdag.dll 	atiumdag.dll@0x257471 	
28 	uxtheme.dll 	uxtheme.dll@0x3736d 	
29 	atiumdag.dll 	atiumdag.dll@0x253453 

More reports at:
http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A4.0b10pre&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=nsAccessNode%3A%3AIsContent%28%29
> first appeared in 4.0b10pre/20110116.
For this stack trace, it first appeared in 4.0b10pre/20110121153543.
The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=efbf1fa4c70e&tochange=16bd82195df8
looking at code I don't spot anything suspect, just one idea we could create an accessible incorrect tree before we created initial tree. If that's true then rest patches of bug 606924 should help.
Assignee: nobody → bolterbugz
the last crash happened 2011-01-25. I think this bug was fixed by bug 606924.
Status: NEW → RESOLVED
Closed: 13 years ago
Depends on: 606924
Resolution: --- → FIXED
Not quite gone. I see some stacks in 4.0, for example:
https://crash-stats.mozilla.com/report/index/68db4c2a-5473-4a8e-8736-20b0b2110310
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: bolterbugz → nobody
it should be related to bug 637097, accessible tree mutates while we create the tree, null check and assertion is suitable fix for that.
Attached patch patch (obsolete) — Splinter Review
Assignee: nobody → surkov.alexander
Status: REOPENED → ASSIGNED
Attachment #518652 - Flags: review?(bolterbugz)
Comment on attachment 518652 [details] [diff] [review]
patch

r=me. Agree with comment 5.
Attachment #518652 - Flags: review?(bolterbugz) → review+
4.x wanted, trivial fix - null check, zero risk.
blocking2.0: --- → ?
Yep.
blocking2.0: ? → .x+
Whiteboard: [safe nullcheck]
Attached patch patch to landSplinter Review
Attachment #518652 - Attachment is obsolete: true
Whiteboard: [safe nullcheck] → [safe nullcheck][fx4-rc-ridealong][has reviewed patch]
landed - http://hg.mozilla.org/mozilla-central/rev/99edfdab05d3
Status: ASSIGNED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Whiteboard: [safe nullcheck][fx4-rc-ridealong][has reviewed patch] → [safe nullcheck]
Target Milestone: --- → mozilla5
Crash Signature: [@ nsAccessNode::IsContent() ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: