Closed Bug 189637 Opened 23 years ago Closed 14 years ago

Are Exit Routines called too early?

Categories

(Core :: XPCOM, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: timeless, Assigned: timeless)

Details

Attachments

(4 files, 1 obsolete file)

==12167== 8 bytes in 1 blocks are still reachable in loss record 2 of 20 ==12167== at 0x40046E1B: __builtin_new (vg_clientfuncs.c:125) ==12167== by 0x40384CDD: NS_RegisterXPCOMExitRoutine (/mnt/ibm/mozhack/mozilla/xpcom/build/nsXPComInit.cpp:633) ==12167== by 0x4046785B: SetupGlobalMemory(void) (/mnt/ibm/mozhack/mozilla/xpcom/glue/nsMemory.cpp:59) ==12167== by 0x40467A22: nsMemory::Clone(void const *, unsigned int) (/mnt/ibm/mozhack/mozilla/xpcom/glue/nsMemory.cpp:120) ==12167== by 0x41A44E4A: nsXPCComponents::GetClassName(char **) (../../../../dist/include/xpconnect/xpc_map_end.h:50) ==12167== by 0x41A813B1: XPCNativeScriptableInfo::Construct(XPCCallContext &, XPCNativeScriptableCreateInfo const *) (/mnt/ibm/mozhack/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1151) ==12167== by 0x41A725DC: XPCWrappedNative::Init(XPCCallContext &, JSObject *, XPCNativeScriptableCreateInfo const *) (/mnt/ibm/mozhack/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:700) ==12167== by 0x41A70FA2: XPCWrappedNative::GetNewOrUsed(XPCCallContext &, nsISupports *, XPCWrappedNativeScope *, XPCNativeInterface *, XPCWrappedNative **) (/mnt/ibm/mozhack/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:373) ==12167== by 0x41A45698: nsXPCComponents::AttachNewComponentsObject(XPCCallContext &, XPCWrappedNativeScope *, JSObject *) (/mnt/ibm/mozhack/mozilla/js/src/xpconnect/src/xpccomponents.cpp:1742) ==12167== by 0x41A32123: nsXPConnect::InitClasses(JSContext *, JSObject *) (/mnt/ibm/mozhack/mozilla/js/src/xpconnect/src/nsXPConnect.cpp:438) ==12167== by 0x41A632F4: XPCJSContextStack::GetSafeJSContext(JSContext **) (/mnt/ibm/mozhack/mozilla/js/src/xpconnect/src/xpcthreadcontext.cpp:152) ==12167== by 0x41A39C4E: XPCCallContext::XPCCallContext(XPCContext::LangType, JSContext *, JSObject *, JSObject *, long, unsigned int, long *, long *) (/mnt/ibm/mozhack/mozilla/js/src/xpconnect/src/xpccallcontext.cpp:87) ==12167== by 0x41A3126B: nsXPConnect::~nsXPConnect(void) (/mnt/ibm/mozhack/mozilla/js/src/xpconnect/src/nsXPConnect.cpp:113) ==12167== by 0x41A30DCF: nsXPConnect::Release(void) (/mnt/ibm/mozhack/mozilla/js/src/xpconnect/src/nsXPConnect.cpp:41) ==12167== by 0x41A3160D: nsXPConnect::ReleaseXPConnectSingleton(void) (/mnt/ibm/mozhack/mozilla/js/src/xpconnect/src/nsXPConnect.cpp:231) ==12167== by 0x41A60BE0: xpcModuleDtor(nsIModule *) (/mnt/ibm/mozhack/mozilla/js/src/xpconnect/src/xpcmodule.cpp:105) ==12167== by 0x40466464: nsGenericModule::Shutdown(void) (/mnt/ibm/mozhack/mozilla/xpcom/glue/nsGenericFactory.cpp:363) ==12167== by 0x40465E76: nsGenericModule::~nsGenericModule(void) (/mnt/ibm/mozhack/mozilla/xpcom/glue/nsGenericFactory.cpp:240) ==12167== by 0x40465FDA: nsGenericModule::Release(void) (/mnt/ibm/mozhack/mozilla/xpcom/glue/nsGenericFactory.cpp:248) ==12167== by 0x4040F055: nsDll::Shutdown(void) (/mnt/ibm/mozhack/mozilla/xpcom/components/xcDll.cpp:383)
Attachment #111953 - Flags: superreview?(dbaron)
Attachment #111953 - Flags: review?(dougt)
Why isn't CallExitRoutines deleting it?
Comment on attachment 111953 [details] [diff] [review] release gExitRoutines when it's empty i dunno. what i do know is that valgrind lists it. stepping through xpcshell shows that CallExitRoutines is called and does delete and null gExitRoutines. valgrind doesn't like it when gdb pokes its victim with a breakpoint (report sent), so i'm not sure what's going on or how to find out. CallExitRoutines only has one entry so I should be able to figure this out... the valgrind params i'm using are: /usr/local/bin/valgrind --error-limit=no --num-callers=20 -v --leak-check=yes --show-reachable=yes
Attachment #111953 - Flags: superreview?(dbaron)
Attachment #111953 - Flags: review?(dougt)
Attachment #111953 - Flags: review-
Keywords: mlk
Summary: NS_UnregisterXPCOMExitRoutine leaks gExitRoutines → valgrind seems to indicate gExitRoutines set by NS_UnregisterXPCOMExitRoutine is still reachable at exit
ok, i think i figured out the problem. it looks like the exit routines are called too early. I have two valgrind stacks showing the leak from: NS_RegisterXPCOMExitRoutine (/mnt/ibm/mozhack/mozilla/xpcom/build/nsXPComInit.cpp:633) SetupGlobalMemory(void) (/mnt/ibm/mozhack/mozilla/xpcom/glue/nsMemory.cpp:59) nsMemory::Free(void *) (/mnt/ibm/mozhack/mozilla/xpcom/glue/nsMemory.cpp:102) Which is probably bad :)
Summary: valgrind seems to indicate gExitRoutines set by NS_UnregisterXPCOMExitRoutine is still reachable at exit → Are Exit Routines called too early?
Attached file smoking gun
Attachment #111953 - Attachment is obsolete: true
Attached file without 'fix'
RegFactory is an app based on a compiling version of mozilla/xpcom/tests/RegFactory.cpp i'll commit that later. Logs are created using the following commands: /usr/local/bin/valgrind --error-limit=no --num-callers=20 -v --leak-check=yes --show-reachable=yes ./RegFactory ./components/nsSample.js 2> RegFactory.valgrind2 perl -pi -e 's/^.?==\d+==//;s/^.?--\d+--//;s/ record \d+ of \d+$/ record.../;s/ (?:at|by) 0x[\dA-F]{8}://' RegFactory.valgrind2
Attached file with 'fix'
Attached patch 'fix'Splinter Review
QA Contact: scc → xpcom
Exit routines were removed.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: