Last Comment Bug 310508 - Calling method on another window crashes when the function uses XMLHttpRequest and alert() [@ js_FreeStack]
: Calling method on another window crashes when the function uses XMLHttpReques...
: crash, fixed1.8.1, verified1.8.0.2
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
P1 critical (vote)
: mozilla1.9alpha1
Assigned To: Blake Kaplan (:mrbkap)
: Hixie (not reading bugmail)
: Andrew Overholt [:overholt]
Depends on:
Blocks: 315254
  Show dependency treegraph
Reported: 2005-09-29 16:12 PDT by Johnny Stenback (:jst,
Modified: 2006-03-02 19:07 PST (History)
6 users (show)
dveditz: blocking1.8.0.2+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

File used by the testcase (195 bytes, text/html)
2005-09-29 16:13 PDT, Johnny Stenback (:jst,
no flags Details
Testcase. (289 bytes, text/html)
2005-09-29 16:15 PDT, Johnny Stenback (:jst,
no flags Details
Testcase (291 bytes, text/html)
2005-09-29 16:17 PDT, Johnny Stenback (:jst,
no flags Details
Potential fix (6.86 KB, patch)
2006-02-23 13:56 PST, Blake Kaplan (:mrbkap)
jst: review+
bzbarsky: superreview+
jst: approval‑branch‑1.8.1+
dveditz: approval1.8.0.2+
Details | Diff | Splinter Review

Description User image Johnny Stenback (:jst, 2005-09-29 16:12:57 PDT
Not sure what's going on here, but I get a reproducable crash with the testcase
I'm about to attach. The testcase opens a new window and loads a page in it that
has a JS function in it that creates a XMLHttpRequest object and then calls
alert(), and that ends up crashing in JS_FreeStack() called from the window
watcher. The problem seems to be that the context passed to JS_FreeStack() has
been deleted...
Comment 1 User image Johnny Stenback (:jst, 2005-09-29 16:13:34 PDT
Created attachment 197931 [details]
File used by the testcase
Comment 2 User image Johnny Stenback (:jst, 2005-09-29 16:15:38 PDT
Created attachment 197932 [details]

This is the testcase. Load this, click "open", then "close" and the new window
should close after two alerts, but instead we crash either when closing the
first or second alert.
Comment 3 User image Johnny Stenback (:jst, 2005-09-29 16:17:15 PDT
Created attachment 197933 [details]

Right URL this time, I hope...
Comment 4 User image Johnny Stenback (:jst, 2005-09-29 16:18:00 PDT
Note that I've only seen this in debug builds so far, 1.8 branch.
Comment 5 User image Ria Klaassen (not reading all bugmail) 2005-09-30 03:36:04 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20050929
Firefox/1.4 ID:2005092922

I could only reproduce this once but never again: TB9890886W
Comment 6 User image timeless 2005-09-30 05:00:42 PDT
Incident ID: 9890886 
Stack Signature js_FreeStack 799b5d0d 
Product ID Firefox15 
Build ID 2005092906 
Trigger Time 2005-09-30 03:28:55.0 
Platform Win32 
Operating System Windows NT 5.1 build 2600 
Module js3250.dll + (0001e1a2) 
URL visited 
User Comments  
Since Last Crash 4111 sec 
Total Uptime 4111 sec 
Trigger Reason Access violation 
Source File, Line No. c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 427 
Stack Trace  

js_FreeStack  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 427]
nsWindowWatcher::OpenWindowJS  [c:/builds/tinderbox/Fx-
dowWatcher.cpp, line 565]
nsJSConsoleService::Open  [c:/builds/tinderbox/Fx-
leService.cpp, line 71]
nsPromptService::Confirm  [c:/builds/tinderbox/Fx-
mptService.cpp, line 185]
nsPrompt::PromptUsernameAndPassword  [c:/builds/tinderbox/Fx-
mpt.cpp, line 325]
nsGlobalWindow::Alert  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp, line 3234]
XPTC_InvokeByIndex  [c:/builds/tinderbox/Fx-
e.cpp, line 102]
XPCWrappedNative::CallMethod  [c:/builds/tinderbox/Fx-
line 2173]
XPC_WN_GetterSetter  [c:/builds/tinderbox/Fx-
pp, line 1422]
js_Invoke  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1163]
js_Interpret  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 3468]
js_Invoke  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1183]
js_InternalInvoke  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1260]
JS_CallFunctionValue  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsapi.c, line 4017]
nsJSContext::CallEventHandler  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1406]
nsJSEventListener::HandleEvent  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/dom/src/events/nsJSEventListener.cpp, line 
nsEventListenerManager::HandleEventSubType  [c:/builds/tinderbox/Fx-
p, line 1655]
DispatchToInterface  [c:/builds/tinderbox/Fx-
p, line 135]
nsGenericElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 
nsHTMLInputElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-
cpp, line 1353]
PresShell::HandleEventInternal  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 6373]
PresShell::HandleEventInternal  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 6283]
nsEventStateManager::GenerateDragDropEnterExit  [c:/builds/tinderbox/Fx-
line 2830]
nsEventStateManager::DoScrollText  [c:/builds/tinderbox/Fx-
line 1797]
PresShell::HandleEventInternal  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 6443]
PresShell::HandleEvent  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 6134]
nsViewManager::HandleEvent  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/view/src/nsViewManager.cpp, line 2536]
nsViewManager::DispatchEvent  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/view/src/nsViewManager.cpp, line 2217]
nsIView::CreateWidget  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/view/src/nsView.cpp, line 638]
nsWindow::DispatchWindowEvent  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 1277]
nsWindow::DispatchMouseEvent  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 6010]
PromiseFlatString  [../../../dist/include/string/nsTPromiseFlatString.h, line 
nsWindow::DefaultWindowProc  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 1456]
USER32.dll + 0x8709 (0x77d18709)
USER32.dll + 0x87eb (0x77d187eb)
USER32.dll + 0x89a5 (0x77d189a5)
USER32.dll + 0x89e8 (0x77d189e8)
nsAppShell::GetNativeEvent  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/widget/src/windows/nsAppShell.cpp, line 181]
nsAppStartup::Quit  [c:/builds/tinderbox/Fx-
cpp, line 164]
main  [c:/builds/tinderbox/Fx-
Mozilla1.8/WINNT_5.2_Depend/mozilla/browser/app/nsBrowserApp.cpp, line 61]
kernel32.dll + 0x16d4f (0x7c816d4f)
Comment 7 User image Marc Bejarano 2005-11-10 23:17:20 PST
talkback: TB11693607G may be this
Comment 8 User image Wayne Mery (:wsmwk, NI for questions) 2006-01-22 18:01:26 PST
is bug 314974 duplicate?
Comment 9 User image Blake Kaplan (:mrbkap) 2006-02-23 13:56:50 PST
Created attachment 212955 [details] [diff] [review]
Potential fix

