290575 - Crash when calling fn.toString (fn = function with more than 32768 arguments)

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect, P1)

Description

[Erik Fabert]

Not sure about the severity of this but it is an easy way to force a crash.

To reproduce:

1. Use Function() to build a function with more than 32768 (0x8000) arguments.
2. Call the function's toString method.
3. See crash.

Testcase follows.

Comment 1

[Erik Fabert]

Attachment: Testcase for shell or browser

Comment 2

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050416
Firefox/1.0+ Crashed for me

TBID TB5135224K

Comment 3

[jpl24]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414
Firefox/1.0.3

This immediately crashed, Talkback ID is TB5140468Z.

js_DecompileFunction 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsopcode.c,
line 2493]
JS_DecompileFunction 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsapi.c,
line 3508]
fun_toString 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsfun.c,
line 1422]
js_Invoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 949]
js_Interpret 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 2993]
js_Execute 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 1170]
JS_EvaluateUCScriptForPrincipals 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsapi.c,
line 3649]
nsJSContext::EvaluateString 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 946]
nsScriptLoader::EvaluateScript 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsScriptLoader.cpp,
line 668]
nsScriptLoader::ProcessRequest 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsScriptLoader.cpp,
line 581]
nsScriptLoader::ProcessScriptElement 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsScriptLoader.cpp,
line 527]
nsHTMLScriptElement::MaybeProcessScript 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/html/content/src/nsHTMLScriptElement.cpp,
line 656]
nsHTMLScriptElement::SetDocument 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/html/content/src/nsHTMLScriptElement.cpp,
line 469]
HTMLContentSink::ProcessSCRIPTTag 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/html/document/src/nsHTMLContentSink.cpp,
line 4341]
HTMLContentSink::AddLeaf 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/html/document/src/nsHTMLContentSink.cpp,
line 3195]
CNavDTD::AddLeaf 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/htmlparser/src/CNavDTD.cpp,
line 3787]
CNavDTD::HandleDefaultStartToken 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/htmlparser/src/CNavDTD.cpp,
line 1459]
CNavDTD::HandleStartToken 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/htmlparser/src/CNavDTD.cpp,
line 1835]
CNavDTD::HandleToken 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/htmlparser/src/CNavDTD.cpp,
line 1019]
CNavDTD::BuildModel 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/htmlparser/src/CNavDTD.cpp,
line 511]
nsParser::BuildModel 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/htmlparser/src/nsParser.cpp,
line 2004]

Comment 4

[Brendan Eich [:brendan]]

Attachment: fix

The patch in bug 155081 mentions this problem:

+ * XXXbe hey, who checks for fun->nvars and fun->nargs overflow?!

Shaver, please review this patch ASAP.

/be

Comment 5

[Brendan Eich [:brendan]]

Comment on attachment 180918 [details] [diff] [review]
fix

Oops, rushed past a warning in jsparse.c added by this patch.

/be

Comment 6

[Brendan Eich [:brendan]]

Attachment: fix

Comment 7

[Mike Shaver (:shaver emeritus)]

Comment on attachment 180919 [details] [diff] [review]
fix

Looks like a fix I was trying yesterday, before I was rudely dragged out to
enjoy the sunshine. r=shaver.

Comment 8

[Brendan Eich [:brendan]]

Fix in trunk.

/be

Comment 9

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED for me using the testcase
https://bugzilla.mozilla.org/attachment.cgi?id=180879 on Windows XP Seamonkey
trunk, build 2005-04-18-05.

Comment 10

[Bob Clary [:bc] (inactive)]

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

Comment 11

[Erik Fabert]

Attachment: modified testcase

There must be another bug still lurking here. This new testcase still crashes
with

Assertion failure: (uint16) sprop->shortid < nargs, at jsopcode.c:2660

Comment 12

[Bob Clary [:bc] (inactive)]

When viewing attachment 181136 [details] I hang in a sm trunk debug on winxpsp2 from last
night. Attaching and breaking execution gives:

NTDLL! 7c90eb94()
KERNEL32! 7c802542()
_PR_MD_WAIT_CV(_MDCVar * 0x002e856c, _MDLock * 0x002e845c, unsigned int 5597280)
line 280 + 20 bytes
_PR_WaitCondVar(PRThread * 0x002e86b0, PRCondVar * 0x002e84f8, PRLock *
0x002e8440, unsigned int 5597280) line 204 + 23 bytes
PR_WaitCondVar(PRCondVar * 0x002e84f8, unsigned int 5597280) line 551 + 23 bytes
MemoryFlusher::Run(MemoryFlusher * const 0x0096e3e8 sGlobalMemoryFlusher) line
414 + 19 bytes
nsThread::Main(void * 0x002e85b0) line 118 + 26 bytes
_PR_NativeRunThread(void * 0x002e86b0) line 436 + 13 bytes
pr_root(void * 0x002e86b0) line 116 + 13 bytes
_threadstartex(void * 0x002e8938) line 212 + 13 bytes
KERNEL32! 7c80b50b()

But when I edit the attachment I crash with:

NTDLL! 7c901230()
js_DecompileFunction(JSPrinter * 0x042e2280, JSFunction * 0x00b74260) line 2660
+ 36 bytes
JS_DecompileFunction(JSContext * 0x0362e930, JSFunction * 0x00b74260, unsigned
int 0) line 3598 + 13 bytes
js_fun_toString(JSContext * 0x0362e930, JSObject * 0x043c08a0, unsigned long 0,
unsigned int 0, long * 0x035e6684, long * 0x0012e460) line 1386 + 17 bytes
fun_toString(JSContext * 0x0362e930, JSObject * 0x043c08a0, unsigned int 0, long
* 0x035e6684, long * 0x0012e460) line 1396 + 27 bytes
js_Invoke(JSContext * 0x0362e930, unsigned int 0, unsigned int 0) line 1320 + 23
bytes
js_Interpret(JSContext * 0x0362e930, unsigned char * 0x035d48e5, long *
0x0012ee58) line 3599 + 15 bytes
js_Execute(JSContext * 0x0362e930, JSObject * 0x02c61fa0, JSScript * 0x03515cb0,
JSStackFrame * 0x00000000, unsigned int 0, long * 0x0012ef58) line 1550 + 19 bytes
JS_EvaluateUCScriptForPrincipals(JSContext * 0x0362e930, JSObject * 0x02c61fa0,
JSPrincipals * 0x02ae3674, const unsigned short * 0x01e879f8, unsigned int 155,
const char * 0x03634d88, unsigned int 1, long * 0x0012ef58) line 3739 + 25 bytes
nsJSContext::EvaluateString(const nsAString & {...}, void * 0x02c61fa0,
nsIPrincipal * 0x02ae3670, const char * 0x03634d88, unsigned int 1, const char *
0x00000000, nsAString * 0x00000000, int * 0x0012efbc) line 1035 + 67 bytes
nsScriptLoader::EvaluateScript(nsScriptLoadRequest * 0x01e87988, const nsString
& {...}) line 723
nsScriptLoader::ProcessRequest(nsScriptLoadRequest * 0x01e87988) line 629 + 22 bytes
nsScriptLoader::ProcessScriptElement(nsScriptLoader * const 0x01ee57d8,
nsIScriptElement * 0x035c89bc, nsIScriptLoaderObserver * 0x035c89b8) line 575 +
20 bytes
nsHTMLScriptElement::MaybeProcessScript() line 657 + 118 bytes
nsHTMLScriptElement::BindToTree(nsIDocument * 0x035b9d88, nsIContent *
0x01f0c5f0, nsIContent * 0x00000000, int 1) line 455
nsGenericElement::AppendChildTo(nsIContent * 0x035c8998, int 0) line 2704 + 23 bytes
HTMLContentSink::ProcessSCRIPTTag(const nsIParserNode & {...}) line 4173
HTMLContentSink::AddLeaf(HTMLContentSink * const 0x02a8a1d8, const nsIParserNode
& {...}) line 3053 + 15 bytes
CNavDTD::AddLeaf(const nsIParserNode * 0x035c13f8) line 3647 + 25 bytes
CNavDTD::HandleScriptToken(const nsIParserNode * 0x035c13f8) line 2209 + 12 bytes
CNavDTD::OpenContainer(const nsCParserNode * 0x035c13f8, nsHTMLTag
eHTMLTag_script, int 1, nsEntryStack * 0x00000000) line 3299 + 12 bytes
CNavDTD::HandleDefaultStartToken(CToken * 0x035c0cc0, nsHTMLTag eHTMLTag_script,
nsCParserNode * 0x035c13f8) line 1332 + 20 bytes
CNavDTD::HandleStartToken(CToken * 0x035c0cc0) line 1711 + 20 bytes
CNavDTD::HandleToken(CNavDTD * const 0x02d6fab0, CToken * 0x00000000, nsIParser
* 0x035d4a10) line 954 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x02d6fab0, nsIParser * 0x035d4a10,
nsITokenizer * 0x02d6fbd8, nsITokenObserver * 0x00000000, nsIContentSink *
0x02a8a1d8) line 461 + 20 bytes
nsParser::BuildModel(nsParser * const 0x035d4a10) line 2069 + 34 bytes
nsParser::ResumeParse(int 1, int 0, int 1) line 1936 + 12 bytes
nsParser::OnDataAvailable(nsParser * const 0x035d4a14, nsIRequest * 0x03634ed8,
nsISupports * 0x00000000, nsIInputStream * 0x02a51c38, unsigned int 0, unsigned
int 180) line 2616 + 21 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x03635918,
nsIRequest * 0x03634ed8, nsISupports * 0x00000000, nsIInputStream * 0x02a51c38,
unsigned int 0, unsigned int 180) line 349 + 46 bytes
nsStreamListenerTee::OnDataAvailable(nsStreamListenerTee * const 0x030aa6f8,
nsIRequest * 0x03634ed8, nsISupports * 0x00000000, nsIInputStream * 0x03636728,
unsigned int 0, unsigned int 180) line 97 + 51 bytes
nsHttpChannel::OnDataAvailable(nsIRequest * 0x03636998, nsISupports *
0x00000000, nsIInputStream * 0x03636728, unsigned int 0, unsigned int 180) line
3903 + 93 bytes
nsInputStreamPump::OnStateTransfer() line 437 + 70 bytes
nsInputStreamPump::OnInputStreamReady(nsInputStreamPump * const 0x0363699c,
nsIAsyncInputStream * 0x03636728) line 340 + 11 bytes
nsInputStreamReadyEvent::EventHandler(PLEvent * 0x03636a8c) line 120
PL_HandleEvent(PLEvent * 0x03636a8c) line 698 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00ad04f0) line 633 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00290238, unsigned int 49407, unsigned int 0,
long 11338992) line 1435 + 9 bytes
USER32! 77d48734()
USER32! 77d48816()
USER32! 77d489cd()
USER32! 77d48a10()
nsAppShell::Run(nsAppShell * const 0x01d57270) line 135
nsAppStartup::Run(nsAppStartup * const 0x01d56fd0) line 208
main1(int 1, char * * 0x002e2580, nsISupports * 0x00ad6f20) line 1268 + 32 bytes
main(int 1, char * * 0x002e2580) line 1752 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
K

