nsThread leaked by SetMainThread

RESOLVED DUPLICATE of bug 29355

Status

()

Core
XPCOM
P3
normal
RESOLVED DUPLICATE of bug 29355
18 years ago
11 years ago

People

(Reporter: dbaron, Unassigned)

Tracking

({mlk})

Trunk
Future
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
I'm assigning this based on CVS Blame on the second part of the problem (warren)
and cc:ing beard since he shows up in CVS blame for the first part.

nsIThread::SetMainThread leaks an nsThread because it is storing the main thread
in a global variable.  SetMainThread is called only from NS_InitXPCOM, so *if*
this thread could be released in NS_ShutdownXPCOM, then that would fix one of
the two extra references.

Actually, though, it seems like the thread is addref'd twice in
nsIThread::GetIThread.  It seems that nsIThread::GetIThread is called only from
SetMainThread (based on LXR), so I'm not sure if this is necessary, but it's not
clear to me why it was done.  Not addref-ing it twice in GetIThread would
actually fix the leak, since there are two outstanding references, although the
correct solution could easily be something else.

A refcount balancer long (with ignore-balanced) is available, when my computer
is on, at
http://dbaron.student.harvard.edu/u/david/leaks/viewer/nsThread.balance-ib.txt
(Reporter)

Updated

18 years ago
Keywords: mlk

Comment 1

18 years ago
Is it that the xpcom shutdown doesn't free the main thread, or that the main 
thread is declared joinable, and no one ever joins with it? (I haven't 
investigated yet, but I thought I'd ask.)

Updated

18 years ago
Target Milestone: M15

Comment 2

18 years ago
Moving non-essential, non-beta2 and performance-related bugs to M17.
Target Milestone: M15 → M17

Comment 3

18 years ago
post-beta2
Target Milestone: M17 → M18

Updated

17 years ago
Assignee: warsome → danm

Comment 4

17 years ago
Moving Warren's thread bugs from his circular file to mine, because I was told it 
was the thing to do. Anyone who actually wants these bugs, now, feel free to 
correct my hastiness.

Updated

17 years ago
Target Milestone: M18 → mozilla0.9

Updated

17 years ago
QA Contact: leger → kandrot

Updated

17 years ago
Target Milestone: mozilla0.9 → mozilla1.0
(Reporter)

Comment 5

17 years ago
I think something fixed the observable leak here a long time ago.

Updated

16 years ago
Blocks: 92580

Updated

16 years ago
No longer blocks: 92580

Comment 6

16 years ago
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1

Updated

16 years ago
Target Milestone: mozilla1.0.1 → ---

Updated

16 years ago
Target Milestone: --- → Future

Updated

13 years ago
Assignee: danm.moz → nobody

Updated

12 years ago
QA Contact: kandrot → nobody
QA Contact: nobody → xpcom
(Reporter)

Updated

11 years ago
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 29355
You need to log in before you can comment on or make changes to this bug.