Memory leak in XTF when using nsXTFInterfaceAggregator

VERIFIED FIXED

Status

VERIFIED FIXED
13 years ago
4 years ago

People

(Reporter: smaug, Assigned: smaug)

Tracking

({verified1.8.0.12, verified1.8.1.4})

Trunk
verified1.8.0.12, verified1.8.1.4

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

13 years ago
Patch coming.
(Assignee)

Comment 1

13 years ago
Created attachment 203147 [details] [diff] [review]
proposed patch

First QueryInterfaceInner AddRefs innerPtr, then NS_NewXTFInterfaceAggregator
AddRefs it, but only the nsXTFInterfaceAggregator object keeps the pointer to innerPtr. So innerPtr will be released only once (when nsXTFInterfaceAggregator is deleted). This means that we're leaking nsIXTFElement objects.
So the patch adds one NS_RELEASE.
Attachment #203147 - Flags: superreview?(bryner)
Attachment #203147 - Flags: review?(bryner)
(Assignee)

Updated

13 years ago
Attachment #203147 - Flags: superreview?(bryner)
Attachment #203147 - Flags: review?(bryner)
(Assignee)

Comment 2

13 years ago
Created attachment 203299 [details] [diff] [review]
proposed patch, better style
Attachment #203147 - Attachment is obsolete: true
Attachment #203299 - Flags: superreview?(bryner)
Attachment #203299 - Flags: review?(bryner)
(Assignee)

Comment 3

13 years ago
Created attachment 203438 [details] [diff] [review]
using nsCOMPtr
Attachment #203299 - Attachment is obsolete: true
Attachment #203438 - Flags: superreview?(bryner)
Attachment #203438 - Flags: review?(bryner)
Attachment #203299 - Flags: superreview?(bryner)
Attachment #203299 - Flags: review?(bryner)
Attachment #203438 - Flags: superreview?(bryner)
Attachment #203438 - Flags: superreview+
Attachment #203438 - Flags: review?(bryner)
Attachment #203438 - Flags: review+
(Assignee)

Comment 4

13 years ago
Checked in
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 5

13 years ago
I know that 1.8 is closed (unless we figure out a way to make this a security error ;-) ). How do we remember to push this to branch as soon as possible?
(Assignee)

Updated

12 years ago
Duplicate of this bug: 377372
(Assignee)

Comment 7

12 years ago
Comment on attachment 203438 [details] [diff] [review]
using nsCOMPtr

It would be really great to get this leak fix to branches. This has been on trunk over a year! and there are no known regressions.
Attachment #203438 - Flags: approval1.8.1.4?
Attachment #203438 - Flags: approval1.8.0.12?
Comment on attachment 203438 [details] [diff] [review]
using nsCOMPtr

approved for 1.8.0.12 and 1.8.1.4, a=dveditz for release-drivers
Attachment #203438 - Flags: approval1.8.1.4?
Attachment #203438 - Flags: approval1.8.1.4+
Attachment #203438 - Flags: approval1.8.0.12?
Attachment #203438 - Flags: approval1.8.0.12+

Comment 9

12 years ago
checked into 1.8 branch
Keywords: fixed1.8.1.4

Comment 10

12 years ago
checked into 1.8.0 branch
Keywords: fixed1.8.0.12
don't know how to test this. verified per checkins and no regressions on trunk
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.0.12, fixed1.8.1.4 → verified1.8.0.12, verified1.8.1.4
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.