285755 - crash when loading (or sometimes only when reloading) HTML page with onerror event handler containing switch

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Martin Honnen]

This came up in the comp.lang.javascript posting here:
<http://groups-beta.google.com/group/comp.lang.javascript/msg/80548c5a06d33120?safe=images&as_umsgid=[e-mail]&lr=&hl=en>
Mozilla 1.7.5 release builds (tested with the Mozilla suite 1.7.5 release as
well as with Firefox 1.0 release) crashes when loading the test case
<http://home.arcor.de/martin.honnen/mozillaBugs/ecmascript/crashSwitchOnError.html>
Sometimes the initial loading works well but then on reloading the crash occurs.
I file this on the JavaScript engine for the time being as I have at least one
talkback
<http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=4272783#id>
showing the crash occurs in js3250.dll. It might be a DOM bug however as onerror
is involved too, I am not able to tell that currently.
Here is the latest talkback on the test case crashing:
<http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=4273754#id>

Comment 1

[Bob Clary [:bc] (inactive)]

the default switch part might be a possible dupe of bug 278873, but I can't
reproduce the crash with a trunk build from 2005-01-20 which was before the fix
for 278873 was checked in.

A 1.7.6 debug winxpsp2 build from yesterday gives a stack:

NTDLL! 7c901230()
js_AllocStack(JSContext * 0x02f82108, unsigned int 3, void * * 0x0012ea10) line
390 + 39 bytes
nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJSClass * const 0x03010628,
nsXPCWrappedJS * 0x03015658, unsigned short 5, const nsXPTMethodInfo *
0x03000e88, nsXPTCMiniVariant * 0x0012ead4) line 1133 + 36 bytes
nsXPCWrappedJS::CallMethod(nsXPCWrappedJS * const 0x03015658, unsigned short 5,
const nsXPTMethodInfo * 0x03000e88, nsXPTCMiniVariant * 0x0012ead4) line 450
PrepareAndDispatch(nsXPTCStubBase * 0x03015658, unsigned int 5, unsigned int *
0x0012eb84, unsigned int * 0x0012eb74) line 117 + 31 bytes
SharedStub() line 147
nsContentTreeOwner::SetStatus(nsContentTreeOwner * const 0x0212f768, unsigned
int 3, const unsigned short * 0x0012ec7c) line 391
nsWebShell::OnOverLink(nsWebShell * const 0x02f81a5c, nsIContent * 0x031871b8,
nsIURI * 0x0323ab18, const unsigned short * 0x100c77f0 gNullChar) line 682 + 46
bytes
nsGenericElement::TriggerLink(nsIPresContext * 0x02fe10e8, nsLinkVerb
eLinkVerb_Replace, nsIURI * 0x03054278, nsIURI * 0x0323ab18, const nsString &
{...}, int 0, int 1) line 3208
nsGenericHTMLElement::HandleDOMEventForAnchors(nsIPresContext * 0x02fe10e8,
nsEvent * 0x0012f028, nsIDOMEvent * * 0x00000000, unsigned int 1, nsEventStatus
* 0x0012f074) line 1513 + 49 bytes
nsHTMLAnchorElement::HandleDOMEvent(nsIPresContext * 0x02fe10e8, nsEvent *
0x0012f028, nsIDOMEvent * * 0x00000000, unsigned int 1, nsEventStatus *
0x0012f074) line 328
nsEventStateManager::DispatchMouseEvent(nsIPresContext * 0x02fe10e8, nsGUIEvent
* 0x0012f754, unsigned int 331, nsIContent * 0x031871b8, nsIFrame * &
0x031b5988, nsIContent * 0x03186438) line 2570
nsEventStateManager::GenerateMouseEnterExit(nsIPresContext * 0x02fe10e8,
nsGUIEvent * 0x0012f754) line 2690
nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x02def3b8,
nsIPresContext * 0x02fe10e8, nsEvent * 0x0012f754, nsIFrame * 0x031b5988,
nsEventStatus * 0x0012f53c, nsIView * 0x03174c90) line 447
PresShell::HandleEventInternal(nsEvent * 0x0012f754, nsIView * 0x03174c90,
unsigned int 1, nsEventStatus * 0x0012f53c) line 6034 + 52 bytes
PresShell::HandleEvent(PresShell * const 0x031343b4, nsIView * 0x03174c90,
nsGUIEvent * 0x0012f754, nsEventStatus * 0x0012f53c, int 0, int & 1) line 5902 +
25 bytes
nsViewManager::HandleEvent(nsView * 0x03170758, nsGUIEvent * 0x0012f754, int 0)
line 2326
nsViewManager::DispatchEvent(nsViewManager * const 0x02fe1770, nsGUIEvent *
0x0012f754, nsEventStatus * 0x0012f640) line 2066 + 20 bytes
HandleEvent(nsGUIEvent * 0x0012f754) line 77
nsWindow::DispatchEvent(nsWindow * const 0x03174a9c, nsGUIEvent * 0x0012f754,
nsEventStatus & nsEventStatus_eIgnore) line 1067 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f754) line 1088
nsWindow::DispatchMouseEvent(unsigned int 300, unsigned int 0, nsPoint *
0x00000000) line 5259 + 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 300, unsigned int 0, nsPoint *
0x00000000) line 5512
nsWindow::ProcessMessage(unsigned int 512, unsigned int 0, long 31391981, long *
0x0012fbf8) line 4025 + 28 bytes
nsWindow::WindowProc(HWND__ * 0x00270194, unsigned int 512, unsigned int 0, long
31391981) line 1349 + 27 bytes
USER32! 77d48709()
USER32! 77d487eb()
USER32! 77d489a5()
USER32! 77d489e8()
nsAppShell::Run(nsAppShell * const 0x00a3dcb0) line 135
nsAppShellService::Run(nsAppShellService * const 0x00a3da00) line 524
main1(int 1, char * * 0x002e2580, nsISupports * 0x00a1cff8) line 1303 + 32 bytes
main(int 1, char * * 0x002e2580) line 1781 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 7c816d4f()

These stacks are quite different. jst?

Comment 2

[Brendan Eich [:brendan]]

Bug 278873 was a debugger issue, not a crash loading or running switch code.

This looks like yet another bad JSContext pointer passed in from docshell land.
 Taking the chance of giving to Embedding: Docshell.  Someone spank me if that's
wrong.

/be

Comment 3

[Boris Zbarsky [:bzbarsky]]

Mm....  The trunk code for this should look quite radically different (the JS
context involved is the chrome one, btw, not the one from the document, as far
as I can tell).

Is this a problem on trunk?

Comment 4

[Bob Clary [:bc] (inactive)]

(In reply to comment #3)
> Is this a problem on trunk?

Not that I can tell. It crashed right away in 1.7.6, but not in trunk for
repeated reloads.

Comment 5

[Martin Honnen]

(In reply to comment #3)
> Is this a problem on trunk?

No, as far as I can tell, no crash with Mozilla 1.8b2 (Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050304).

Comment 6

[Boris Zbarsky [:bzbarsky]]

I'm not sure it's really desirable to port the trunk window.status rearch to the
branch, though.

Comment 7

[Bob Clary [:bc] (inactive)]

I am tempted to mark this wontfix since the crash is not reproducible anymore, but on the trunk I do get:

WARNING: Somehow not a plaintext editor?, file .../mozilla/layout/forms/nsTextControlFrame.cpp, line 3110

      nsCOMPtr<nsIPlaintextEditor> htmlEditor = do_QueryInterface(mEditor);
      if (!htmlEditor) {
        NS_WARNING("Somehow not a plaintext editor?");
        if (pushed) {
          JSContext* cx;
          stack->Pop(&cx);
          NS_ASSERTION(!cx, "Unexpected JSContext popped!");
        }        
      }

where pushed is 0x01 and

-	mEditor	{...}
-	mRawPtr	0x034850d8
+	[nsPlaintextEditor]	{...}
+	nsISupports	{...}

resulting in the assertion 

###!!! ASSERTION: Unexpected JSContext popped!: '!cx', file .../mozilla/layout/forms/nsTextControlFrame.cpp, line 3153

      if (pushed) {
        JSContext* cx;
        stack->Pop(&cx);
        NS_ASSERTION(!cx, "Unexpected JSContext popped!");
      }

finally with 

###!!! ASSERTION: ThreadJSContextStack underflow: 'mStack.GetSize() > 0', file .../mozilla/js/src/xpconnect/src/xpcthreadcontext.cpp, line 95

Comment 8

[Boris Zbarsky [:bzbarsky]]

Bob, I'm not sure why that QI to nsIPlaintextEditor failed, but the ensuing assertions are due to a bug in the patch for bug 287446.  An early return that should be there got lost.  :(

We should probably file a separate bug on that and fix it on the 1.8 branches... :(

Comment 9

[Bob Clary [:bc] (inactive)]

Filed bug 321494, marking this wontfix.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Bug 321238 explains why the QI to nsIPlaintextEditor fails (bug 293485).