Closed Bug 43587 Opened 25 years ago Closed 24 years ago

nsTimer held past XPCOM shutdown in static nsCOMPtr

Categories

(SeaMonkey :: Bookmarks & History, defect, P3)

Product:
SeaMonkey
Component:
Bookmarks & History
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: dbaron, Assigned: mozilla)

References

(Blocks 1 open bug)

Details

(Keywords: memory-leak, topembed+, Whiteboard: [tind-mlk])

nsBookmarksService::mTimer is held past XPCOM shutdown in a static nsCOMPtr. See bug 43561 for more info. It is defined at: http://lxr.mozilla.org/seamonkey/source/xpfe/components/bookmarks/src/nsBookmark sService.cpp#1713
Blocks: 43561
Keywords: mlk
Whiteboard: [tind-mlk]
m20
Target Milestone: --- → M20
Blocks: 38671
mTimer is cleared in nsBookmarksService's destructor... ref: http://lxr.mozilla.org/seamonkey/source/xpfe/components/bookmarks/src/nsBookmark sService.cpp#1713 which kind of implies that this isn't the root of the leak (RDF datasources are leaking due to something else leaking.)
can't we just make the com ptr a raw ptr and have the bookmarkservice clean it up when it goes away?
Keywords: nsbeta3
What's the difference? Whether its a rawptr or a comptr, the bookmark service clears it in its destructor.
you're right, no difference. So are we clearing it in reality, or do we indeed have a leak here?
nav triage team: reassigning to rjc who can reassign if necessary - doesn't seem like a slamm issue.
Assignee: slamm → rjc
.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Keywords: topembed+
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.