If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Leaks introduced by checkin to nsDOMClassInfo.cpp

RESOLVED FIXED

Status

()

Core
DOM
RESOLVED FIXED
13 years ago
12 years ago

People

(Reporter: Robert Kaiser, Assigned: jst)

Tracking

({fixed-aviary1.0, fixed1.7.5, mlk})

Trunk
x86
Linux
fixed-aviary1.0, fixed1.7.5, mlk
Points:
---
Bug Flags:
blocking1.7.5 +
blocking-aviary1.0PR +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
Brad tinderbox show that leaks increased by to the level before you fixed the
ones from bug 256932

The increase happend late on 2004-08-30, and the only checkin in this time
window is to nsDOMClassInfo.cpp - see
http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?module=MozillaTinderboxAll&date=explicit&mindate=1093908180&maxdate=1093917179

jst, you probably know that change, as you did it yourself, but as a reminder,
here's the diff:
http://tinderbox.mozilla.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/dom/src/base&command=DIFF_FRAMESET&file=nsDOMClassInfo.cpp&rev1=1.240&rev2=1.241&root=/cvsroot

brad shows an increase of refcnt leaks (RLk) from 268B to 7.22KB and of leaks
(Lk) from 302KB to 318KB.

Updated

13 years ago
Keywords: mlk
Chances are, we're pulling the pulluter out of the proto chain before we call
GetInvalidatedGlobalScopePolluter, so that function does nothing...
(Assignee)

Comment 2

13 years ago
The odd thing is that I do *not* see these leaks on my system. Last time I did,
but this time all but five nsEventListenerManagers are deleted when I start
firefox and immediately exit it. Last time I saw 137 nsEventListenerManagers
leaked, just like tinderbox did...
(Assignee)

Comment 3

13 years ago
Created attachment 157631 [details] [diff] [review]
Don't hand the old document to the gsp when setting a new document.

Found it. We were handing the old document to the gsp when
GlobalWindowImpl::SetNewDocument(nsnull) was called, which was fine in all
cases except when closing a window where there wouldn't be a following call
with a new document to SetNewDocument(). That's how the old document got left
in the gsp on shutdown.
(Assignee)

Updated

13 years ago
Attachment #157631 - Flags: superreview?(dbaron)
Attachment #157631 - Flags: review?(dbaron)
Comment on attachment 157631 [details] [diff] [review]
Don't hand the old document to the gsp when setting a new document.

r+sr=me in lieu of dbaron, with his consent.   Also approving for branches.

/be
Attachment #157631 - Flags: superreview?(dbaron)
Attachment #157631 - Flags: superreview+
Attachment #157631 - Flags: review?(dbaron)
Attachment #157631 - Flags: review+
Attachment #157631 - Flags: approval1.7.x+
Attachment #157631 - Flags: approval-aviary+

Updated

13 years ago
Flags: blocking1.7.x+
Flags: blocking-aviary1.0PR+
(Assignee)

Comment 5

13 years ago
Fixed on trunk and aviary.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Depends on: 256932
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
Did this land on 1.7 branch also?
(Assignee)

Comment 7

13 years ago
Not yet, it's waiting on the initial document.all and global name/id resolve
code to land. Once I get some spare time, I'll land it all...

Comment 8

13 years ago
This should be able to land on 1.7 now, correct?
(Assignee)

Updated

13 years ago
Keywords: fixed1.7.5
You need to log in before you can comment on or make changes to this bug.