leak global window when starting mail

RESOLVED INVALID

Status

RESOLVED INVALID
19 years ago
8 years ago

People

(Reporter: dbaron, Unassigned)

Tracking

({memory-footprint, memory-leak})

Trunk
x86
Linux
memory-footprint, memory-leak

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3-][cut 8/28])

Attachments

(1 attachment)

We leak one GlobalWindowImpl when starting mail from the command line.  (We leak
a second from the password dialog, so to avoid that, the steps I've been using
for testing are:

1) "./mozilla -mail"
2) The instant the window comes up, click the X in the window manager

The window that is leaked is the one passed to nsMessenger::SetWindow.  I think
the problem is that the Close method of that window is never called, so there
are a lot of circular references (some through JS) that are never broken.
(There may also be a problem that GlobalWindowImpl::CleanUp needs to set
mControllers to nsnull to release mControllers.)  There may be some other stuff
I found that I'm forgetting...
Created attachment 11327 [details] [diff] [review]
**incorrect** patches I was working with (but they do reduce leaks and may be useful in debugging...)

Comment 2

19 years ago
reassigning to mscott.
Assignee: putterman → mscott

Comment 3

19 years ago
.
Status: NEW → ASSIGNED
Keywords: nsbeta3
Target Milestone: --- → M18

Updated

19 years ago
Keywords: footprint

Comment 4

19 years ago
marking nsbeta3+. Is this happening once per standalone window?  Is this related
to 45176?
Whiteboard: [nsbeta3+]
I see the GlobalWindowImpl (and a bunch of XPConnect stuff) leak when I open the
mail window from within the browser (not starting with -mail) in today's build,
and then exit.

Comment 6

19 years ago
second pass: - per mail triage
Whiteboard: [nsbeta3+] → [nsbeta3-][cut 8/28]

Updated

18 years ago
Target Milestone: M18 → ---

Updated

17 years ago
Blocks: 92580

Updated

17 years ago
No longer blocks: 92580
QA Contact: lchiang → stephend

Comment 7

17 years ago
plussing, but does this still happen?
Keywords: nsbeta3 → nsbeta1+

Comment 8

17 years ago
minusing because it's not clear this still happens. If it does and we can get a
fix, I'd + it.
Blocks: 122274
Keywords: nsbeta1+ → nsbeta1-
I've looked at this with Purify recently, and can't figure out if this is still
valid.
Product: Browser → Seamonkey
Assignee: mscott → mail
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: stephend

Comment 10

10 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED

Comment 11

10 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 12

10 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 13

10 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 14

10 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 15

10 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 16

10 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 17

9 years ago
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → EXPIRED

Comment 18

8 years ago
The backend has changed so much over the last 10 years that this report really isn't helpful anymore. Current leaks should be filed as new bugs, please.
Resolution: EXPIRED → INVALID
You need to log in before you can comment on or make changes to this bug.