16612 - Native class use at startup fails

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P3)

Description

[Ulrich Drepper]

I'm still looking for the first time I can run Mozilla.  This is the latest bug
I come accross.  This is on Linux/x86 using a very recent (unreleased) compiler
with seems not to be the problem.  I've enabled optimization.  The sources are
coming directly from CVS with only the patch from #16402 applied I don't think
this makes a difference).

During startup of mozilla-apprunner the application crashes with the following
backtrace:

#0  0x0 in ?? ()
#1  0x405e5775 in nsXPCWrappedNativeClass::CallWrappedMethod (this=0x80d2fd0,
    cx=0x80c0540, wrapper=0x80d3270, desc=0x80d302c, callMode=CALL_GETTER,
    argc=0, argv=0x0, vp=0xbffff130) at ../../../../dist/include/xptinfo.h:116
#2  0x405e70a4 in WrappedNative_GetProperty (cx=0x80c0540, obj=0x80c26f0,
    id=135082296, vp=0xbffff130) at xpcwrappednativejsops.cpp:235
#3  0x40079293 in js_Interpret (cx=0x80c0540, result=0xbffff278)
    at jsinterp.c:2204
#4  0x400737cb in js_Execute (cx=0x80c0540, chain=0x80c2898, script=0x81379c0,
    fun=0x0, down=0x0, debugging=0, result=0xbffff278) at jsinterp.c:845
#5  0x40058e0e in JS_ExecuteScript (cx=0x80c0540, obj=0x80c2898,
    script=0x81379c0, rval=0xbffff278) at jsapi.c:2565
#6  0x406052df in mozJSComponentLoader::GlobalForLocation (this=0x80825d0,
    aLocation=0x8070e70 "rel:nsCategoryManager.js", component=0x8075f60)
    at mozJSComponentLoader.cpp:591
#7  0x406050c6 in mozJSComponentLoader::ModuleForLocation (this=0x80825d0,
    registryLocation=0x8070e70 "rel:nsCategoryManager.js", component=0x8075f60)
    at mozJSComponentLoader.cpp:499
#8  0x40604fad in mozJSComponentLoader::AutoRegisterComponent (this=0x80825d0,
    when=0, component=0x8075f60, registered=0xbffff358)
    at mozJSComponentLoader.cpp:456
#9  0x40604a0e in mozJSComponentLoader::RegisterComponentsInDir (
    this=0x80825d0, when=0, dir=0x80825b0) at mozJSComponentLoader.cpp:327
#10 0x40604683 in mozJSComponentLoader::AutoRegisterComponents (
    this=0x80825d0, when=0, aDirectory=0x80825b0)
    at mozJSComponentLoader.cpp:289
#11 0x4011c7e3 in AutoRegister_enumerate (key=0x8082608, aData=0x80825d0,
    aClosure=0xbffff4e8) at nsComponentManager.cpp:1980
#12 0x400f2db8 in _hashEnumerate (he=0x8072050, i=0, arg=0xbffff474)
    at nsHashtable.cpp:85
#13 0x40169554 in PL_HashTableEnumerateEntries (ht=0x8052878,
    f=0x400f2d90 <_hashEnumerate(PLHashEntry *, int, void *)>, arg=0xbffff474)
    at plhash.c:368
#14 0x400f3216 in nsHashtable::Enumerate (this=0x8052868,
    aEnumFunc=0x4011c790 <AutoRegister_enumerate(nsHashKey *, void *, void *)>,
closure=0xbffff4e8) at nsHashtable.cpp:214
#15 0x4011d094 in nsComponentManagerImpl::AutoRegister (this=0x8051e08,
    when=0, inDirSpec=0x0) at nsComponentManager.cpp:2059
#16 0x40122a99 in nsComponentManager::AutoRegister (when=0, directory=0x0)
    at nsRepository.cpp:196
#17 0x804b172 in NS_AutoregisterComponents () at nsSetupRegistry.cpp:94
#18 0x804c1f8 in NS_SetupRegistry_1 () at nsSetupRegistry.cpp:114
#19 0x804a531 in main1 (argc=1, argv=0xbffff7a4) at nsAppRunner.cpp:489
#20 0x804b03c in main (argc=1, argv=0xbffff7a4) at nsAppRunner.cpp:703

I can easily test patches if someone has any.

Comment 1

[Mike McCabe]

nsCategoryManager?

Mike, I'm guessing this is you.  CC'ing John, and leaving myself CC'ed.

Comment 2

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

Hey, Ulrich.  I'm rather pleased that you're the one reporting this bug, because
some of us have been chasing it for a while, and it appears to be either a
compiler bug or at the very least compiler-triggered.

Could you try rebuilding without optimization, at least in
xpcom/reflect/xptcall?  If this is the bug I think it is, then running
``xpcshell'' will crash with optimization, but start up and give you the 'js> '
prompt without.

http://bugzilla.mozilla.org/show_bug.cgi?id=16318 is the original bug, and I
just noticed that someone has provided a possible fix.  I don't have 2.95
installed currently, but I'll install it today.  I'll attach the patch to this
bug shortly.

(I'm virtually certain that this couldn't be a bug in nsCategoryManager.js, but
I'm glad it got misassigned anyway.)

Comment 3

[Ulrich Drepper]

Attachment: This is the first (and uglier) proposed patch. Rather consider the second.

Comment 4

[Ulrich Drepper]

Attachment: This is the second patch. Use either this (preferred) or the first patch.

Comment 5

[Ulrich Drepper]

Attachment: This is the patch for the second file containing asm code. THe problem is again missing stack correction.

Comment 6

[cls]

*** Bug 14805 has been marked as a duplicate of this bug. ***

Comment 7

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

*** Bug 16318 has been marked as a duplicate of this bug. ***

Comment 8

[Adam D. Moss]

I believe that this is fixed -- can it be marked
as such?

Comment 9

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

For you, Adam, anything.

(Thanks again, Ulrich.)

Comment 10

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

Comment on attachment 2262 [details] [diff] [review]
This is the second patch.  Use either this (preferred) or the first patch.

>+      "0" (fn_copy)         /* %3 */

Is there a reason this says %3 rather than %9?	(I'm looking at this code while
reviewing bug 297326.)

Comment 11

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

(Or maybe %0?)