Closed
Bug 261618
Opened 20 years ago
Closed 20 years ago
Crash in str_indexOf() if indexOf() second arg isn't a number
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
VERIFIED
WONTFIX
People
(Reporter: kherron+mozilla, Unassigned)
Details
(Keywords: crash)
Attachments
(1 file, 1 obsolete file)
93 bytes,
text/html
|
Details |
In the two-argument form of string.indexOf(), if the second argument is a non-numeric string then mozilla can crash. It appears that, inside str_index() (in js/src/jsstr.c), the string is parsed into a floating-point number, which yields NaN; this is converted to 0xFFFFFFFF and used as the starting point for the search operation. A trivial test case is as follows: html> <body> <script> var foo = 'foo'.indexOf('bar', '='); </script> </body> </html> This yields a crash with the backtrace: (gdb) bt 15 #0 0x407e6006 in nanosleep () from /lib/i686/libc.so.6 #1 0xffffffa0 in ?? () #2 0x407e5e37 in sleep () from /lib/i686/libc.so.6 #3 0x0806d38e in ah_crap_handler (signum=1082554784) at /extra/kherron/moz/mozilla/xpfe/bootstrap/nsSigHandlers.cpp:133 #4 0x41c5d20c in nsProfileLock::FatalSignalHandler (signo=11) at /extra/kherron/moz/mozilla/profile/dirserviceprovider/src/nsProfileLock.cpp:208 #5 0x4011c4ec in __pthread_clock_settime () from /lib/i686/libpthread.so.0 #6 <signal handler called> #7 0x400a04f7 in str_indexOf (cx=0x8779cd0, obj=0x8823bd0, argc=2, argv=0x8825ed0, rval=0xbfffdc90) at /extra/kherron/moz/mozilla/js/src/jsstr.c:988 #8 0x40058fd3 in js_Invoke (cx=0x8779cd0, argc=2, flags=0) at /extra/kherron/moz/mozilla/js/src/jsinterp.c:1280 #9 0x4005dbc9 in js_Interpret (cx=0x8779cd0, result=0xbfffe020) at /extra/kherron/moz/mozilla/js/src/jsinterp.c:3372 #10 0x40057e85 in js_Execute (cx=0x8779cd0, chain=0x8627b58, script=0x8823a80, down=0x0, flags=0, result=0xbfffe0d8) at /extra/kherron/moz/mozilla/js/src/jsinterp.c:1509 #11 0x40029d9e in JS_EvaluateUCScriptForPrincipals (cx=0x8779cd0, obj=0x8627b58, principals=0x8823bd0, chars=0x8823bd0, length=142752720, filename=0x8823bd0 "f", lineno=142752720, rval=0x8823bd0) at /extra/kherron/moz/mozilla/js/src/jsapi.c:3662 #12 0x41840b14 in nsJSContext::EvaluateString (this=0x8779c18, aScript=@0xbfffe290, aScopeObject=0x8627b58, aPrincipal=0xbfffe0f0, aURL=0x80005218 <Address 0x80005218 out of bounds>, aLineNo=2147504664, aVersion=0x0, aRetValue=0x0, aIsUndefined=0xbfffe1bc) at /extra/kherron/moz/mozilla/dom/src/base/nsJSEnvironment.cpp:988 #13 0x41672f90 in nsScriptLoader::EvaluateScript (this=0xbfffe290, aRequest=0x8823a48, aScript=@0x80005218) at /extra/kherron/moz/mozilla/content/base/src/nsScriptLoader.cpp:669 #14 0x41672b8a in nsScriptLoader::ProcessRequest (this=0x8437ed0, aRequest=0x8823a48) at /extra/kherron/moz/mozilla/content/base/src/nsScriptLoader.cpp:586 (More stack frames follow...) I originally encountered this on a public website, but it's not a site I want to admit reading :-) I can reproduce it with current trunk builds of mozilla and an aviary 1.0 branch build of firefox from today. I think the crashes began after I recently changed the gcc optimization switches that I use from "-Os -march=athlon" to "-O3 -ffast-math -march=athlon". -ffast-math affects floating-point operations so it may be relevant.
Reporter | ||
Comment 1•20 years ago
|
||
What version of mozilla ? This doens't crash for me on Linux with mozilla cvs 20040922
Comment 3•20 years ago
|
||
No problem for me too: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10
Comment 4•20 years ago
|
||
-ffast-math is known to do bogus optimizations and I don't believe there is any interest in making it work. Brendan?
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 5•20 years ago
|
||
This version prints the return value from the indexOf() call. With a copy of mozilla compiled without gcc's -ffast-math option, it consistently prints -1. In my copy of mozilla compiled with -ffast-math, it consistently prints random positive numbers or else crashes. The second arg to indexOf() is handled at at jsstr.c beginning at line 961; see <http://lxr.mozilla.org/seamonkey/source/js/src/jsstr.c#961>. It seems that for a non-numeric string, js_ValueToNumber() is setting d to NaN and returning true. The following call to js_DoubleToInteger() returns 0 for mozilla without -ffast-math, or NaN for mozilla with -ffast-math. In the latter case, the line "i = (jsint)d;" executes and sets i to 0x80000000, or -2^31. This causes the actual search for the substring to iterate over memory outside the source string. It will return a value or crash depending on whether it finds a copy of the search string or not. So the real question seems to be why js_DoubleToInteger() is returning NaN in one case and 0 in the other. This function is in jsnum.c <http://lxr.mozilla.org/seamonkey/source/js/src/jsnum.c#886>, and it contains an explicit NaN test. However, with the -ffast-math version of mozilla, the initial (d == 0) test is succeeding when d is NaN. So this could be a compiler bug.
Attachment #160126 -
Attachment is obsolete: true
Reporter | ||
Comment 6•20 years ago
|
||
(In reply to comment #4) > -ffast-math is known to do bogus optimizations and I don't believe there is any > interest in making it work. Brendan? That's a pity. -ffast-math breaks strict IEEE compliance, but I think "bogus" is overstating it a bit. I haven't tried to benchmark mozilla, but the option can provide a nice performance improvement; see <http://home.comcast.net/~jcunningham63/linux/GCC_Optimization.html> for example. Mozilla seems to run normally other than this issue, and it looks like the issue could be "fixed" by reordering the tests in js_DoubleToInteger().
Comment 7•20 years ago
|
||
-ffast-math enables, among a bunch of other things, -ffinite-math-only, a mode in which nan and infinity aren't supported. The nan == 0.0 result is intentional when you do this.
Comment 8•20 years ago
|
||
ECMA-262 requires working IEEE-754 including non-finite values. Verifying. /be
Status: RESOLVED → VERIFIED
Comment 9•20 years ago
|
||
<rant> I'm tired of GCC's lameness -- instead of bugging JS to use -fbroken-fast-math, why not file a bug against GCC? It still produces significantly fatter, slower code than MSVC, even with the tree-ssa branch. The combination of GCC and ELF lameness (PIC bloat, visibility on by default, no dllimport/export way to optimize intra-library calls) is holding back Linux, although fixing that won't fix the nine other big problems holding back Linux. </rant> /be
You need to log in
before you can comment on or make changes to this bug.
Description
•