registry coruption on win32 with USE_BUFFERED_REGISTRY_IO

VERIFIED FIXED

Status

()

Core
XPCOM
P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: John Bandhauer, Assigned: dveditz)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [09271999]waiting to hear from reporter)

(Reporter)

Description

18 years ago
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

18 years ago
buffering fixed.
(Assignee)

Updated

18 years ago
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Updated

18 years ago
Whiteboard: [09271999]waiting to hear from reporter

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 2

18 years ago
marking verified
You need to log in before you can comment on or make changes to this bug.