Closed Bug 18172 Opened 25 years ago Closed 25 years ago

nsCategoryManager.js:27 TypeError: Components.interfaces has no properties

Categories

(Core :: XPConnect, defect, P3)

x86
FreeBSD
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: marauder, Assigned: shaver)

Details

apprunner segfaults at some stage after autoregistration is complete, first time
after compile gives error about nsCategoryManager then segfaults, times after
that segfaults only.

version is latest CVS version of Seamonkey, not sure how to find out what
version number that actually is.

marauder@katharina:~/mozilla/dist/bin$ ./mozilla-apprunner.sh
MOZILLA_FIVE_HOME=/usr/home/marauder/mozilla/dist/bin
  LD_LIBRARY_PATH=/usr/home/marauder/mozilla/dist/bin
      MOZ_PROGRAM=./apprunner
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
nsNativeComponentLoader: autoregistering begins.
*** Registering sample components
*** Registering net components
*** Registering about: components
*** Registering data: components
*** Registering file: components
 ...
*** Registering CookieService components
*** Registering wallet components
*** Registering walletviewer components
nsNativeComponentLoader: autoregistering succeeded
mJCL: ERROR
/usr/home/marauder/mozilla/dist/bin/components/nsCategoryManager.js:27
TypeError: Components.interfaces has no properties
Segmentation fault - core dumped

