Closed Bug 858896 Opened 11 years ago Closed 6 years ago

crash in mozilla::a11y::GetExistingDocAccessible


(Core :: Disability Access APIs, defect)

22 Branch
Windows 7
Not set



Tracking Status
firefox21 --- unaffected
firefox22 --- affected
firefox23 --- unaffected


(Reporter: scoobidiver, Unassigned)



(Keywords: crash, regression, Whiteboard: [leave open])

Crash Data


(1 file)

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 Address	0x32
App Notes 	
AdapterVendorID: 0x8086, AdapterDeviceID: 0x2572, AdapterSubsysID: 71011462, AdapterDriverVersion:
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:*%29
seems similar to bug 857348: no node while the accessible is not defunct
(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"
crash earlier when we might have some idea what's going wrong if it is infact a null mNode
Attachment #734669 - Flags: review?(dbolter)
Whiteboard: [leave open]
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.
Attachment #734669 - Flags: review?(dbolter) → review+
(In reply to Trevor Saunders (:tbsaunde) from comment #5)
> remote:

keeping this open? I guess we will be reported by another bug.
It's #55 browser crasher in Aurora. I haven't seen it in 23.0a1.
might well be fixed by bug 865240 which we need to backport anyway
Depends on: 865240
Crash Signature: [@ mozilla::a11y::GetExistingDocAccessible(nsIDocument const*)] → [@ mozilla::a11y::GetExistingDocAccessible(nsIDocument const*)] [@ mozilla::a11y::GetExistingDocAccessible]
no fresh reports, wfm
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.