Comment 13

[Bob Clary [:bc] (inactive)]

adding Erik's new testcase to regress-290575.js 

/cvsroot/mozilla/js/tests/js1_5/Regress/regress-290575.js,v  <--  regress-290575.js
new revision: 1.2; previous revision: 1.1

MSVCRT! 77c470de()
Function(JSContext * 0x00032e10, JSObject * 0x00773f68, unsigned int 32770, long
* 0x0077c44c, long * 0x0013e424) line 1710 + 169 bytes
js_Invoke(JSContext * 0x00032e10, unsigned int 32770, unsigned int 6) line 1320
+ 23 bytes
fun_apply(JSContext * 0x00032e10, JSObject * 0x00000000, unsigned int 32770,
long * 0x004250c4, long * 0x0013e57c) line 1546 + 15 bytes
js_Invoke(JSContext * 0x00032e10, unsigned int 2, unsigned int 0) line 1320 + 23
bytes
js_Interpret(JSContext * 0x00032e10, unsigned char * 0x00422176, long *
0x0013ee28) line 3599 + 15 bytes
js_Execute(JSContext * 0x00032e10, JSObject * 0x000387a8, JSScript * 0x0041e458,
JSStackFrame * 0x00000000, unsigned int 0, long * 0x0013fed0) line 1550 + 19 bytes
JS_ExecuteScript(JSContext * 0x00032e10, JSObject * 0x000387a8, JSScript *
0x0041e458, long * 0x0013fed0) line 3630 + 25 bytes
Process(JSContext * 0x00032e10, JSObject * 0x000387a8, char * 0x00032d5a) line
351 + 22 bytes
ProcessArgs(JSContext * 0x00032e10, JSObject * 0x000387a8, char * * 0x00032cc4,
int 6) line 550 + 23 bytes
main(int 6, char * * 0x00032cc4, char * * 0x00033240) line 2532 + 21 bytes
JS! mainCRTStartup + 227 bytes
KERNEL32! 7c816d4f()

Comment 14

[Brendan Eich [:brendan]]

Attachment: duh, forgot all about Function

Comment 15

[Brendan Eich [:brendan]]

Fixed for good.  Thanks for the testing back-up!

/be

Comment 16

[Bob Clary [:bc] (inactive)]

Brendan, did you run the test for this? I still crash with the same stack.

Comment 17

[Brendan Eich [:brendan]]

Yes, of course.  The fix clearly throws an error when the 65535'th argument is seen:

[~/src/phoenix/mozilla/js/src-e4x]$ Linux_All_DBG.OBJ/js < /tmp/crashMe2.html
7: SyntaxError: too many function arguments

Can you verify your build is valid?  If this was a browser crash like the one
shown in comment 12, that's unrelated.

/be

Comment 18

[Bob Clary [:bc] (inactive)]

