Closed
Bug 122076
Opened 23 years ago
Closed 21 years ago
RegExp crash when following link
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: kleist, Assigned: rogerl)
References
()
Details
(Keywords: crash, Whiteboard: [QA Note: verify any fix interactively + verify bug 138326], talkback)
Attachments
(3 files)
Build ID: 2002 01 24 03. Windows 2000. The first crash (TB2168531Y) occurred when I clicked the link "About us" on < http://www.marzie.com/ >. The other one (TB2168574Y) occurred when I had clicked on the same link, and the clicked the button "Go back one page". The bug is intermittent, it seems.
Reporter | ||
Comment 1•23 years ago
|
||
Sorry, I forgot to set severity "critical"
Severity: normal → critical
Keywords: crash
Comment 3•23 years ago
|
||
Just CVSup'ed tree about an hour ago and rebuilt on FreeBSD. Same problem here. Seems to be platform independent.
Comment 4•23 years ago
|
||
WFM 2002012503/WinNT4
Comment 5•23 years ago
|
||
WFM 2002012608/WinXP
Comment 6•23 years ago
|
||
WFM, 2002012606/Linux
Comment 7•23 years ago
|
||
WFM 2002012605-0.9.8/WinNT4.
Comment 8•23 years ago
|
||
Today's CVS pull and build (20020128) for FreeBSD works fine.
Comment 9•23 years ago
|
||
This crashes me with 021108 mozilla win32 build on win2K. Will try to get a stack trace when talkback comes up.
Whiteboard: talkback
Comment 10•23 years ago
|
||
->JavaScript Engine. ParseAtom() ParseQuantAtom() ParseItem() ParseAltern() ParseRegExp() ParseAtom() ParseQuantAtom() ParseItem() ParseAltern() ParseRegExp() ParseAtom() ParseQuantAtom() ParseItem() ParseAltern() ParseRegExp() ParseAtom() ParseQuantAtom() ParseItem() ParseAltern() ParseRegExp() js_NewRegExp() js_NewRegExpObject() js_GetToken() js_MatchToken() ArgumentList() MemberExpr() UnaryExpr() MulExpr() AddExpr() ShiftExpr() RelExpr() EqExpr() BitAndExpr() BitXorExpr() BitOrExpr() AndExpr() OrExpr() CondExpr() AssignExpr() Expr() PrimaryExpr() MemberExpr() UnaryExpr() MulExpr() AddExpr() ShiftExpr() RelExpr() EqExpr() BitAndExpr() BitXorExpr() BitOrExpr() AndExpr() OrExpr() CondExpr() AssignExpr() Expr() Statement() Statements() FunctionBody() FunctionDef() FunctionStmt() Statement() Statements() js_CompileTokenStream() CompileTokenStream() JS_CompileUCScriptForPrincipals() JS_EvaluateUCScriptForPrincipals() nsJSContext::EvaluateString() nsScriptLoader::EvaluateScript() nsScriptLoader::ProcessRequest() nsScriptLoader::OnStreamComplete() nsStreamLoader::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 + 0xec10 (0x40367c10) libglib-1.2.so.0 + 0x102d9 (0x403692d9) libglib-1.2.so.0 + 0x108e3 (0x403698e3) libglib-1.2.so.0 + 0x10a7c (0x40369a7c) libgtk-1.2.so.0 + 0x8dd97 (0x4028cd97) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x18a42 (0x40466a42)
Assignee: asa → rogerl
Status: UNCONFIRMED → NEW
Component: Browser-General → JavaScript Engine
Ever confirmed: true
QA Contact: doronr → pschwartau
Comment 11•23 years ago
|
||
I got a crash when I loaded the site for the first time; that's it! Same thing with my Linux build (both dated 2002-02-07). OS: Win ---> All. Will attach WinNT stack trace below. It looks the same as Asa's. Since this looks like it might be a RegExp crash, leaving assigned to rogerl.
OS: Windows 2000 → All
Comment 12•23 years ago
|
||
Comment 13•23 years ago
|
||
Note: the crash does seem to be intermittent. One must be ready to debug it the first time one loads the site; it may not crash again so easily -
Comment 14•23 years ago
|
||
The regular expressions are in the external file view-source:http://www.marzie.com/include/scripts.js Roger noted the problem seems to center on this one: function checkURL () { return (this.value.search(/^(((https?)|(ftp)):\/\/([\-\w]+\.)+\w{2,4}(\/[%\-\w]+(\.\w{2 ,})?)*(([\w\-\.\?\\/\*\$+@&#;`~=%!]*)(\.\w{2,})?)*\/?)$/) != -1); }
Comment 15•23 years ago
|
||
Wow, I was able to load the site without crashing, and found this error in the JS Console: Error: unterminated parenthetical ( Source File: http://www.marzie.com/include/scripts.js Line: 78, Column: 27 Source Code: return (this.value.search(/^(((https?)|(ftp)):\/\/([\-\w]+\.)+\w{2,4}(\/[%\-\w]+(\.\w{2 ,})?)*(([\w\-\.\?\\/\*\$+@&#;`~=%!]*)(\.\w{2,})?)*\/?)$/) != -1);
Comment 16•23 years ago
|
||
I have put the function checkURL() into a standalone JS shell testcase. It crashes my JS shell, but intermittently. The test driver alone will not be enough to verify the fix. We'll have to verify interactively, by loading the testcase over and over by hand in the JS shell. And also, of course, by loading the above website repeatedly. In the meantime, I will attach the testcase to this bug before checking it into CVS; I'm not sure yet if this should be a "negative" test or a "positive" test. That is, does checkURL() really contain a syntax error, and JS should fail to compile it? Here is what NN4.7 says in its JS Console when we load the website: JavaScript Error: unterminated character class [ I think I see the error. What looks funny to me is this: / etc. etc. [\w\-\.\?\\/ etc. etc. / I say, the \\/ is escaping the backslash so that it is a literal and no longer functions as a backslash. Therefore the / which follows is unescaped, and terminates the parse of the regular expression. Since the character class beginning with [ has not closed yet, we get the error. Anyway, that's my theory. But why does IE6 load the site without an error? See bug 101070, an Evangelism bug against Microsoft: "microsoft.com - Using "/" character unescaped in RegExp literals is non-ECMA"
Whiteboard: talkback → [QA Note: verify any fix interactively], talkback
Comment 17•23 years ago
|
||
Comment 18•22 years ago
|
||
I'll add to it. Just had another crash whilst visiting http://www.statsman.org/genomestats/5.html ... I always find this page loading slower in Mozilla than in IE, but sometimes I have it crashing totally in this page (intermittent). No crash ID, as Mozilla won't quit on it's own. It will just halt, and when CAD'ing out, I'm left with a desktop consisting of white icons, and every icon I go over with the mouse goes white, system tray will vanish, me needing to reboot. Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.8+) Gecko/20020226 WinME
Comment 19•22 years ago
|
||
missed something: am using Java Plug-in 1.3.1 for Netscape Navigator (DLL Helper) NPOJI600.dll NPJava11.dll NPJava12.dll NPJava131.dll NPJava32.dll
Comment 20•22 years ago
|
||
Jorden: thanks, but that looks like a completely different crash. The one in this report is due to a RegExp crash in the JavaScript Engine; yours looks like a Java problem. Could you file a separate bug on that? (To the Plug-ins component). Please cc me on it, too: pschwartau@netscape.com. Thanks -
Comment 21•22 years ago
|
||
Testcase added to JS testsuite: mozilla/js/tests/ecma_3/RegExp/regress-122076.js However, it does not crash when I run it under the test driver. See my Comment #16 above; the only way I will be able to verify any fix for this bug is to start the JS shell and load() the testcase attached in Comment #17. It's one of those peculiar crashes that requires just the right combination of circumstances to occur...
Comment 22•22 years ago
|
||
Adding "RegExp" to the summary to make this bug more easily searched -
Summary: crash when following link → RegExp crash when following link
Comment 23•22 years ago
|
||
*** Bug 138326 has been marked as a duplicate of this bug. ***
Comment 24•22 years ago
|
||
cc'ing Matti from bug 138326; noting we must verify that site as well as this bug's site once the fix goes in -
Whiteboard: [QA Note: verify any fix interactively], talkback → [QA Note: verify any fix interactively + verify bug 138326], talkback
Comment 25•22 years ago
|
||
Is anyone working on fixing this bug? This bug is one of the few problems remaining that prevents me from using Mozilla full time without switching back to IE6.
Comment 26•22 years ago
|
||
Our RegExp owner is away on sabbatical; that accounts for the delay. Sorry for the inconvenience - he's back on June 1.
Comment 27•22 years ago
|
||
Ok that's understandable. I can live with this until then. Thanks for replying.
Assignee | ||
Comment 28•22 years ago
|
||
Nuts, I think I created this when fixing 98306. The '[' parsing loop is trying to protect itself from running off the end of the regexp but is actually looking too far ahead by comparing cp+1 against cpend - cp has already been incremented at this point. {Phil, I can't think of any better way of testing this, the trouble is that the parse loop is going to keep marching through memory until a read fails because it's an invalid address or it accidentally encounters a ']' - there's no telling which will happen first. But note that running under Purify catches the bad read}
Comment 29•22 years ago
|
||
cc'ing reviewers for this patch -
Comment 30•21 years ago
|
||
Comment on attachment 85605 [details] [diff] [review] Prevent over-reaching for end check ok, i ran this test using valgrind on boffo and the current codebase results in ==12179== Invalid read of size 2 ==12179== at 0x402CA854: ParseAtom (/mnt/ibm/mozhack/mozilla/js/src/jsregexp.c:916) ==12179== by 0x402CA0C7: ParseQuantAtom (/mnt/ibm/mozhack/mozilla/js/src/jsregexp.c:655) ... ==12179== Address 0x4167ED88 is 0 bytes after a block of size 160 alloc'd ==12179== at 0x40046D2B: malloc (vg_clientfuncs.c:100) ==12179== by 0x40255237: JS_malloc (/mnt/ibm/mozhack/mozilla/js/src/jsapi.c:1424) ==12179== by 0x402E4597: js_NewStringCopyN (/mnt/ibm/mozhack/mozilla/js/src/jsstr.c:2550) ==12179== by 0x402D1CBE: js_NewRegExpObject (/mnt/ibm/mozhack/mozilla/js/src/jsregexp.c:2835) With this patch I don't get the invalid read and I do get the correct error. If I were a peer i'd mark r+. After a bit of reading i even understand why this is correct :) Phil, you should probably be able to build a testdriver which integrates valgrind, ./run-mozilla.sh /usr/local/bin/valgrind --logfile-fd=3 ./xpcshell jstest 3> valgrind.logfile grep "Invalid read" valgrind.logfile ==12234== definitely lost: 60 bytes in 3 blocks. fwiw is bug 188206
Comment 31•21 years ago
|
||
Comment on attachment 85605 [details] [diff] [review] Prevent over-reaching for end check Please get this in for 1.4a. /be
Attachment #85605 -
Flags: review+
Assignee | ||
Comment 32•21 years ago
|
||
checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 33•21 years ago
|
||
Verified FIXED. By using source from 2003-03-18, I was able to reproduce the crash in the debug and optimized JS shell by loading the standalone JS testcase from Comment #17 over and over. I was also able to reproduce the crash in a 2003-03-18 Mozilla trunk build by loading the HTML testcase from bug 138326 comment 10 over and over. Reproduced on WinNT and Linux. Using today's source and today's Mozilla trunk build, I am unable to reproduce the crash on WinNT or Linux with either testcase, no matter how many times I load them. Instead, I correctly get the same error as in Nav4 (see Comment #16): Error: unterminated character class [
Status: RESOLVED → VERIFIED
Updated•19 years ago
|
Flags: testcase+
You need to log in
before you can comment on or make changes to this bug.
Description
•