155971 - gcc-3.1-7: startup crash in XPTC_InvokeByIndex

Status: VERIFIED DUPLICATE of bug 140412

(Core :: XPConnect, defect)

Description

[Brian Ryner (not reading)]

Sorry for dumping this on you, dbaron, but you probably have the best chance of
figuring out how to fix it...

On the new RedHat beta release (Limbo), I get a startup crash in XPConnect with
my debug build using gcc-3.1-7.  Here is the stack:

#0  0x402737d5 in XPTC_InvokeByIndex (that=0x80a42f0, methodIndex=1081708728,
    paramCount=1081594270, params=0x814e330)
    at
../../../../../../../xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:88
#1  0x407990b8 in __JCR_LIST__ ()
   from
/mnt/rh73/home/bryner/Source/mozilla/obj-gcc31-dbg/dist/bin/components/libxpconnect.so
#2  0x40788690 in XPCWrappedNative::GetAttribute(XPCCallContext&) (
    ccx=@0xbfffe3e0) at ../../../../../js/src/xpconnect/src/xpcprivate.h:1838
#3  0x407874e7 in XPC_WN_GetterSetter(JSContext*, JSObject*, unsigned, long*,
long*) (cx=0x81202a0, obj=0x8122048, argc=0, argv=0x82a5148, vp=0xbfffe580)
    at ../../../../../js/src/xpconnect/src/xpcwrappednativejsops.cpp:1298
#4  0x400c5943 in js_Invoke (cx=0x81202a0, argc=0, flags=2)
    at ../../../js/src/jsinterp.c:788
#5  0x400c5d3a in js_InternalInvoke (cx=0x81202a0, obj=0x8122048,
    fval=135409800, flags=0, argc=0, argv=0x0, rval=0xbfffeb34)
    at ../../../js/src/jsinterp.c:880
#6  0x400e739e in js_GetProperty (cx=0x81202a0, obj=0x8122048, id=135432272,
    vp=0xbfffeb34) at ../../../js/src/jsobj.c:2524
#7  0x400d1432 in js_Interpret (cx=0x81202a0, result=0xbfffece8)
    at ../../../js/src/jsinterp.c:2574
#8  0x400c60ec in js_Execute (cx=0x81202a0, chain=0x8121f78, script=0x81356c8,
    down=0x0, special=0, result=0xbfffece8) at ../../../js/src/jsinterp.c:968
#9  0x400963ff in JS_ExecuteScript (cx=0x81202a0, obj=0x8121f78,
    script=0x81356c8, rval=0xbfffece8) at ../../../js/src/jsapi.c:3274
#10 0x407ac9b6 in mozJSComponentLoader::GlobalForLocation(char const*, nsIFile*)
(this=0x80ad248, aLocation=0x80ad4b0 "rel:nsProxyAutoConfig.js",
    component=0x80ad2b8)
    at ../../../../../js/src/xpconnect/loader/mozJSComponentLoader.cpp:1132
#11 0x407abd6f in mozJSComponentLoader::ModuleForLocation(char const*, nsIFile*)
(this=0x80ad248, registryLocation=0x80ad4b0 "rel:nsProxyAutoConfig.js",
    component=0x80ad2b8)
    at ../../../../../js/src/xpconnect/loader/mozJSComponentLoader.cpp:926
#12 0x407ab531 in mozJSComponentLoader::AttemptRegistration(nsIFile*, int) (
    this=0x80ad248, component=0x80ad2b8, deferred=0)
    at ../../../../../js/src/xpconnect/loader/mozJSComponentLoader.cpp:762
#13 0x407ab214 in mozJSComponentLoader::AutoRegisterComponent(int, nsIFile*,
int*) (this=0x80ad248, when=0, component=0x80ad2b8, registered=0xbffff0e4)
    at ../../../../../js/src/xpconnect/loader/mozJSComponentLoader.cpp:688
#14 0x407aaea3 in mozJSComponentLoader::RegisterComponentsInDir(int, nsIFile*)
    (this=0x80ad248, when=0, dir=0x80c8518)
    at ../../../../../js/src/xpconnect/loader/mozJSComponentLoader.cpp:594
#15 0x407aacba in mozJSComponentLoader::AutoRegisterComponents(int, nsIFile*) (
   this=0x80ad248, when=0, aDirectory=0x80c8518)
    at ../../../../../js/src/xpconnect/loader/mozJSComponentLoader.cpp:550
#16 0x40236259 in nsComponentManagerImpl::AutoRegisterImpl(int, nsIFile*, int)
    (this=0x80a5370, when=0, inDirSpec=0x0, fileIsCompDir=1)
    at ../../../xpcom/components/nsComponentManager.cpp:3084
#17 0x40235a4d in nsComponentManagerImpl::AutoRegister(int, nsIFile*) (
    this=0x80a5370, when=0, inDirSpec=0x0)
    at ../../../xpcom/components/nsComponentManager.cpp:2984
#18 0x4023a025 in nsComponentManager::AutoRegister(int, nsIFile*) (when=0,
    directory=0x0)
    at ../../../xpcom/components/nsComponentManagerObsolete.cpp:221
#19 0x0805cd66 in main1 (argc=1, argv=0xbffff554, nativeApp=0x809f840)
    at ../../../xpfe/bootstrap/nsAppRunner.cpp:1358
#20 0x0805e429 in main (argc=1, argv=0xbffff554)
    at ../../../xpfe/bootstrap/nsAppRunner.cpp:1864
#21 0x420165c4 in __libc_start_main () from /lib/i686/libc.so.6

I'll attach a disassembly of the function.

Comment 1

[Brian Ryner (not reading)]

Attachment: function disassembly

Comment 2

[Brian Ryner (not reading)]

Attachment: register dump

Comment 3

[Brian Ryner (not reading)]

The method index and param count look pretty bogus.

Comment 4

[Brian Ryner (not reading)]

... but they're fine on entry to the function.  Do we normally overwrite that
data on the stack?  It looks like that is happening when we hit the "push" ops
at 0x402737bf.

Comment 5

[Christopher Blizzard (:blizzard)]

dup of 140412?  (Try the patch there.)

Comment 6

[Brian Ryner (not reading)]

Yes, that worked nicely.  That was _so_ not obvious from the summary of 140412.

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

Comment 7

[Phil Schwartau]

Marking Verified -

Comment 8

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Isn't -fno-omit-frame-pointer a workaround for this (since it was now made the
default, but our xptcall code assumed it was not specified)?

Comment 9

[Christopher Blizzard (:blizzard)]

The opinion of those who do a lot of asm() within red hat was that our original
code was fundamentally broken.  Apparently, you can make no assumptions about
stack layout before calling into an inline asm() statement.  If you want to do
what we are doing, you need to use pure asm.

Comment 10

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Well, we're not exactly trying to be portable.  We either need to make
assumptions about name mangling or about stack layout -- all that patch really
does is switch which evil assumptions we're making.