Closed
Bug 398462
Opened 18 years ago
Closed 16 years ago
Leak nsBaseAppShell and nsRunnable with <iframe src="aim:foo"> and goQuitApplication
Categories
(Toolkit :: Startup and Profile System, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: jruderman, Unassigned)
References
Details
(Keywords: memory-leak, testcase)
Attachments
(4 files, 1 obsolete file)
Steps to reproduce:
1. Save the testcase as "a3.xhtml".
2. Edit the testcase to point to a URL that calls goQuitApplication (and is allowed to do so).
3. Exit Firefox.
4. export XPCOM_MEM_LEAK_LOG=1
5. Run a debug build of Firefox with "a3.xhtml" on the command line.
The testcase will automatically instruct Firefox to quit about a second after the browser window appears.
Result: 1 nsBaseAppShell and 1 nsRunnable leak.
Note that if bug 167475 is fixed, the testcase will stop working.
I have Adium installed but I have not instructed Firefox to allow clicks on aim: links. This results in a protocol-handling dialog appearing, but somehow *behind* the browser window. CCing sdwilsh on suspicion that this leak involves the new protocol-handling dialog (since he added it in bug 385065).
Reporter | ||
Comment 1•18 years ago
|
||
Reporter | ||
Comment 2•18 years ago
|
||
When I log nsBaseAppShell or nsRunnable, the leak goes away! (Logging a non-existent class doesn't make it go away.) Here's what I'm trying to use:
export XPCOM_MEM_LEAK_LOG=2
export XPCOM_MEM_REFCNT_LOG=log-file.dat
export XPCOM_MEM_COMPTR_LOG=log-comptr.dat
export XPCOM_MEM_LOG_CLASSES=nsBaseAppShell
![]() |
||
Comment 3•18 years ago
|
||
Does it matter which objects in that class you log? Sounds like a possible timing bug, with the logging affecting the timing....
Reporter | ||
Comment 4•18 years ago
|
||
There's only 1 nsBaseAppShell allocated according to the "Total" column, so I can't use XPCOM_MEM_LOG_OBJECTS with a specific serial number to avoid timing issues.
Reporter | ||
Comment 5•18 years ago
|
||
I got a balance tree for the leaked nsRunnable (mDummyEvent) using XPCOM_MEM_LOG_OBJECTS=262.
It does seem to be a timing issue, but adjusting the timeout in the testcase doesn't help :(
Reporter | ||
Comment 6•18 years ago
|
||
I managed to reproduce with logging on with this nastier testcase, after increasing THREAD_EVENT_STARVATION_LIMIT from 20ms to 200ms.
![]() |
||
Updated•18 years ago
|
Component: Networking → XRE Startup
Product: Core → Toolkit
QA Contact: networking → xre.startup
Reporter | ||
Comment 7•18 years ago
|
||
Component: XRE Startup → Startup and Profile System
QA Contact: xre.startup → startup
Reporter | ||
Comment 8•16 years ago
|
||
WFM on mozilla-central. Had to tweak the testcase a bunch to get it to work with my new setup involving Quitter.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 9•16 years ago
|
||
Attachment #283436 -
Attachment is obsolete: true
You need to log in
before you can comment on or make changes to this bug.
Description
•