760038 - crash in NotificationController::WillRefresh

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Scoobidiver (away)]

It first appeared in 15.0a1/20120530132235. The regression range is:

Signature 	DocAccessible::HasLoadState(DocAccessible::LoadState) More Reports Search
UUID	d3874bfd-1ae3-40ce-8bb2-6f4f42120531
Date Processed	2012-05-31 08:34:36
Uptime	69
Last Crash	1.6 minutes before submission
Install Age	4.0 hours since version was first installed.
Install Time	2012-05-31 04:35:12
Product	Firefox
Version	15.0a1
Build ID	20120530144327
Release Channel	nightly
OS	Windows NT
OS Version	5.1.2600 Service Pack 3
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 23 stepping 10
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0xe8
App Notes 	
AdapterVendorID: 0x8086, AdapterDeviceID: 0x2a42, AdapterSubsysID: 1484103c, AdapterDriverVersion: 6.14.10.5284
D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers+ 
EMCheckCompatibility	True	
Total Virtual Memory	2147352576
Available Virtual Memory	1594949632
System Memory Use Percentage	46
Available Page File	2585395200
Available Physical Memory	1112080384

Frame 	Module 	Signature 	Source
0 	xul.dll 	DocAccessible::HasLoadState 	accessible/src/generic/DocAccessible.h:142
1 	xul.dll 	DocAccessible::IsLoadEventTarget 	accessible/src/generic/DocAccessible.cpp:2033
2 	xul.dll 	DocAccessible::ProcessLoad 	accessible/src/generic/DocAccessible.cpp:1570
3 	xul.dll 	NotificationController::WillRefresh 	accessible/src/base/NotificationController.cpp:265
4 	xul.dll 	nsRefreshDriver::Notify 	layout/base/nsRefreshDriver.cpp:336
5 	xul.dll 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:476
6 	xul.dll 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:556
7 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:624
8 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:82
9 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:201
10 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:175
11 	xul.dll 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:163
12 	xul.dll 	nsAppShell::Run 	widget/windows/nsAppShell.cpp:232
13 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:256
14 	xul.dll 	XREMain::XRE_mainRun 	toolkit/xre/nsAppRunner.cpp:3786
15 	xul.dll 	XREMain::XRE_main 	toolkit/xre/nsAppRunner.cpp:3863
16 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3939
17 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:100
18 	firefox.exe 	__tmainCRTStartup 	crtexe.c:552
19 	kernel32.dll 	BaseProcessStart 	

More reports at:
https://crash-stats.mozilla.com/report/list?signature=DocAccessible%3A%3AHasLoadState%28DocAccessible%3A%3ALoadState%29
https://crash-stats.mozilla.com/report/list?signature=DocAccessible%3A%3AFireDelayedAccessibleEvent%28AccEvent*%29
https://crash-stats.mozilla.com/report/list?signature=DocAccessible%3A%3ADoInitialUpdate

Comment 1

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

Perhaps related to our absent parent document problems? I see this in the stack:
"ParentDocument()->FireDelayedAccessibleEvent(reorderEvent)" (which isn't new).

Comment 2

[alexander :surkov (:asurkov)]

(In reply to David Bolter [:davidb] from comment #1)
> Perhaps related to our absent parent document problems? I see this in the
> stack:
> "ParentDocument()->FireDelayedAccessibleEvent(reorderEvent)" (which isn't
> new).

it's caused by no parent document but what problem do you refer to?

Comment 3

[alexander :surkov (:asurkov)]

Attachment: patch

get back the ParentDocument() logic changed in bug 754165.

Comment 4

[Scoobidiver (away)]

(In reply to Scoobidiver from comment #0)
> It first appeared in 15.0a1/20120530132235. The regression range is:
... http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=79262a88881d&tochange=f28d1ec8bd33
bug 754165 belongs to it.

Comment 5

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

(In reply to alexander :surkov from comment #2)
> (In reply to David Bolter [:davidb] from comment #1)
> > "ParentDocument()->FireDelayedAccessibleEvent(reorderEvent)" (which isn't
> > new).
> 
> it's caused by no parent document but what problem do you refer to?

Nothing specific.

Comment 6

[Trevor Saunders (:tbsaunde)]

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

both ways of finding the parent doc seem  reasonable, but I'm not sure what the point of that change is, it seems like checking the parent is not null should be enough.

Comment 7

[alexander :surkov (:asurkov)]

(In reply to Trevor Saunders (:tbsaunde) from comment #6)
> Comment on attachment 628763 [details] [diff] [review]
> patch
> 
> both ways of finding the parent doc seem  reasonable,

that's what I thought

> but I'm not sure what
> the point of that change is, it seems like checking the parent is not null
> should be enough.

but apparently not because of new crash in ParentDocument()->FireDelayedAccessibleEvent (https://crash-stats.mozilla.com/report/list?signature=DocAccessible%3A%3AFireDelayedAccessibleEvent%28AccEvent*%29).

nsIContent::GetParentDocument is unclear about its return value (aka "may cross chrome boundaries") so I decided to rely on a11y tree instead.

Comment 8

[Trevor Saunders (:tbsaunde)]

ok, sounds fine.

Comment 9

[alexander :surkov (:asurkov)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/63271af1e3dc

Comment 10

[(no longer active)]

https://hg.mozilla.org/mozilla-central/rev/63271af1e3dc