In the middle of displaying the dialog, our window is having SetDocShell(nsnull) called on it, causing it to destroy its script context. The window watcher needs to hold onto said script context until after it really is done with the context.
Comment 10 User image Johnny Stenback (:jst, 2006-02-23 15:09:31 PST
Comment on attachment 212955 [details] [diff] [review]
Potential fix

Comment 11 User image Boris Zbarsky [:bz] (still a bit busy) 2006-02-23 20:48:17 PST
Comment on attachment 212955 [details] [diff] [review]
Potential fix

s/truely/truly/ please.
Comment 12 User image Blake Kaplan (:mrbkap) 2006-02-24 13:14:13 PST
Fix checked into trunk.
Comment 13 User image Blake Kaplan (:mrbkap) 2006-02-25 13:28:37 PST
Comment on attachment 212955 [details] [diff] [review]
Potential fix

I know that time is short for, but this does block blocker bug 315254. Do we want this on the 1.8.0 branch or should it wait for more trunk baking?
Comment 14 User image Daniel Veditz [:dveditz] 2006-02-27 11:56:42 PST
Comment on attachment 212955 [details] [diff] [review]
Potential fix

approved for 1.8.0 branch, a=dveditz for drivers
Comment 15 User image Blake Kaplan (:mrbkap) 2006-02-27 13:28:11 PST
Fix checked into the 1.8 branches.
Comment 16 User image Jay Patel [:jay] 2006-03-02 15:38:41 PST
Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060302 Firefox/, I don't crash with the testcase, but I am also not seeing the second alert after closing the first one ("foo").  I don't see anything in the JS console, so I'm wondering if the second part is executed at all

var result_html = xmlhttp.responseText;

That would be bad, no?  Johnny is going to try to reproduce with today's 1.8.0 build as well.
Comment 17 User image Jay Patel [:jay] 2006-03-02 19:03:10 PST
v.fixed on 1.8.0 branch, no crash.  Second alert not popping up is expected behavior on Windows (more from mrbkap soon).
Comment 18 User image Blake Kaplan (:mrbkap) 2006-03-02 19:07:43 PST
jst and I looked into this and we found that the script was actually continuing to execute as expected, however on Windows, the alert was simply failing to show, probably because it was a modal alert and it didn't have a parent to display on. Linux probably doesn't require a parent window for modal dialogs, so it was displaying the alert anyway.

Note You need to log in before you can comment on or make changes to this bug.