Closed Bug 49600 Opened 24 years ago Closed 23 years ago

Crash with JavaScript turned off.

Categories

(Core :: XUL, defect, P3)

x86
All
defect

Tracking

()

VERIFIED DUPLICATE of bug 71421
Future

People

(Reporter: suckfish, Assigned: danm.moz)

References

()

Details

(Keywords: crash, relnote, Whiteboard: [nsbeta3-] relnote-devel)

Attachments

(2 files)

(1) Turn off JavaScript in preferences.
(2) Go to URL above.
(3) Click on "this window" link.

We crash with the following backtrace.

Note that nsXULDocument.cpp:5660, we call

    rv = context->ExecuteScript(aScriptObject, nsnull, nsnull, nsnull);

Those nsnulls get passed down & eventually we dereference one of them.

Reproduced with M17 and today's build.

#0  js_LockObj (cx=0x878a630, obj=0x0) at ../../../mozilla/js/src/jslock.c:716
#1  0x401335cc in js_GetSlotWhileLocked (cx=0x878a630, obj=0x0, slot=3) at
../../../mozilla/js/src/jslock.c:275
#2  0x4010e05c in JS_GetPrivate (cx=0x878a630, obj=0x0) at
../../../mozilla/js/src/jsapi.c:1723
#3  0x40360def in nsJSContext::ExecuteScript (this=0x879d688, aScriptObject=0x0,
aScopeObject=0x8705920, aRetValue=0x0, aIsUndefined=0x0) at
../../../../mozilla/dom/src/base/nsJSEnvironment.cpp:665
#4  0x404dbec9 in nsXULDocument::ExecuteScript (this=0x8c52e08,
aScriptObject=0x0) at ../../../../mozilla/rdf/content/src/nsXULDocument.cpp:5660
#5  0x404dbdb1 in nsXULDocument::OnStreamComplete (this=0x8c52e08,
aLoader=0x8905fd0, context=0x0, aStatus=0, stringLen=18873, string=0x8b97828
"\r\n/* ", '*' <repeats 74 times>, " *\r\n *", ' ' <repeats 76 times>, "*\r\n *
  Window opening and closing even"...) at
../../../../mozilla/rdf/content/src/nsXULDocument.cpp:5608
#6  0x4096ac72 in nsStreamLoader::OnStopRequest (this=0x8905fd0,
channel=0x87db4f8, ctxt=0x0, aStatus=0, aStatusArg=0x400ec014) at
../../../../mozilla/netwerk/base/src/nsStreamLoader.cpp:121
#7  0x4099f40c in nsHTTPFinalListener::OnStopRequest (this=0x87dbb08,
aChannel=0x87db4f8, aContext=0x0, aStatus=0, aStatusArg=0x400ec014) at
../../../../../mozilla/netwerk/protocol/http/src/nsHTTPResponseListener.cpp:1197
#8  0x4097e60a in InterceptStreamListener::OnStopRequest (this=0x8749e60,
channel=0x87db4f8, ctxt=0x0, aStatus=0, aStatusArg=0x400ec014) at
../../../../mozilla/netwerk/cache/mgr/nsCachedNetData.cpp:1185
#9  0x40997d19 in nsHTTPChannel::ResponseCompleted (this=0x87db4f8,
aListener=0x8749e60, aStatus=0, aStatusArg=0x400ec014) at
../../../../../mozilla/netwerk/protocol/http/src/nsHTTPChannel.cpp:1761
#10 0x4099e79d in nsHTTPServerListener::OnStopRequest (this=0x88a5b68,
channel=0x8aab4dc, i_pContext=0x87db4f8, i_Status=0, aStatusArg=0x400ec014) at
../../../../../mozilla/netwerk/protocol/http/src/nsHTTPResponseListener.cpp:725
#11 0x4095857c in nsOnStopRequestEvent::HandleEvent (this=0x41300da0) at
../../../../mozilla/netwerk/base/src/nsAsyncStreamListener.cpp:301
#12 0x40957f22 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x41300dd8) at
../../../../mozilla/netwerk/base/src/nsAsyncStreamListener.cpp:97
#13 0x400c1a54 in PL_HandleEvent (self=0x41300dd8) at
../../../mozilla/xpcom/threads/plevent.c:587
#14 0x400c196a in PL_ProcessPendingEvents (self=0x80a71e0) at
../../../mozilla/xpcom/threads/plevent.c:528
#15 0x400c289c in nsEventQueueImpl::ProcessPendingEvents (this=0x80a71b8) at
../../../mozilla/xpcom/threads/nsEventQueue.cpp:356
#16 0x4057c494 in event_processor_callback (data=0x80a71b8, source=7,
condition=GDK_INPUT_READ) at ../../../../mozilla/widget/src/gtk/nsAppShell.cpp:158
#17 0x4057c1f8 in our_gdk_io_invoke (source=0x8346268, condition=G_IO_IN,
data=0x8346258) at ../../../../mozilla/widget/src/gtk/nsAppShell.cpp:58
#18 0x40722ee9 in g_io_unix_dispatch (source_data=0x8346280,
current_time=0xbffffa64, user_data=0x8346258) at giounix.c:135
#19 0x40724646 in g_main_dispatch (dispatch_time=0xbffffa64) at gmain.c:656
#20 0x40724c40 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#21 0x40724de9 in g_main_run (loop=0x83462c8) at gmain.c:935
#22 0x40649489 in gtk_main () at gtkmain.c:476
#23 0x4057ca12 in nsAppShell::Run (this=0x80ac2e0) at
../../../../mozilla/widget/src/gtk/nsAppShell.cpp:335
#24 0x40436e07 in nsAppShellService::Run (this=0x80ae880) at
../../../../mozilla/xpfe/appshell/src/nsAppShellService.cpp:378
#25 0x0804de65 in main1 (argc=1, argv=0xbffffc74, nativeApp=0x0) at
../../../mozilla/xpfe/bootstrap/nsAppRunner.cpp:943
#26 0x0804e2d8 in main (argc=1, argv=0xbffffc74) at
../../../mozilla/xpfe/bootstrap/nsAppRunner.cpp:1123
#27 0x4022bb10 in __libc_start_main () from /usr/lib/libc.so.6
Using Mozilla tip builds: 2000-08-17  8PM Pacific Time on WinNT  
                          2000-08-21  1PM Pacific Time on Linux

