Open Bug 276112 Opened 20 years ago Updated 2 years ago

Can still leak nsExternalAppHandler/nsIDownload

Categories

(Firefox :: File Handling, defect, P5)

defect

Tracking

()

People

(Reporter: chpe, Unassigned)

References

Details

(Keywords: memory-leak)

Even with the fix from bug 152224, it's still possible that nsExternalAppHandler and its nsIDownload are leaked, if the OnStopRequest is received _before_ the nsIDownload is even created. See the analysis at http://bugzilla.gnome.org/show_bug.cgi?id=158217#c1 .
confirming and taking; maybe these refcycle-breaking code from http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.cpp#1982 (OnStopRequest) should move to ExecuteDesiredAction; but that needs to be done carefully since it's possible that that's releasing the last reference to the apphandler, I think...
Assignee: file-handling → cbiesinger
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Keywords: mlk
Summary: can still leak nsExternalAppHandler/nsIDownload → Can still leak nsExternalAppHandler/nsIDownload
Priority: P2 → P1
Target Milestone: --- → mozilla1.8beta3
Yes, that looks like the same problem, according to my analysis of the problem in http://bugzilla.gnome.org/show_bug.cgi?id=158217#c1 from comment 0.
I have no leak related to bug 343107. Everything is correctly released after the return from SaveToDisk and the release of the HelperAppLauncherDialog which follows.
I'm still not sure why that caused a leak, but bug 343107 is fixed now. anything left to do here?
QA Contact: ian → file-handling
Assignee: cbiesinger → nobody
Product: Core → Firefox
Target Milestone: mozilla1.8beta3 → ---
Version: Trunk → unspecified
Decreasing the priority as no update for the last 2 years on this bug. See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage about the priority meaning.
Priority: P1 → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.