144834 - mozilla crashes when loading page [@ js_Interpret]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Roel Teuwen]

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.

Comment 1

[Matthias Versen [:Matti]]

Do you have a talkback ID from that crash ?

Comment 2

[Roel Teuwen]

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+"$@"}

Comment 3

[Kai Lahmann (is there, where MNG is)]

crashes here too.
Linux, Build 2002051121

Talkback:
TB6360687Q

Comment 4

[Roel Teuwen]

still present in 1.0.0

Comment 5

[Matthias Versen [:Matti]]

Kail: 
Can you please generate a new Talkback ID ?
I will get a stack this time...

Comment 6

[Roel Teuwen]

TB7905246E

Comment 7

[Boris Zbarsky [:bzbarsky]]

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) 

Comment 8

[Phil Schwartau]

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?

Comment 9

[Matthias Versen [:Matti]]

Phil: I can't reproduce the crash on my win2k system. Possible only linux...

Comment 10

[Roel Teuwen]

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

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: 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

Comment 12

[Phil Schwartau]

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.

Comment 13

[Phil Schwartau]

Note: for convenience, here is Boris' reduced testcase:

<script language="JavaScript1.1">

   function RedrawSched() {
       var MinBound;

       switch (i) {
         case MinBound :
       }
   } 
  
</script>

Comment 14

[Brendan Eich [:brendan]]

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

Comment 15

[Brendan Eich [:brendan]]

Attachment: patch to apply, not to review (see next for review)

This ought to fix all variations on the theme.

/be

Comment 16

[Brendan Eich [:brendan]]

Attachment: diff -wu of last patch

shaver, khanson, please review.

/be

Comment 17

[Brendan Eich [:brendan]]

Please help get this fix into 1.0.1 and 1.1beta.

/be

Comment 18

[Mike Shaver (:shaver emeritus)]

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.

Comment 19

[Brendan Eich [:brendan]]

Attachment: fix js.msg to match last patch

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 20

[Kenton Hanson (gone)]

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

r=khanson  changes look safe.

Comment 21

[Kenton Hanson (gone)]

Comment on attachment 90378 [details] [diff] [review]
fix js.msg to match last patch

r=khanson

Comment 22

[Phil Schwartau]

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 -

Comment 23

[Brendan Eich [:brendan]]

Fixed on trunk.  Going for branch approval.

/be

Comment 24

[chris hofmann]

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

a=chofmann for the 1.0.1 branch.

Comment 25

[greer]

Adding the talkback decorations so that we can track it as it drops of the top40
lists in the Trunk data.

Comment 26

[Brendan Eich [:brendan]]

Fixed in the branch, too.

/be

Comment 27

[greer]

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)

Comment 28

[Boris Zbarsky [:bzbarsky]]

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.  ;)

Comment 29

[Phil Schwartau]

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.