Closed
Bug 14306
Opened 25 years ago
Closed 25 years ago
registry coruption on win32 with USE_BUFFERED_REGISTRY_IO
Categories
(Core :: XPCOM, defect, P3)
Tracking
()
VERIFIED
FIXED
People
(Reporter: jband_mozilla, Assigned: dveditz)
Details
(Whiteboard: [09271999]waiting to hear from reporter)
waterson wrote: Dan, As you suggested, I tried commenting out USE_BUFFERED_REGISTRY_IO in mozilla/modules/libreg/src/makefile.win, rebuilding modules/libreg/src, and re-linking xpcom.dll. This fixed my problem. Which leads me to believe there are still some kinks to work out with USE_BUFFERED_REIGSTRY_IO on Win32. chris Chris Waterson wrote: > > Ok, here's what I'm seeing: > > 1. Delete component.reg. Autoreg runs. kMetaCharsetCID gets registered. > I get past nsAppShellService.cpp:213. > > 2. In nsAppShellService::CreateHiddenWindow() > > > http://lxr.mozilla.org/seamonkey/source/xpfe/appshell/src/nsAppShellService.cpp# 271 > > NS_NewURI() is failing because it can't find a protocol handler for > 'chrome' at > > > http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsIOService.cpp#196 > > I set a breakpoint in chrome.dll's NS_RegisterSelf(), and sure 'nuf, > it's being registered. So why wouldn't we be able to find it later? > Corruption? Graft? Greed? > > 3. On subsequent runs, autoreg does _not_ run, and the registry seems to > have been corrupted -- or maybe just never got written back out to disk. > kMetaCharsetCID appears to be unregistered. > > Can somebody please vend a clue? > > Chris Waterson wrote: > > > > I fail here: > > > > http://lxr.mozilla.org/seamonkey/source/xpfe/appshell/src/nsAppShellService.cpp# 213 > > > > Why is it unable to get the "kMetaCharsetCID" service? > > > > chris ---------------------------------------------------------------------------- I [jband] am seeing it return the error: if (desc->location != offset) err = REGERR_BADLOCN; in nr_ReadDesc. This gets mapped to a RegisterComponent result of NS_ERROR_UNEXPECTED. It looks like subsequent registy calls fail too. This happens to be in autregistering ucvcn.dll with the stack that follows. It is not the first thing registered byt the dll and I can't see anything odd about the call. Renaming the dll, whacking the components.reg and starting over makes this not fail. But perhaps this is just hitting a size boundary or something? setting a breakpoint in the err return code above will get one to the place where failure seems to start, but I don't know where any actual corruption (if that is the problem) is happenning. Hope this helps :) John. nr_ReadDesc(_regfile * 0x00a45c30, long 0x00020023, _desc * 0x0012ee94) line 865 nr_FindAtLevel(_regfile * 0x00a45c30, long 0x00020023, char * 0x00a72d40, _desc * 0x0012f0f4, long * 0x00000000) line 1540 + 17 bytes nr_RegAddKey(_regfile * 0x00a45c30, long 0x000002a9, char * 0x00a72d40, long * 0x0012f198, int 0x00000001) line 1869 + 23 bytes NR_RegAddKeyRaw(void * 0x00a45980, long 0x000002a9, char * 0x00a72d40, long * 0x0012f198) line 2438 + 23 bytes nsRegistry::AddSubtreeRaw(nsRegistry * const 0x00a45fa0, unsigned long 0x000002a9, const char * 0x00a72d40, unsigned long * 0x0012f198) line 741 + 24 bytes nsComponentManagerImpl::AddComponentToRegistry(const nsID & {...}, const char * 0x0012f298, const char * 0x0012f31c, const char * 0x00a72da0, const char * 0x10064fcc nativeComponentType) line 1703 + 33 bytes nsComponentManagerImpl::RegisterComponentCommon(const nsID & {...}, const char * 0x0012f298, const char * 0x0012f31c, char * 0x00a72da0, int 0x00000001, int 0x00000001, const char * 0x10064fcc nativeComponentType) line 1543 + 28 bytes nsComponentManagerImpl::RegisterComponent(nsComponentManagerImpl * const 0x00a44810, const nsID & {...}, const char * 0x0012f298, const char * 0x0012f31c, const char * 0x00a70e50, int 0x00000001, int 0x00000001) line 1436 NSRegisterSelf(nsISupports * 0x00a41520, const char * 0x00a70e50) line 269 + 50 bytes nsNativeComponentLoader::SelfRegisterDll(nsDll * 0x00a71360, const char * 0x00a70e50) line 481 + 14 bytes nsNativeComponentLoader::AutoRegisterComponent(nsNativeComponentLoader * const 0x00a44300, int 0x00000000, nsIFileSpec * 0x00a713c0, int * 0x0012fd84) line 816 + 19 bytes nsNativeComponentLoader::RegisterComponentsInDir(nsNativeComponentLoader * const 0x00a44300, int 0x00000000, nsIFileSpec * 0x00a4a900) line 323 + 24 bytes nsNativeComponentLoader::AutoRegisterComponents(nsNativeComponentLoader * const 0x00a44300, int 0x00000000, nsIFileSpec * 0x00a4a900) line 267 + 20 bytes nsComponentManagerImpl::AutoRegister(nsComponentManagerImpl * const 0x00a44810, int 0x00000000, nsIFileSpec * 0x00000000) line 1955 + 31 bytes nsComponentManager::AutoRegister(int 0x00000000, nsIFileSpec * 0x00000000) line 197 SetupRegistry() line 61 + 10 bytes main(int 0x00000001, char * * 0x00a41560) line 585 mainCRTStartup() line 338 + 17 bytes
Assignee | ||
Comment 1•25 years ago
|
||
buffering fixed.
Assignee | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Updated•25 years ago
|
Whiteboard: [09271999]waiting to hear from reporter
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 2•25 years ago
|
||
marking verified
You need to log in
before you can comment on or make changes to this bug.
Description
•