182159 - [gtk2] crash on startup when built by K2 compiler with switch -xO4

Status: VERIFIED INVALID

(Core :: JavaScript Engine, defect)

Description

[Simford]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021029 Phoenix/0.4
Build Identifier: Mozilla 1.2 branch 

When built with K2 compiler, mozilla 1.2 branch can not be launched.
When traced with tool -- truss, mozilla stoped at:
/1:         Incurred fault #6, FLTBOUNDS  %pc = 0xFE8A0F7C
/1:           siginfo: SIGSEGV SEGV_MAPERR addr=0x41124000
/1:         Received signal #11, SIGSEGV [caught]
/1:           siginfo: SIGSEGV SEGV_MAPERR addr=0x41124000
/1:     sigprocmask(SIG_SETMASK, 0xFFBFDC7C, 0x00000000) = 0 

Reproducible: Always

Steps to Reproduce:
In a Solaris 2.9/Sparc machine:

1. cvs checkout source code from mozilla.org

2. built with following env and switches:
ENV:
export CFLAGS="-xO4 -xlibmil"
export CXXFLAGS="-xO4 -xlibmil -xlibmopt"

SWITCHES:
./configure --enable-default-toolkit=gtk2 --disable-freetype2
--disable-freetypetest --disable-debug --disable-gtktest --disable-libIDLtest
--disable-glibtest --disable-tests --with-xprint --enable-xinerama --enable-ldap
--enable-x11-shm --disable-auto-deps --enable-crypto --enable-strip-libs

3. launch mozilla by ./mozilla

Actual Results:  
nothing happen

Expected Results:  
launch mozilla normally

Comment 1

[Simford]

After building mozilla more than hundred times with the same code, the same env
and switch, I found that it is the function js_ValueToNumber in file
mozilla/js/src/jsnum.c that stops the launch procedure.

After the first time mozilla called js_ValueToNumber, mozilla will always crash.
I found the at that time, the valuable v is an INT.
But when I omit the lines after "++", 
then mozilla will continue launch process without stop at js_ValueToNumber.

very strange, huh?

=============================================================
JSBool
js_ValueToNumber(JSContext *cx, jsval v, jsdouble *dp)
{
    JSObject *obj;
    JSString *str;
    const jschar *bp, *ep;

    if (JSVAL_IS_OBJECT(v)) {
        obj = JSVAL_TO_OBJECT(v);
        if (!obj) {
            *dp = 0;
            return JS_TRUE;
        }
++        if (!OBJ_DEFAULT_VALUE(cx, obj, JSTYPE_NUMBER, &v))
++            return JS_FALSE;
    }
    if (JSVAL_IS_INT(v)) {
        *dp = (jsdouble)JSVAL_TO_INT(v);
    } else if (JSVAL_IS_DOUBLE(v)) {
        *dp = *JSVAL_TO_DOUBLE(v);
    } else if (JSVAL_IS_STRING(v)) {
        str = JSVAL_TO_STRING(v);
        /*
         * Note that ECMA doesn't treat a string beginning with a '0' as an
         * octal number here.  This works because all such numbers will be
         * interpreted as decimal by js_strtod and will never get passed to
         * js_strtointeger (which would interpret them as octal).
         */
        /* XXXbe js_strtod shouldn't require NUL termination */
        bp = js_UndependString(cx, str);
        if (!bp)
            return JS_FALSE;
        if ((!js_strtod(cx, bp, &ep, dp) ||
++             js_SkipWhiteSpace(ep) != bp + str->length) &&
            (!js_strtointeger(cx, bp, &ep, 0, dp) ||
             js_SkipWhiteSpace(ep) != bp + str->length)) {
            goto badstr;
        }
    } else if (JSVAL_IS_BOOLEAN(v)) {
        *dp = JSVAL_TO_BOOLEAN(v) ? 1 : 0;
    } else {
#if JS_BUG_FALLIBLE_TONUM
        str = js_DecompileValueGenerator(cx, JSDVG_SEARCH_STACK, v, NULL);
badstr:
        if (str) {
            JS_ReportErrorNumber(cx, js_GetErrorMessage, NULL, JSMSG_NAN,
                                 JS_GetStringBytes(str));

        }
        return JS_FALSE;
#else
badstr:
++        *dp = *cx->runtime->jsNaN;
#endif
    } 
    return JS_TRUE;
}

