214761 - Loading page crashes when js.options.strict is true [@ MSVCRT.DLL ] [@ js_DecompileCode]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Olivier Cahagne]

build ID: 2003080104 on Win2k.

Steps to reproduce:
1. Load URL http://www.cisco.com/public/sw-center/
2. Mozilla crashes after loading ~ 1/3 of the page.

Has been happening for a week. I cleared the cache before doing tests.
I got stack viewing my reports (search for cisco.com) in:
http://ftp25moz.newaol.com/pub/data/crash-data/detailed-crash-analysis-all.html

I hope someone using a Windows debug build will come with a more interesting
stack. I couldn't get a Linux build to crash (debug or not).

Comment 1

[Matthias Versen [:Matti]]

doesn't crash for me with a cvs build from today on win2k

Comment 2

[Olivier Cahagne]

I don't crash with a new profile, I guess I have a corrupted profile.
I deleted XUL.mfl, history.dat/mab but it didn't help, any idea which other file
I could reset ?

Comment 3

[Mats Palmgren (inactive)]

If you have the time you could make a copy of your prefs.js and then start
removing lines from it.  It would be nice to know if there is a specific
pref that is causing this.

Comment 4

[Olivier Cahagne]

Mats, thanks ! I found the culprit, this particular pref crashes on URL above:
user_pref("javascript.options.strict", true);
I have no idea where it comes from, removing it prevent from crashing.

Comment 5

[Olivier Cahagne]

I remember enabling this pref (Debug -> Show strict JavaScript warnings) when
debugging something and forgot to set it back.
However, should it crash on particular JavaScript code anyway ? I'll try to
produce a reduced testcase if possible.

-> moving to JS Engine.

Comment 6

[Olivier Cahagne]

Attachment: Reduced testcase (only crashes with JavaScript strict warnings on)

Comment 7

[Olivier Cahagne]

Testcase has 24 lines, couldn't reduce more, I don't quite understand the logic
behind the crash as removing one of the testcase lines don't crash Mozilla
anymore. A stack will give more info. "JavaScript strict warnings" is probably
not supported and is expected to crash (?) but I thought I'd investigate to see
if there can a be a root cause involved in other issues.

Comment 8

[Matthias Versen [:Matti]]

Attachment: win2k stack trace

Is there a reason why you removed me from the cc List ?

Comment 9

[Olivier Cahagne]

I tested 1.4 (release) and 1.5a (release), both won't crash on testcase nor URL
(with the JavaScript strict warning pref set to true).
I think I started seeing this on July 25th (to debug bug 213842) so it'd show it
regressed between 07/17 and 07/25, will try to report with more builds.

Comment 10

[timeless]

i'm pretty sure this is brendan's he's the only active spidermonkey hacker.

Comment 11

[Phil Schwartau]

Compare bug 214210 comment 18, where another profile-dependant crash
has been reported -

Comment 12

[David Bradley]

When I run this, I hit the JS_ASSERT(top != 0) in PopOff. The code returns back
null, and the code in Decompile doesn't allow for a null return from POP_STR(),
line 1386.

Comment 13

[Olivier Cahagne]

indeed, fwiw, confirming crash on Linux:

Assertion failure: top != 0, at jsopcode.c:625
 
Program received signal SIGABRT, Aborted.
[Switching to Thread 16384 (LWP 27789)]
0x40520481 in kill () from /lib/i686/libc.so.6
Current language:  auto; currently c
(gdb) bt
#0  0x40520481 in kill () from /lib/i686/libc.so.6
#1  0x40129acd in pthread_kill () from /lib/i686/libpthread.so.0
#2  0x40129deb in raise () from /lib/i686/libpthread.so.0
#3  0x40520224 in raise () from /lib/i686/libc.so.6
#4  0x4052176b in abort () from /lib/i686/libc.so.6
#5  0x400ae733 in JS_Assert (s=0x400bbaa1 "top != 0",
    file=0x400bba3b "jsopcode.c", ln=625) at jsutil.c:150
#6  0x40084bea in PopOff (ss=0xbfffd750, op=JSOP_AND) at jsopcode.c:625
#7  0x40087088 in Decompile (ss=0xbfffd750, pc=0x8b24c05 "E", nb=9)
    at jsopcode.c:1386
#8  0x4008a3af in js_DecompileCode (jp=0x8a53c70, script=0x8b24b70,
    pc=0x8b24c05 "E", len=9) at jsopcode.c:2347
[...]

Comment 14

[Andrew Schultz]

this regressed betwen linux trunk 2003072605 and 2003072722, indicating bug
208030 as the culprit

Comment 15

[R.K.Aa.]

*** Bug 214210 has been marked as a duplicate of this bug. ***

Comment 16

[Phil Schwartau]

Reassigning this one to Brendan, in conformance with the duped bug 214210
and the related bug 208030, "JS errors report incorrect line numbers...".

Comment 17

[chris hofmann]

be is trying to fix for 1.5 beta.

Comment 18

[Brendan Eich [:brendan]]

Attachment: fix

I forgot to do one last thing in the long course of fixing bug 208030: re-base
the origin used by js_GetSrcNote to compute the pc-offset for a given note,
from the old origin of the script's main entry point (which prevented prolog
bytecodes from having notes) to the prolog entry point (script->code).	Augh!

Sorry for the trouble.	This is checked in.

/be

Comment 19

[Brendan Eich [:brendan]]

Fixed.

/be

Comment 20

[Phil Schwartau]

Using Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5b) Gecko/20030806.

I do not crash either on the given site or the reduced testcase.
I tried each one after toggling the setting for

  Edit > Preferences > Debug > "Show strict JavaScript warnings"

Marking Verified, although I will feel better if Olivier can confirm
this as well - thanks.

Comment 21

[Olivier Cahagne]

I do not crash either using 2003080605 (from mozilla.org) on Linux on both
testcase and URL (w/ and w/o JS strict warnings).

Comment 22

[Brendan Eich [:brendan]]

*** Bug 215878 has been marked as a duplicate of this bug. ***

Comment 23

[Bob Clary [:bc] (inactive)]

Checking in regress-214761.js;
/cvsroot/mozilla/js/tests/js1_5/Regress/regress-214761.js,v  <--  regress-214761.js
initial revision: 1.1
done