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)

x86
Linux
defect
Not set
critical

Tracking

()

VERIFIED WONTFIX

People

(Reporter: kherron+mozilla, Unassigned)

Details

(Keywords: crash)

Attachments

(1 file, 1 obsolete file)

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.
Attached file indexOf test case (obsolete) —
What version of mozilla ? This doens't crash for me on Linux with mozilla cvs
20040922
No problem for me too:
Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10
-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
Attached file Modified test case
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
(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().
-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.
ECMA-262 requires working IEEE-754 including non-finite values.  Verifying.

/be
Status: RESOLVED → VERIFIED
<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.

Attachment

General

Creator:
Created:
Updated:
Size: