Closed Bug 144834 Opened 22 years ago Closed 22 years ago

mozilla crashes when loading page [@ js_Interpret]

Categories

(Core :: JavaScript Engine, defect)

x86
All
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla1.0.1

People

(Reporter: Roel.Teuwen, Assigned: brendan)

References

()

Details

(Keywords: crash, js1.5, topcrash)

Crash Data

Attachments

(4 files)

when surfing to a specific part of the kinepolis.be website, the browser crashes.
This crash has been present in multiple versions.

I think it is javascript related as the site uses it heavily.

to recreate the problem, surf to www.kinepolis.be and click the banner-type
navigation button on top that says "kin3ticket online" or similar. This is the
part of the site that allows to buy movie tickets online. register and log in
(registering is free, any email address should be sufficiant to gain access,
valid or not, afaict)

after pressing the "enter" button, select a movie theatre by clicking any of the
mentioned choices. I chose Metropolis Antwerpen. the browser crashes when it is
loading the following page.

regardless if the code is valid or not, I don't think the browser should crash.
Do you have a talkback ID from that crash ?
Severity: major → critical
Keywords: crash
I am sorry to say that I have not. I am currently running the debian unstable
package of mozilla 1.0rc2 (I don't think this version is talkback enabled?).

OK, I just installed the 1.0rc2 version from ftp.mozilla.org and the same crash
happens. Shouldn't it prompt for talkback ? All I got was this on the commandline:
run-mozilla.sh: line 72:  6738 Segmentation fault       $prog ${1+"$@"}
crashes here too.
Linux, Build 2002051121

Talkback:
TB6360687Q
Status: UNCONFIRMED → NEW
Ever confirmed: true
still present in 1.0.0
Kail: 
Can you please generate a new Talkback ID ?
I will get a stack this time...
TB7905246E
JS engine based on that stack

js_Interpret()
js_Execute()
js_EmitTree()
js_EmitTree()
js_EmitTree()
js_EmitTree()
js_EmitFunctionBody()
js_EmitTree()
Statements()
js_CompileTokenStream()
CompileTokenStream()
JS_CompileUCScriptForPrincipals()
JS_EvaluateUCScriptForPrincipals()
nsJSContext::EvaluateString()
nsScriptLoader::EvaluateScript()
nsScriptLoader::ProcessRequest()
nsScriptLoader::ProcessScriptElement()
nsHTMLScriptElement::SetDocument()
nsGenericHTMLContainerElement::AppendChildTo()
HTMLContentSink::ProcessSCRIPTTag()
HTMLContentSink::AddLeaf()
CNavDTD::AddLeaf()
CNavDTD::HandleScriptToken()
CNavDTD::OpenContainer()
CNavDTD::HandleDefaultStartToken()
CNavDTD::HandleStartToken()
CNavDTD::HandleToken()
CNavDTD::BuildModel()
nsParser::BuildModel()
nsParser::ResumeParse()
nsParser::ContinueParsing()
CSSLoaderImpl::Cleanup()
CSSLoaderImpl::SheetComplete()
CSSLoaderImpl::ParseSheet()
CSSLoaderImpl::DidLoadStyle()
SheetLoadData::OnStreamComplete()
nsStreamLoader::OnStopRequest()
nsStreamListenerTee::OnStopRequest()
nsHttpChannel::OnStopRequest()
nsOnStopRequestEvent::HandleEvent()
nsARequestObserverEvent::HandlePLEvent()
PL_HandleEvent()
PL_ProcessPendingEvents()
nsEventQueueImpl::ProcessPendingEvents()
event_processor_callback()
our_gdk_io_invoke()
libglib-1.2.so.0 + 0xee00 (0x4037ae00)
libglib-1.2.so.0 + 0x104c8 (0x4037c4c8)
libglib-1.2.so.0 + 0x10ad3 (0x4037cad3)
libglib-1.2.so.0 + 0x10c6c (0x4037cc6c)
libgtk-1.2.so.0 + 0x8d7f7 (0x4029d7f7)
nsAppShell::Run()
nsAppShellService::Run()
main1()
main()
libc.so.6 + 0x1914f (0x404b714f) 
Assignee: Matti → rogerl
Component: Browser-General → JavaScript Engine
QA Contact: imajes-qa → pschwartau
When I click the "Metropolis Antwerpen" link, I just hang on WinNT,
using either IE6 or Mozilla 2002070108.

As best as I can tell, here is the URL for the page.
At least, with my current SessionID, etc.:

https://www.megatix.be/BossScripts/WWWSrv.dll/xPage?APP=WWW&PAGE=MAIN&FRAME=SPLI
T&OBJ=DATA&SESSID=75157&LNG=EN&COMP=METRO&COMPNAME=Metropolis Antwerpen&XLOG=N

Can anyone tell me, how long does it take before you crash?
Do you have to wait a long time?

Does this crash for anyone on Windows, or is this Linux-only?
Assignee: rogerl → khanson
Phil: I can't reproduce the crash on my win2k system. Possible only linux...
It happens almost instantly. When the link is slow I can see it loads the page
for about a second (if that) and then crashes.

The crash also occurs in Windows. (invalid page fault in JS3250.DLL)
TB 7931041K
Attached file Minimal testcase
This crashes Linux Mozilla reliably.  Removing the |function| from around the
other stuff stops the crash.  Getting rid of the declaration of |MinBound| or
changing the |case| to use a constant of some sort stops the crash.  Changing
"language" to "JavaScript1.5" stops the crash, but both "JavaScript1.1" and
"JavaScript1.2" crash.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 23114)]
0x400d5e22 in js_Interpret (cx=0x855cdd0, result=0x86365a0) at jsinterp.c:3216
3216		    PUSH_OPND(fp->vars[slot]);
Current language:  auto; currently c

