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)
Tracking
()
RESOLVED
WORKSFORME
mozilla1.8beta2
People
(Reporter: jerfa, Unassigned)
Details
(Keywords: crash, js1.5, testcase)
Attachments
(4 files, 1 obsolete file)
271 bytes,
text/html
|
Details | |
8.79 KB,
patch
|
shaver
:
review+
brendan
:
approval1.8b2+
|
Details | Diff | Splinter Review |
180 bytes,
text/html
|
Details | |
1.96 KB,
patch
|
brendan
:
review+
brendan
:
approval1.8b2+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•19 years ago
|
||
Comment 2•19 years ago
|
||
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
Updated•19 years ago
|
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]
Updated•19 years ago
|
Comment 4•19 years ago
|
||
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 5•19 years ago
|
||
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?
Comment 6•19 years ago
|
||
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+
Comment 8•19 years ago
|
||
Fix in trunk. /be
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 9•19 years ago
|
||
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
Comment 10•19 years ago
|
||
Checking in regress-290575.js; /cvsroot/mozilla/js/tests/js1_5/Regress/regress-290575.js,v <-- regress-290575.js initial revision: 1.1
Reporter | ||
Comment 11•19 years ago
|
||
There must be another bug still lurking here. This new testcase still crashes with Assertion failure: (uint16) sprop->shortid < nargs, at jsopcode.c:2660
Reporter | ||
Updated•19 years ago
|
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 12•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
Attachment #181197 -
Flags: review+
Attachment #181197 -
Flags: approval1.8b2+
Comment 15•19 years ago
|
||
Fixed for good. Thanks for the testing back-up! /be
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
Comment 16•19 years ago
|
||
Brendan, did you run the test for this? I still crash with the same stack.
Comment 17•19 years ago
|
||
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•19 years ago
|
||
(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).
Comment 20•19 years ago
|
||
/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.
Reporter | ||
Comment 21•19 years ago
|
||
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•19 years ago
|
||
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.
Reporter | ||
Comment 23•19 years ago
|
||
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.
Updated•19 years ago
|
Flags: testcase+
Comment 24•19 years ago
|
||
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?
Comment 25•19 years ago
|
||
(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 → ---
Comment 26•19 years ago
|
||
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
Comment 27•18 years ago
|
||
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 ago → 18 years ago
Resolution: --- → WORKSFORME
Comment 28•18 years ago
|
||
(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.
Description
•