637288 - Crash [@ ns_if_addref<jsdIExecutionHook*>(jsdIExecutionHook*) ]

Status: RESOLVED WORKSFORME

(Core :: DOM: Editor, defect)

Description

[Scoobidiver (away)]

It is a new crash signature in 4.0b12.
It is currently #53 top crasher in 4.0b12.

Signature	ns_if_addref<jsdIExecutionHook*>(jsdIExecutionHook*)
UUID	2566fff1-f54d-4bc1-b67b-31d772110228
Time 	2011-02-28 02:54:35.573136
Uptime	5280
Install Age	169280 seconds (2.0 days) since version was first installed.
Product	Firefox
Version	4.0b12
Build ID	20110222210221
Branch	2.0
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	AuthenticAMD family 16 model 10 stepping 0
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x4
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 0e22, AdapterDriverVersion: 8.17.12.6658

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	ns_if_addref<jsdIExecutionHook*> 	obj-firefox/dist/include/nsISupportsUtils.h:94
1 	xul.dll 	nsDOMDocumentType::GetNotations 	content/base/src/nsDOMDocumentType.cpp:180
2 	xul.dll 	nsDocShell::GetEditor 	docshell/base/nsDocShell.cpp:10543
3 	xul.dll 	GetHTMLEditor 	content/base/src/nsGenericElement.cpp:334
4 	xul.dll 	nsINode::GetSelectionRootContent 	content/base/src/nsGenericElement.cpp:375
5 	xul.dll 	nsFrameSelection::ConstrainFrameAndPointToAnchorSubtree 	layout/generic/nsSelection.cpp:914
6 	xul.dll 	nsFrameSelection::HandleDrag 	layout/generic/nsSelection.cpp:1707
7 	xul.dll 	nsFrame::HandleDrag 	
8 	xul.dll 	nsFrame::HandleEvent 	layout/generic/nsFrame.cpp:1848
9 	xul.dll 	nsPresShellEventCB::HandleEvent 	layout/base/nsPresShell.cpp:1488
10 	xul.dll 	nsEventTargetChainItem::HandleEventTargetChain 	content/events/src/nsEventDispatcher.cpp:386
11 	xul.dll 	nsEventDispatcher::Dispatch 	content/events/src/nsEventDispatcher.cpp:628
12 	xul.dll 	PresShell::HandleEventInternal 	layout/base/nsPresShell.cpp:7066
13 	xul.dll 	PresShell::HandlePositionedEvent 	layout/base/nsPresShell.cpp:6900
14 	xul.dll 	PresShell::HandleEvent 	layout/base/nsPresShell.cpp:6734
15 	xul.dll 	PresShell::HandleEvent 	
16 	xul.dll 	nsViewManager::HandleEvent 	view/src/nsViewManager.cpp:1105
17 	xul.dll 	nsViewManager::DispatchEvent 	view/src/nsViewManager.cpp:1083
18 	xul.dll 	AttachedHandleEvent 	view/src/nsView.cpp:193
19 	xul.dll 	nsWindow::DispatchEvent 	widget/src/windows/nsWindow.cpp:3786
20 	xul.dll 	nsWindow::DispatchWindowEvent 	widget/src/windows/nsWindow.cpp:3809
21 	xul.dll 	nsWindow::DispatchMouseEvent 	widget/src/windows/nsWindow.cpp:4233
22 	xul.dll 	nsWindow::ProcessMessage 	widget/src/windows/nsWindow.cpp:5115
23 	xul.dll 	nsWindow::WindowProcInternal 	widget/src/windows/nsWindow.cpp:4613
24 	xul.dll 	nsIMM32Handler::ProcessMessage 	widget/src/windows/nsIMM32Handler.cpp:401
25 	xul.dll 	nsIMM32Handler::ProcessMessage 	widget/src/windows/nsIMM32Handler.cpp:401
26 	xul.dll 	xul.dll@0x359b4d 	

More reports at:
https://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=ns_if_addref%3CjsdIExecutionHook*%3E%28jsdIExecutionHook*%29

Comment 1

[Boris Zbarsky [:bzbarsky]]

The part of that stack below GetEditor is bogus.  Ehsan, peter?  This looks pretty bad!

In particular, the call there is:

  return mEditorData->GetEditor(aEditor);

This is a non-virtual function, so I'm not sure how we're landing in the document type code (which _is_ a virtual function)...  but presumably in this case mEditorData is bogus?

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Why do you think this should block release, Boris? It's wayyyyy down on the crash list.

Comment 3

[Boris Zbarsky [:bzbarsky]]

I didn't realize a new #50 topcrash is way down on the list.

If it's actually low-frequency, then there's no reason to block on this, I suspect.

Comment 4

[(no longer active)]

(In reply to comment #1)
> The part of that stack below GetEditor is bogus.  Ehsan, peter?  This looks
> pretty bad!
> 
> In particular, the call there is:
> 
>   return mEditorData->GetEditor(aEditor);
> 
> This is a non-virtual function, so I'm not sure how we're landing in the
> document type code (which _is_ a virtual function)...  but presumably in this
> case mEditorData is bogus?

Hmm, even if mEditorData is bogus, it won't explain this crash.  We should just end up in nsDocShellEditorData::GetEditor with the wrong this pointer, right?

Comment 5

[Boris Zbarsky [:bzbarsky]]

You'd think so, yes....

Comment 6

[Scoobidiver (away)]

Now #31 top crasher in 4.0b12.

Comment 7

[Scoobidiver (away)]

There have been no crashes in versions above 4.0b12 for the last four weeks.
I close it as WFM.