(gdb) p fp->vars
$1 = (jsval *) 0x0

(gdb) p fp->fun->nvars
$2 = 1

(gdb) p slot
$3 = 0

(gdb) p *fp->fun
$5 = {nrefs = 1, object = 0x860f790, native = 0, script = 0x0, nargs = 0, extra
= 0, 
  nvars = 1, flags = 0 '\0', spare = 0 '\0', atom = 0x8635580, clasp = 0x0}

(gdb) p *fp
$7 = {callobj = 0x0, argsobj = 0x0, varobj = 0x860f790, script = 0x8635f58, 
  fun = 0x86355a0, thisp = 0x0, argc = 0, argv = 0x0, rval = -2147483647, nvars
= 0, 
  vars = 0x0, down = 0xbfffd910, annotation = 0x0, scopeChain = 0x860f790, 
  pc = 0x8635f8c "V", sp = 0x86370d4, spbase = 0x86370d4, sharpDepth = 0, 
  sharpArray = 0x0, flags = 0, dormantNext = 0x0}

so the problem is having fp->fun->nvars > 0 while fp->vars == 0 and 
fp->nvars == 0
Boris: thanks! Testcase added to JS testsuite:

          js1_2/regress/regress-144834.js

cc'ing Brendan on this JS1.1/JS1.2 crash. This crashes the JS shell
on WinNT, too, so changing OS from Linux ---> All.

OS: Linux → All
Note: for convenience, here is Boris' reduced testcase:

<script language="JavaScript1.1">

   function RedrawSched() {
       var MinBound;

       switch (i) {
         case MinBound :
       }
   } 
  
</script>
This has been busted forever.  I have a patch to rip out the old compile-time
case evaluation of JS1.0-JS1.3 (truth be told, switch didn't show up in this
busted form until JS1.2, but SpiderMonkey accepts switch statements for versions
1.0 and 1.1 too).

/be
Assignee: khanson → brendan
This ought to fix all variations on the theme.

/be
shaver, khanson, please review.

/be
Please help get this fix into 1.0.1 and 1.1beta.

/be
Blocks: 149801
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
Comment on attachment 90362 [details] [diff] [review]
diff -wu of last patch

I _sort_of_ dislike the idea of breaking JS1.1/1.2 compatibility, but then I
wake up in the real world, and I'm fine with it.

sr=shaver.
Attachment #90362 - Flags: superreview+
As entries in js.msg become unused, they should be replaced with JSMSG_UNUSEDn
where n is the message index, with the string "<Error #n is currently unused>".
 New messages should (ahem, I've failed to do this already) recycle unused
slots instead of appending to the end.

/be
Comment on attachment 90362 [details] [diff] [review]
diff -wu of last patch

r=khanson  changes look safe.
Attachment #90362 - Flags: review+
Comment on attachment 90378 [details] [diff] [review]
fix js.msg to match last patch

r=khanson
Attachment #90378 - Flags: review+
I applied the patches above for jsemit.c and js.msg and ran
the entire testsuite in the optimized JS shell on WinNT.

They fixed this bug, and introduced no regressions -
Fixed on trunk.  Going for branch approval.

/be
Comment on attachment 90362 [details] [diff] [review]
diff -wu of last patch

a=chofmann for the 1.0.1 branch.
Attachment #90362 - Flags: approval+
Adding the talkback decorations so that we can track it as it drops of the top40
lists in the Trunk data.
Keywords: topcrash
Summary: mozilla crashes when loading page → mozilla crashes when loading page [@ js_Interpret]
Fixed in the branch, too.

/be
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Brendan / Phil,
The Talkback Trunk data still shows some incidents under js_Interpret following
the 7-8 checkin to the Trunk. (No branch incidents.) I have not been able to
crash my Win2000 box with the steps in this bug or with Boris' testcase. 
The Trunk incndents are probably not the same issue.

Would someone with a Linux box please verify this particular crash is fixed.

Trunk (js_Interpret):
   # Build      ID #
   1 2002071204 (8361674)
   1 2002071404 (8308440)
   1 2002071508 (8357312)
   1 2002071608 (8389612)
verified with linux trunk build 2002-07-15-08.  I don't have a branch build
handy, however... so it would be good if someone checked that and twiddled the
keywords appropriately.  ;)
Status: RESOLVED → VERIFIED
Verified on branch; adding verified1.0.1 keyword.

Using Mozilla branch build 2002071707 on Linux. I tried both the
original steps to reproduce above, and Boris' reduced testcase.
No problems; did not crash on anything.

In addition, the JS testcase above now passes in the debug and 
optimized JS shell.

Also checked in CVS that there is no difference between the
-rHEAD, -rMOZILLA_1_0_BRANCH revisions of jsemit.c, js.msg.
Keywords: verified1.0.1
Flags: testcase+
Crash Signature: [@ js_Interpret]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: