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: 126.96.36.19984 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
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"
Created attachment 734669 [details] [diff] [review] 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 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.
(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.
It's #55 browser crasher in Aurora. I haven't seen it in 23.0a1.