Confirming crash on WinNT and Linux. Changing OS to "All".
Attaching stack traces. Note the WinNT stack trace resembles the reporter's.
The Linux trace is different, but also involves code from nsXULdocument. 

Sending to XUL group for review. Don't know if this is the right component,
but it is not an Engine issue with the JavaScript turned off in Preferences...

For what it's worth, these were the last line I saw in the debug console
before I crashed on Linux:

###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 
'mRawPtr != 0', file ../../dist/include/nsCOMPtr.h, line 649
###!!! Break: at file ../../dist/include/nsCOMPtr.h, line 649 
Assignee: rogerl → trudelle
Status: UNCONFIRMED → NEW
Component: Javascript Engine → XP Toolkit/Widgets: XUL
Ever confirmed: true
OS: Linux → All
QA Contact: pschwartau → jrgm
Attached file Linux stack trace -
Attached file WinNT stack trace -
Adding crash keyword to all open crashers
Keywords: crash
->danm, nominating for nsbeta3.  Does this happen on any top-100 sites?  How
about when using XUL anywhere else in the product?  
Assignee: trudelle → danm
Keywords: nsbeta3
Whiteboard: [need info]
nsbeta3-, relnote for N6.  Should only affect UI developers, let's make sure 
they know to keep JS on.
Keywords: relnote
Whiteboard: [need info] → [nsbeta3-]
Target Milestone: --- → Future
Whiteboard: [nsbeta3-] → [nsbeta3-] relnote-devel
I don't understand this bug well enough to write a good release note -- could 
one of you (John, Phil, Dan?) write an appropriate release note in this bug
as soon as possible? Thanks.
This xul file will also crash the same way (if test.js exists):

<?xml version="1.0"?> 
<window xmlns:html="http://www.w3.org/TR/REC-html40"
        xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
<script type="text/javascript" src="test.js"/>
<text value="don't look at me"/>
</window>

You'll crash with every attempt to load a xul file that references an external 
js file (unless the xul file was loaded from a chrome URL). Basically, you're OK 
loading HTML, but don't be loading XUL files (except for the blessed standard UI 
content chrome files) with JS disabled.
Thanks!
this bug and 71421 are duplicates, and although I shouldn't mark the older 
as dup of newer, in this case, I am. So, there.

*** This bug has been marked as a duplicate of 71421 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
verified
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: