I had reported this back on March 12, 1999 to dp, but didn't think it was real. I get this typically after a depend build when loading components/libucvja.so, but sometimes other things. A second run makes it all go fine. This looks related to #4270 **** Purify instrumented ./apprunner.pure (pid 27916) **** MSE: Memory segment error: * This is occurring while in: nsIDKey::nsIDKey(const nsID&) [nsHashtable.h:125] nsComponentManagerImpl::FindFactory(const nsID&,nsIFactory**) [nsComponentManager.cpp:926] nsComponentManagerImpl::RegisterComponent(const nsID&,const char*,const char*,const char*,int,int) [nsComponentManager.cpp:1297] NSRegisterSelf [nsUCVJA2Dll.cpp:202] nsComponentManagerImpl::SelfRegisterDll(nsDll*) [nsComponentManager.cpp:1947] nsComponentManagerImpl::SyncComponentsInFile(const char*) [nsComponentManager.cpp:1869] nsComponentManagerImpl::SyncComponentsInDir(const char*) [nsComponentManager.cpp:1697] nsComponentManagerImpl::SyncComponentsInPathList(const char*) [nsComponentManager.cpp:1667] nsComponentManagerImpl::AutoRegister(nsIComponentManager::RegistrationTime,c onst char*) [nsComponentManager.cpp:1586] nsComponentManager::AutoRegister(nsIComponentManager::RegistrationTime,const char*) [nsRepository.cpp:157] NS_SetupRegistry [nsSetupRegistry.cpp:293] NS_SetupRegistry_1 [nsSetupRegistry.cpp:93] main [nsAppRunner.cpp:120] _start [crt1.o] * Accessing a memory range that crosses a memory segment boundary. Addressing 0xfffc0000 for 4 bytes ending at 0xfffc0004, which is neither in the heap nor the main stack. **** Purify instrumented ./apprunner.pure (pid 27916) **** COR: Fatal core dump: * This is occurring while in: nsIDKey::nsIDKey(const nsID&) [nsHashtable.h:125] nsComponentManagerImpl::FindFactory(const nsID&,nsIFactory**) [nsComponentManager.cpp:926] nsComponentManagerImpl::RegisterComponent(const nsID&,const char*,const char*,const char*,int,int) [nsComponentManager.cpp:1297] NSRegisterSelf [nsUCVJA2Dll.cpp:202] nsComponentManagerImpl::SelfRegisterDll(nsDll*) [nsComponentManager.cpp:1947] nsComponentManagerImpl::SyncComponentsInFile(const char*) [nsComponentManager.cpp:1869] nsComponentManagerImpl::SyncComponentsInDir(const char*) [nsComponentManager.cpp:1697] nsComponentManagerImpl::SyncComponentsInPathList(const char*) [nsComponentManager.cpp:1667] nsComponentManagerImpl::AutoRegister(nsIComponentManager::RegistrationTime,c onst char*) [nsComponentManager.cpp:1586] nsComponentManager::AutoRegister(nsIComponentManager::RegistrationTime,const char*) [nsRepository.cpp:157] NS_SetupRegistry [nsSetupRegistry.cpp:293] NS_SetupRegistry_1 [nsSetupRegistry.cpp:93] main [nsAppRunner.cpp:120] _start [crt1.o] * Received signal 11 (SIGSEGV - Segmentation Fault) * Faulting address = 0xfffc0000 * Signal mask: (SIGHUP | SIGINT | SIGQUIT | SIGILL | SIGTRAP | \ SIGABRT | SIGEMT | SIGFPE | SIGBUS | SIGSEGV | SIGSYS | SIGPIPE | \ SIGALRM | SIGTERM | SIGUSR1 | SIGUSR2 | SIGCHLD | SIGPWR | \ SIGWINCH | SIGURG | SIGPOLL | SIGTSTP | SIGCONT | SIGTTIN | \ SIGTTOU | SIGVTALRM | SIGPROF | SIGXCPU | SIGXFSZ | SIGWAITING | \ SIGLWP) * Pending signals:

Is your solaris machine a Multi processor one ?

I can only wish. No, it is a single CPU machine.

this isn't happening right now - maybe we shoudl release note it

this is easy to replicate for me. any time that components/libucvja.so is touched on unix, the next startup will coredump with the stack trace below. The other libraries do not cause this to happen. This is easily repeatable, and happened on machines other than mine as well.

I can reproduce it fine on the latest 4/9 M4 build. I've been seeing it for a long time. If anyone needs me to show them, just give me a call.

jevering and slamm have been looking but haven't figured out a solution. this bug is restricted to and updated set of binaries, and not a clean install, right? can we convince ourselves to move this to m6 or is it really bugging folks and frequently getting in their way?

I will look into this one. Maybe donm can show me if I cannot reproduce it.

Here is the debug output from XPCOM on doing this on a linux machine where I dont see the core dump: nsComponentManager: RegisterComponent({0e6892c1-a9ad-11d2-b3ae-00805f8a6670}, (null), (null), /home/dp/build/mozilla/dist/bin/components/libucvja.so), replace = 1, persist = 1. nsComponentManager: FindFactory({0e6892c1-a9ad-11d2-b3ae-00805f8a6670}) not found in factory cache. Looking in registry nsComponentManager: New dll "/home/dp/build/mozilla/dist/bin/components/libucvja.so". nsComponentManager: Adding New dll "/home/dp/build/mozilla/dist/bin/components/libucvja.so" to mDllStore. found in registry. nsComponentManager: + Loading "/home/dp/build/mozilla/dist/bin/components/libucvja.so". FindFactory() succeeded deleting registered Factory. Factory register succeeded. nsComponentManager: RegisterComponent({e28ab250-d66d-11d2-8aac-00600811a836}, (null), (null), /home/dp/build/mozilla/dist/bin/components/libucvja.so), replace = 1, persist = 1. nsComponentManager: FindFactory({e28ab250-d66d-11d2-8aac-00600811a836}) not found in factory cache. Looking in registry nsComponentManager: Found in mDllStore "/home/dp/build/mozilla/dist/bin/components/libucvja.so". found in registry. FindFactory() succeeded deleting registered Factory. Factory register succeeded. nsComponentManager: Autoregistration Passed for "/home/dp/build/mozilla/dist/bin/components/libucvja.so". Skipping... Can one of you with a debug build on solaris do the following and mail me the result: setenv NSPR_LOG_MODULES nsComponentManager:5 setenv NSPR_LOG_FILE xpcom.log ./apprunner [core dump] [email dp file xpcom.log]

haven't heard from dp. moving to m6.

Holding for post XPCOM20 landing.

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

What dup. NO! That was something else.

Bruce I tried it on solaris and I dont see it. I am hoping that testing or you will reopen it if this happens again.