Closed
Bug 189637
Opened 23 years ago
Closed 14 years ago
Are Exit Routines called too early?
Categories
(Core :: XPCOM, defect)
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?
Attachment #111953 -
Attachment is obsolete: true
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
Updated•19 years ago
|
QA Contact: scc → xpcom
Comment 9•14 years ago
|
||
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.
Description
•