16318 - compiling xptcinvoke_unixish_x86.cpp with "-O -fexpensive-optimizations" breaks XPTC_InvokeByIndex

Status: VERIFIED DUPLICATE of bug 16612

(Core :: XPConnect, defect, P3)

Description

[Mikhail T.]

If the xpcom part is compiled by gcc295 with
"-O -fexpensive-optimizations", the programs
segfault at startup at the first call to SetAttributeFromJSVal,
which calls CallWrappedMethod which ends up calling
XPTC_InvokeByIndex.

The instruction pointer at the time of the fault is
totally wacked and the only way to narrow it down is
to put fprintf(stderr, "..) around the
	invokeResult = XPTC_InvokeByIndex(wrapper->GetNative(), vtblIndex,
                                      paramCount, dispatchParams);
in js/src/xpconnect/src/xpcwrappednativeclass.cpp .

Either the compiler errs compiling the assembly code
of the XPTC_InvokeByIndex() or the code makes some invalid
assumptions...

Recompiling the entire xpcom subtree with just `-g' results
in a runnable mozilla.

I tried this on FreeBSD-3.3-STABLE with the M9 and M10 releases
of the source code.

Comment 1

[Frank Mitchell]

This is more properly an XPConnect bug, since it occurs in Java*Script* code,
and since (I believe) XPConnect is responsible for xptcall as well.  [Of course,
if xptcall is broken than BlackConnect won't work either ...]

Comment 2

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Attachment: Tor's patch

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

The attached patch helps, but not much:
<cls>	shaver: no good.  I compiled that one file with -O (+TT's patch) and
apprunner crashes now (xpcshell seems to work fine)
#0  0x4 in ?? ()
#1  0x403966e0 in nsXPCWrappedNativeClass::CallWrappedMethod (this=0x8107030,
    cx=0x80aca80, wrapper=0x80cf2d0, desc=0x81070a0, callMode=CALL_GETTER,
	    argc=0, argv=0x0, vp=0xbfffe620)
    at /opt/cls/mozilla/js/src/xpconnect/src/xpcwrappednativeclass.cpp:791

Hrmph.

Comment 4

[John Bandhauer]

If the problem is that the c++ lines are getting optimized away then Tor's patch
seems to leave something that is just as likely to be optimzed away
too - they are is a no effect statements. Are there no gcc pragmas to disable
optimizations? The dang thing ought to know better than to optimize in a
function that contains inline asm.

Comment 5

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

*** This bug has been marked as a duplicate of 16612 ***

Comment 6

[Sebastian Späth]

VERIFY dupe