Closed
Bug 14306
Opened 26 years ago
Closed 26 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•26 years ago
|
||
buffering fixed.
Assignee | ||
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Updated•26 years ago
|
Whiteboard: [09271999]waiting to hear from reporter
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Comment 2•26 years ago
|
||
marking verified
You need to log in
before you can comment on or make changes to this bug.
Description
•