Comment 2

[Sun's mozilla java team]

Does it happen for mozilla with gtk1.2?

Comment 3

[Bradley Baetz (:bbaetz)]

-> js engine

Comment 4

[Phil Schwartau]

cc'ing JS experts -

Comment 5

[Simford]

for comment #2:

I built two builds using gtk1.2.

ENV1:
setenv CFLAGS "-xO5 -xlibmil"
setenv CXXFLAGS "-xO5 -xlibmil -xlibmopt"
SWITCH1:
./configure --disable-freetype2 --disable-freetype-test --disable-debug --disabl
e-gtktest --disable-libIDLtest --disable-glibtest --disable-tests --with-xprint
--enable-xinerama --enable-ldap --enable-x11-shm --disable-auto-deps --enable-cr
ypto --enable-strip-libs   

ENV2:
setenv CFLAGS "-xO3 -xlibmil"
setenv CXXFLAGS "-xO3 -xlibmil -xlibmopt"
SWITCH2(the same with 1):
./configure --disable-freetype2 --disable-freetype-test --disable-debug --disabl
e-gtktest --disable-libIDLtest --disable-glibtest --disable-tests --with-xprint
--enable-xinerama --enable-ldap --enable-x11-shm --disable-auto-deps --enable-cr
ypto --enable-strip-libs   


result:
build1 crash at the same place as this bug mentioned.
build2 works fine.


Maybe it is a gtk2 independent bug.

Comment 6

[Simford]

Another information:
with -xO3, the gtk2 build also works fine.

Comment 7

[Simford]

from the link:
http://docs.sun.com/source/816-2454/cc_ops.app.html#pgfId-1001164

Optimizes the object code; note the uppercase letter O. When -xO is used with
the -g option, a limited amount of debugging is available. For more information,
see "Debugging Optimized Code" in Chapter 1 of Debugging a Program With dbx.

The levels (1, 2, 3, 4, or 5) you can use with -xO differ according to the
platform you are using.
(SPARC)

-xO1

Does basic local optimization (peephole).

-xO2

Does basic local and global optimization. This is induction variable
elimination, local and global common subexpression elimination, algebraic
simplification, copy propagation, constant propagation, loop-invariant
optimization, register allocation, basic block merging, tail recursion
elimination, dead code elimination, tail call elimination, and complex
expression expansion.

The -xO2 level does not assign global, external, or indirect references or
definitions to registers. It treats these references and definitions as if they
were declared volatile. In general, the -xO2 level results in minimum code size.

-xO3

Performs like -xO2, but also optimizes references or definitions for external
variables. Loop unrolling and software pipelining are also performed. This level
does not trace the effects of pointer assignments. When compiling either device
drivers, or programs that modify external variables from within signal handlers,
you may need to use the volatile type qualifier to protect the object from
optimization. In general, the -xO3 level results in increased code size.

-xO4

Performs like -xO3, but also automatically inlines functions contained in the
same file; this usually improves execution speed. If you want to control which
functions are inlined, see Section A.3.85, -xinline=list.

This level traces the effects of pointer assignments, and usually results in
increased code size.

-xO5

Attempts to generate the highest level of optimization. Uses optimization
algorithms that take more compilation time or that do not have as high a
certainty of improving execution time. Optimization at this level is more likely
to improve performance if it is done with profile feedback. See Section A.3.108,
-xprofile=p.

Comment 8

[timeless]

i'm not sure it'd help, but could you attach stack traces and the values of the
local/used variables for the successful function call and the crashing call?

to simplify things, try ./run-mozilla.sh ./xpcshell instead of ./mozilla

Comment 9

[Roland Mainz]

Just curious:
Does the problem go away when you compile the code in mozilla/js with
/opt/SUNWspro/bin/CC instead of /opt/SUNWspro/bin/cc ?

Comment 10

[Roland Mainz]

BTW: It's an very old story that some versions of Sun Workshop's compiler have
problems producing correct code for mozilla/js/ while no other compiler causes
similar problems. This looks like a compiler bug for me since the issue is
present in some versions with a certain patchlevel - and some other
compiler/patch-combinations do not have it.
Maybe someone with good knowledge of SPARC assembler code can look at the
difference between -xO3 and -xO4 of the generated code.

Comment 11

[Simford]

timeless:
Could you please give more details about how to get stack traces and values
through "./run-mozilla.sh ./xpcshell"?

The debug version of Mozilla works fine.
Only the release version with -xO4 or -xO5 crashes at startup.

Comment 12

[Simford]

Roland:

>Does the problem go away when you compile the code in mozilla/js with
>/opt/SUNWspro/bin/CC instead of /opt/SUNWspro/bin/cc ?

I have mentioned that.

The problem goes away when mozilla was built with low level optimize
switch(-xO1, -xO2 or -xO3)

Comment 13

[Simford]

Roland:

>Does the problem go away when you compile the code in mozilla/js with
>/opt/SUNWspro/bin/CC instead of /opt/SUNWspro/bin/cc ?

I have NOT mentioned that.

The problem goes away when mozilla was built with low level optimize
switch(-xO1, -xO2 or -xO3)

Comment 14

[timeless]

oh right, that'd help, the syntax is the same as for ./mozilla:

./run-mozilla.sh -g -d dbx ./xpcshell
-d dbx is optional, but it means: use dbx as my debugger instead of walking
through a list of possible debuggers (which includes ddd)

Comment 15

[Simford]

Attachment: stack traces of mozilla

timeless:
mozilla is a "k2, -xO5, gtk2.0" build

Comment 16

[Simford]

Attachment: stack traces of mozilla

timeless:
this is a trunk build with "k2, -xO4, gtk2".
does it help?

I am trying another debug build with trunk source code.
However, this bug will only appear in release -xO4/-xO5 build.
I am not sure whether the debug build would help.

Comment 17

[timeless]

ok, so we're moving along. you'll need to apply a few more patches from
http://bugzilla.mozilla.org/showdependencytree.cgi?id=181519 as you get stack
traces the crashes should match items in there -- this is partly a problem with
working off the 1.2 branch (my fixes never made it there) and partly my fault
for not commiting all of the fixes that are available.

applying attachment 106714 [details] [diff] [review] should get you past that one. i'm sorry that this
isn't as simple as just running the driver and hitting your real problem.
hopefully it will be in a few months.

Comment 18

[Simford]

Attachment: stack traces

timeless:
new output with the patch 106714.
note: this is a "k2, -xO4, gtk2, release" mozilla trunk build.

Comment 19

[Simford]

Attachment: where

Comment 20

[Simford]

Attachment: new output

timeless:
maybe this time it would help a bit.

build env:
export CFLAGS="-xO4 -xlibmil -g -xs"
export CXXFLAGS="-xO4 -xlibmil -xlibmopt -g -xs"

./configure --enable-default-toolkit=gtk2 --disable-freetype2
--disable-freetype
test --disable-debug --disable-gtktest --disable-libIDLtest --disable-glibtest
-
-disable-tests --with-xprint --enable-xinerama --enable-ldap --enable-x11-shm
--
disable-auto-deps --enable-crypto --enable-strip-libs


truss -f ./mozilla:
 .
 .
 .
15406/1:	    Incurred fault #6, FLTBOUNDS  %pc = 0xFE8A41A8
15406/1:	      siginfo: SIGSEGV SEGV_MAPERR addr=0x41124000
15406/1:	    Received signal #11, SIGSEGV [caught]
15406/1:	      siginfo: SIGSEGV SEGV_MAPERR addr=0x41124000
15406/1:	sigprocmask(SIG_SETMASK, 0xFFBFD75C, 0x00000000) = 0
15406/1:       
unlink("/export/browser/simford/.mozilla/default/37lbhisg.slt/lock") = 0
15406/1:	_exit(11)
15395:	waitid(P_PID, 15406, 0xFFBFF1F8, WEXITED|WTRAPPED|WNOWAIT) = 0
15395:	ioctl(0, TIOCGPGRP, 0xFFBFF1B4) 		= 0
15395:	ioctl(0, TCGETS, 0x000391D4)			= 0
15395:	waitid(P_PID, 15406, 0xFFBFF1F8, WEXITED|WTRAPPED) = 0
15395:	brk(0x0003DCA8) 				= 0
15395:	brk(0x0003DAA8) 				= 0
15395:	_exit(11)

Comment 21

[Roland Mainz]

Simford wrote:
> >Does the problem go away when you compile the code in mozilla/js with
> >/opt/SUNWspro/bin/CC instead of /opt/SUNWspro/bin/cc ?
> 
> I have NOT mentioned that.

Can you try whether this makes any difference ?

Comment 22

[Kyle Yuan]

Roland, CC works with -xO5

Comment 23

[Roland Mainz]

Kyle Yuan wrote:
> Roland, CC works with -xO5

?!
So the problem is only present with -xO4 and not with -xO5 or -xO3 builds ?!

Comment 24

[Roland Mainz]

OK, maybe I misunderstood kyle...

Kyle Yuan wrote:
> CC works with -xO5

So compiling the mozilla/js/-code with Sun Workshop's C++ compiler
(/opt/SUNWspro/bin/CC) with -xO5 works, compiling it with Sun Workshop's C
compiler (/opt/SUNWspro/bin/cc) causes a crash ?
If the answer is "yes" then the C compiler is likely on drugs(=buggy).

Is it possible to get a member of Sun's compiler team CC:'ed here (someone who
is willing :) to get some questions answered ?

Comment 25

[Kyle Yuan]

> So the problem is only present with -xO4 and not with -xO5 or -xO3 builds ?!

CC works with both -xO4 and -xO5.

I found the problem is in js_DoubleToECMAUint32, but if I moved this function to
another file, no crash again, even if using cc.

Seems K2 is buggy, we will not use it to do the future release.

Comment 26

[Roland Mainz]

Kyle Yuan wrote:
> I found the problem is in js_DoubleToECMAUint32, but if I moved this function 
> to another file, no crash again, even if using cc.

Sounds like simple code reodering (which triggers a differnent path in the
optimizer) or that you forced the compiler to avoid automatic inlining (which
gets enabled by default starting with -xO4).
Beyond that I can do only guessing... looking at the generated SPARC assember
code and do some comparisations is a pain... and getting the source of the
compiler is not possible (yeah, I wish I could get my claws on the source... but
I guess this will never happen in this life... ;-/) ...

> Seems K2 is buggy, we will not use it to do the future release.

IMHO it would be nice to get someone from the compiler team to look at the
issue. Maybe it's possible to create a quick patch for the compiler... :)

Comment 27

[Kyle Yuan]

This is not a mozilla bug, is a compiler bug that has been fixed in new K2 
build.

Comment 28

[Phil Schwartau]

Rubber-stamp vrfy. Simford: thank you for this report -

Comment 29

[Roland Mainz]

Kyle Yuan wrote:
> This is not a mozilla bug, is a compiler bug that has been fixed in new K2 
> build.

Can you post the SunSolve bugid and the compiler patch number that we can update
the Solaris build page, please?

Comment 30

[Kyle Yuan]

Roland, that was fixed in Sun's newest compiler named 'K2' build 27 which  is
not yet released officially. So there aren't any simple patches for it.

Comment 31

[Roland Mainz]

kyle.yuan wrote:
> that was fixed in Sun's newest compiler named 'K2' build 27 which  is
> not yet released officially. So there aren't any simple patches for it.

... are there any SunSolve bugids for reference (that people can spot the ids in
the patch readmes when they are released) ?

Comment 32

[Kyle Yuan]

It's not yet an official released product, so there is no SunSolve bugid for
this bug.