858896 - crash in mozilla::a11y::GetExistingDocAccessible

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Scoobidiver (away)]

It first showed up in 22.0a1/20130221072044 but is discontinuous across builds.

Signature 	mozilla::a11y::GetExistingDocAccessible(nsIDocument const*) More Reports Search
UUID	48342eb6-2402-4f1a-8dcd-8fbef2130406
Date Processed	2013-04-06 05:06:00
Uptime	310
Last Crash	36.3 minutes before submission
Install Age	4.0 hours since version was first installed.
Install Time	2013-03-09 01:07:31
Product	Firefox
Version	22.0a2
Build ID	20130405004016
Release Channel	aurora
OS	Windows NT
OS Version	5.1.2600 Service Pack 2
Build Architecture	x86
Build Architecture Info	GenuineIntel family 15 model 4 stepping 9
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x32
App Notes 	
AdapterVendorID: 0x8086, AdapterDeviceID: 0x2572, AdapterSubsysID: 71011462, AdapterDriverVersion: 6.14.10.4384
D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers- 
Processor Notes 	sp-processor04.phx1.mozilla.com_21124:2008
EMCheckCompatibility	True
Adapter Vendor ID	0x8086
Adapter Device ID	0x2572
Total Virtual Memory	2147352576
Available Virtual Memory	1853059072
System Memory Use Percentage	69
Available Page File	815149056
Available Physical Memory	161501184
Accessibility	Active

Frame 	Module 	Signature 	Source
0 	xul.dll 	mozilla::a11y::GetExistingDocAccessible 	accessible/src/base/DocManager.h:160
1 	xul.dll 	mozilla::a11y::sdnAccessible::get_attributesForNames 	accessible/src/windows/sdn/sdnAccessible.cpp:172
2 	FSDomNodeFirefox.DLL 	FSDomNodeFirefox.DLL@0xb07c 	
3 	FsDomSrv.dll 	FsDomSrv.dll@0x1a823

More reports at:
https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Aa11y%3A%3AGetExistingDocAccessible%28nsIDocument+const*%29

Comment 1

[alexander :surkov (:asurkov)]

seems similar to bug 857348: no node while the accessible is not defunct

Comment 2

[Trevor Saunders (:tbsaunde)]

(In reply to alexander :surkov from comment #1)
> seems similar to bug 857348: no node while the accessible is not defunct

accept that sdnAccessible should be much smaller than 0x32 (I'd guess sizeof(sdnAccessible) == 0xc, but that might be worth checking.

when you inline all the functions you get this
mNode->mNodeInfo->mDocument->mBFCacheEntry / mPresShell

the offset of mNodeInfo in nsINode on a linux 64 debug build is 0x18 and its hard to imagine that it wouldn't be even smaller on  a win32 release build so it doesn't seem likely that  mNode is null.
Smaug says mNodeInfo should never be null, and mDocument is its first member after a single vtable so that's proably not null
mPresShell and mBFCacheEntry are about 0x200 into a nsIDocument on the same linux64 debug build so they're probably too far...

since all the callers of sdnAccessible's constructor null check, and creating a sdnAccessible with null mNode will lead to crashes when you try and use it lets crash in the constructor "just to be sure"

Comment 3

[Trevor Saunders (:tbsaunde)]

Attachment: bug 858896 - crash if sdnAccessible is constructed with a null node

crash earlier when we might have some idea what's going wrong if it is infact a null mNode

Comment 4

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

Comment on attachment 734669 [details] [diff] [review]
bug 858896 - crash if sdnAccessible is constructed with a null node

Review of attachment 734669 [details] [diff] [review]:
-----------------------------------------------------------------

r=me as a diagnostic I guess. Note the crashes all happen on Aurora (currently FF22) so not sure this will give us the info we want soon.

Crash address ranges from 0x2d to 0x33.

Comment 5

[Trevor Saunders (:tbsaunde)]

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/68fc259ff3e0

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/68fc259ff3e0

Comment 7

[alexander :surkov (:asurkov)]

(In reply to Trevor Saunders (:tbsaunde) from comment #5)
> remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/68fc259ff3e0

keeping this open? I guess we will be reported by another bug.

Comment 8

[Scoobidiver (away)]

It's #55 browser crasher in Aurora. I haven't seen it in 23.0a1.

Comment 9

[Trevor Saunders (:tbsaunde)]

might well be fixed by bug 865240 which we need to backport anyway

Comment 10

[alexander :surkov (:asurkov)]

no fresh reports, wfm