Closed Bug 4275 Opened 25 years ago Closed 25 years ago

updating components/libucvja.so causes component manager to crash

Categories

(Core :: XPCOM, defect, P1)

Product:
Core
Component:
XPCOM
Platform:
Sun
Solaris
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: bruce, Assigned: dp)

Details

(Whiteboard: affects only updates to existing installs?) 

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:
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: M4
Is your solaris machine a Multi processor one ?
I can only wish.  No, it is a single CPU machine.
Assignee: dp → jevering
Status: ASSIGNED → NEW
Target Milestone: M4 → M5
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.
Summary: Random startup crashes related to component manager → updating components/libucvja.so causes component manager to crash
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?
Assignee: jevering → dp
I will look into this one. Maybe donm can show me if I cannot reproduce it.
Status: NEW → ASSIGNED
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]
Whiteboard: affects only updates to existing installs?
Target Milestone: M5 → M6
haven't heard from dp.  moving to m6.
Target Milestone: M6 → M7
Holding for post XPCOM20 landing.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
*** This bug has been marked as a duplicate of 4965 ***
What dup. NO! That was something else.
Status: REOPENED → ASSIGNED
Resolution: DUPLICATE → ---
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → VERIFIED
Component: XPCOM Registry → XPCOM
QA Contact: dp → xpcom
You need to log in before you can comment on or make changes to this bug.