marauder@katharina:~/mozilla/dist/bin$ gdb apprunner apprunner.core
GNU gdb 4.18
This GDB was configured as "i386-unknown-freebsd"...
Core was generated by `apprunner'.
Program terminated with signal 11, Segmentation fault.

(gdb) bt
#0  0x0 in ?? ()
#1  0x281d85c5 in XPTC_InvokeByIndex (that=0x8126da0, methodIndex=4,
paramCount=1, params=0xbfbfc7a4)
    at xptcinvoke_unixish_x86.cpp:159
#2  0x2857f54a in nsXPCWrappedNativeClass::CallWrappedMethod (this=0x812d000,
cx=0x80aa400, wrapper=0x812d040, desc=0x8125c28,
    callMode=CALL_GETTER, argc=0, argv=0x0, vp=0xbfbfcbe0) at
xpcwrappednativeclass.cpp:890
#3  0x28581a96 in nsXPCWrappedNativeClass::GetAttributeAsJSVal (this=0x812d000,
cx=0x80aa400, wrapper=0x812d040, desc=0x8125c28,
    vp=0xbfbfcbe0) at xpcprivate.h:702
#4  0x285833b5 in WrappedNative_GetProperty (cx=0x80aa400, obj=0x80c9fb0,
id=135425632, vp=0xbfbfcbe0)
    at xpcwrappednativejsops.cpp:238
#5  0x280ed126 in js_Interpret (cx=0x80aa400, result=0xbfbfccb4) at
jsinterp.c:2203
#6  0x280de539 in js_Invoke (cx=0x80aa400, argc=1, flags=0) at jsinterp.c:688
#7  0x280ef342 in js_Interpret (cx=0x80aa400, result=0xbfbfd188) at
jsinterp.c:2247
#8  0x280dea40 in js_Execute (cx=0x80aa400, chain=0x80ca158, script=0x812e200,
fun=0x0, down=0x0, debugging=0, result=0xbfbfd188)
    at jsinterp.c:845
#9  0x280b51ab in JS_ExecuteScript (cx=0x80aa400, obj=0x80ca158,
script=0x812e200, rval=0xbfbfd188) at jsapi.c:2619
#10 0x2853cf19 in mozJSComponentLoader::GlobalForLocation (this=0x807d9c0,
aLocation=0x80a2e80 "rel:nsSample.js",
    component=0x80918e0) at mozJSComponentLoader.cpp:591
#11 0x2853cc6a in mozJSComponentLoader::ModuleForLocation (this=0x807d9c0,
registryLocation=0x80a2e80 "rel:nsSample.js",
    component=0x80918e0) at mozJSComponentLoader.cpp:499
#12 0x2853cb07 in mozJSComponentLoader::AutoRegisterComponent (this=0x807d9c0,
when=0, component=0x80918e0, registered=0xbfbfd2b8)
    at mozJSComponentLoader.cpp:456
#13 0x2853c3e2 in mozJSComponentLoader::RegisterComponentsInDir (this=0x807d9c0,
when=0, dir=0x8091880)
    at mozJSComponentLoader.cpp:327
#14 0x2853c066 in mozJSComponentLoader::AutoRegisterComponents (this=0x807d9c0,
when=0, aDirectory=0x8091880)
    at mozJSComponentLoader.cpp:289
#15 0x281aedb0 in AutoRegister_enumerate (key=0x8092000, aData=0x807d9c0,
aClosure=0xbfbfd40c) at nsComponentManager.cpp:2025
#16 0x2817944a in _hashEnumerate (he=0x80a2e40, i=0, arg=0xbfbfd390) at
nsHashtable.cpp:89
#17 0x281fd249 in PL_HashTableEnumerateEntries (ht=0x8056340, f=0x28179414
<_hashEnumerate(PLHashEntry *, int, void *)>,
    arg=0xbfbfd390) at plhash.c:368
#18 0x28179918 in nsHashtable::Enumerate (this=0x805d320,
    aEnumFunc=0x281aed20 <AutoRegister_enumerate(nsHashKey *, void *, void *)>,
closure=0xbfbfd40c) at nsHashtable.cpp:218
#19 0x281af483 in nsComponentManagerImpl::AutoRegister (this=0x805b880, when=0,
inDirSpec=0x0) at nsComponentManager.cpp:2104
#20 0x281ba763 in nsComponentManager::AutoRegister (when=0, directory=0x0) at
nsRepository.cpp:200
#21 0x804f630 in NS_AutoregisterComponents () at nsSetupRegistry.cpp:87
#22 0x804fdad in NS_SetupRegistry_1 () at nsSetupRegistry.cpp:107
#23 0x804cf32 in main1 (argc=1, argv=0xbfbfd6c8) at nsAppRunner.cpp:495
#24 0x804d7b5 in main (argc=1, argv=0xbfbfd6c8) at nsAppRunner.cpp:670
#25 0x804bf1d in _start ()
Assignee: leger → granrose
Component: Browser-General → Build Config
QA Contact: leger → granrose
Sending over the build gurus.
Assignee: granrose → mccabe
Component: Build Config → Javascript Engine
this isn't a build config issue, looks more like a javascript or xpcom
registration issue.  changing component to javascript and sending to default
component owner.

fwiw, the best way to say what build you're running is to look at the build id
in Help|About which should be something like 1999111908 if you built it right
now.  Or you can just say the timestamp of when you pulled the tree from CVS
which would be the most accurate.
Assignee: mccabe → jband
Component: Javascript Engine → XPConnect
Passing this on to XPConnect (sorry, John!)
Assignee: jband → shaver
This is likely independent of the category manager stuff. This looks to me like
a 'nix xptcall problem. Shaver owns those.
Status: NEW → ASSIGNED
Are you still seeing this?  This looks a fair bit like the problem we had when
our xptcall assembly was broken.

What compiler are you using?
Still want to find out what compiler you're using...
the last one I tried with was gcc 2.8.1. 2.7.something gave the same results.
Just wanted to let people know that I've gotten the same crash in exactly the
same place with a SeaMonkeyAll CVS pull from tonight, using gcc 2.7.2.3 on
FreeBSD 3.3-RELEASE, and also on an older version (from a few weeks ago) using
egcs-1.1.2.
Ok, updated my system to FreeBSD 3.4-STABLE, pulled the latest lizard, and
rebuilt it using gcc 2.95.2 -- all widgets are visible now, and works as well as
the binaries posted on the site. It still segfaults in the exact same place with
gcc 2.7.2.3, so I wager that it's the older compiler causing the problem.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I'm going to get all ambitious and close this, then.  Thanks for the detective
work!
Status: RESOLVED → VERIFIED
marking verified on reporters comments.
You need to log in before you can comment on or make changes to this bug.