(In reply to comment #17)
> 
> Can you verify your build is valid?  If this was a browser crash like the one
> shown in comment 12, that's unrelated.

I think so. I cvs update'd in the js/src dir, have 3.107 of jsfun.c, removed the
WINNT* dirs, rebuilt and still crash with the same stack as comment 13.

MSVCRT! 77c46fa3()
Function(JSContext * 0x00036e30, JSObject * 0x00a59158, unsigned int 2, long *
0x0041ec6c, long * 0x0013e57c) line 1710 + 169 bytes
js_Invoke(JSContext * 0x00036e30, unsigned int 2, unsigned int 0) line 1320 + 23
bytes
js_Interpret(JSContext * 0x00036e30, unsigned char * 0x0041eadf, long *
0x0013ee28) line 3599 + 15 bytes
js_Execute(JSContext * 0x00036e30, JSObject * 0x000383a8, JSScript * 0x0041eb58,
JSStackFrame * 0x00000000, unsigned int 0, long * 0x0013fed0) line 1550 + 19 bytes
JS_ExecuteScript(JSContext * 0x00036e30, JSObject * 0x000383a8, JSScript *
0x0041eb58, long * 0x0013fed0) line 3630 + 25 bytes
Process(JSContext * 0x00036e30, JSObject * 0x000383a8, char * 0x00000000) line
351 + 22 bytes
ProcessArgs(JSContext * 0x00036e30, JSObject * 0x000383a8, char * * 0x00032c3c,
int 0) line 573 + 17 bytes
main(int 0, char * * 0x00032c3c, char * * 0x00032fe8) line 2532 + 21 bytes
JS! mainCRTStartup + 227 bytes
KERNEL32! 7c816d4f()

Comment 19

[Stephen Donner [:stephend] Not actively reading bugmail]

The modified testcase at https://bugzilla.mozilla.org/attachment.cgi?id=181136
works for me now using a 2005-04-20-05 builds, whereas yesterday's 19 build
crashed.  I'll wait for Erik and Bob to weigh in before marking VERIFIED (or
they can do the honors).

Comment 20

[Bob Clary [:bc] (inactive)]

/cvsroot/mozilla/js/tests/js1_5/Regress/regress-290575.js,v  <--  regress-290575.js
new revision: 1.3; previous revision: 1.2

updated to account for SyntaxError in crashMe2(). 

I haven't crashed with today's ff/sm builds on winxpsp2. Am still waiting to
complete local builds for full shell coverage.

Comment 21

[Erik Fabert]

The JS shell I just build runs both testcases flawlessly and I couldn't find any
other loophole, so if you can't reproduce the problem you had yesterday please
mark this as verfied.

Comment 22

[Bob Clary [:bc] (inactive)]

I don't crash running crashMe2.html in today's nightlies, nor in my custom builds.

I don't crash when running regress-290575.js using the online version of the
test in today's nightlies nor my custom builds.

I do crash in crashMe2.html and js/tests/js1_5/Regress/regress-290575.js at the
same place when running in the shell in both OPT and DBG builds. I am building
with WinXPSP2, MSVC6/SP5/Processor Pack/Windows SDK Feb 2003 on a Xeon. I need help.

Comment 23

[Erik Fabert]

Maybe it's yet another compiler problem? I'm using Visual C++ Toolkit 2003 and
both debug and release shells work just fine. If you don't mind the 32MB
download it might be worth a try.

Comment 24

[Asa Dotzler [:asa]]

Comment on attachment 180919 [details] [diff] [review]
fix

1.0.5 and 1.7.8 have already shipped; removing approval requests.

Comment 25

[Bob Clary [:bc] (inactive)]

(In reply to comment #23)
> Maybe it's yet another compiler problem? I'm using Visual C++ Toolkit 2003 and
> both debug and release shells work just fine. If you don't mind the 32MB
> download it might be worth a try.

yeah, but we ship builds made with vc6. reopening. This still crashes on winxp on branch/trunk at least with 2005102209 builds.

Comment 26

[Brendan Eich [:brendan]]

I disown this bug, as I am not the guy to develop workarounds for VC6 bugs (if that is what's going wrong here).

/be

Comment 27

[Bob Clary [:bc] (inactive)]

I no longer see this crash in 1.8.0.1, 1.8, 1.9a1 on windows/linux but do in 1.7.12 20060207. marking wfm.

Comment 28

[Bob Clary [:bc] (inactive)]

(In reply to comment #27)
> I no longer see this crash in 1.8.0.1, 1.8, 1.9a1 on windows/linux but do in
> 1.7.12 20060207. marking wfm.
> 

note to self: the windows crashers on 1.8, 1.8.0.1 are back but ignorable re comment 26.