Closed Bug 290575 Opened 19 years ago Closed 18 years ago

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

Categories

(Core :: JavaScript Engine, defect, P1)

x86
Windows XP
defect

Tracking

()

RESOLVED WORKSFORME
mozilla1.8beta2

People

(Reporter: jerfa, Unassigned)

Details

(Keywords: crash, js1.5, testcase)

Attachments

(4 files, 1 obsolete file)

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.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050416
Firefox/1.0+ Crashed for me

TBID TB5135224K
Keywords: testcase
Severity: major → critical
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]
Assignee: general → brendan
Keywords: js1.5
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta2
Attached patch fix (obsolete) — Splinter Review
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
Attachment #180918 - Flags: review?(shaver)
Attachment #180918 - Flags: approval1.8b2+
Attachment #180918 - Flags: approval1.7.8?
Attachment #180918 - Flags: approval-aviary1.0.4?
Comment on attachment 180918 [details] [diff] [review]
fix

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

/be
Attachment #180918 - Attachment is obsolete: true
Attachment #180918 - Flags: review?(shaver)
Attachment #180918 - Flags: approval1.8b2+
Attachment #180918 - Flags: approval1.7.8?
Attachment #180918 - Flags: approval-aviary1.0.4?
Attached patch fixSplinter Review
Attachment #180919 - Flags: review?(shaver)
Attachment #180919 - Flags: approval1.8b2+
Attachment #180919 - Flags: approval1.7.8?
Attachment #180919 - Flags: approval-aviary1.0.4?
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.
Attachment #180919 - Flags: review?(shaver) → review+
Fix in trunk.

/be
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
Checking in regress-290575.js;
/cvsroot/mozilla/js/tests/js1_5/Regress/regress-290575.js,v  <--  regress-290575.js
initial revision: 1.1
Attached file 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
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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
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()
Attachment #181197 - Flags: review+
Attachment #181197 - Flags: approval1.8b2+
Fixed for good.  Thanks for the testing back-up!

/be
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
Brendan, did you run the test for this? I still crash with the same stack.
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
(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()
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).
/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.
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.
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.
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.
Flags: testcase+
Comment on attachment 180919 [details] [diff] [review]
fix

1.0.5 and 1.7.8 have already shipped; removing approval requests.
Attachment #180919 - Flags: approval1.7.8?
Attachment #180919 - Flags: approval-aviary1.0.5?
(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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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
Assignee: brendan → general
Status: REOPENED → NEW
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.
Status: NEW → RESOLVED
Closed: 19 years ago18 years ago
Resolution: --- → WORKSFORME
(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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: