Closed Bug 32448 Opened 24 years ago Closed 24 years ago

[FIX]Viewer leaking widgets

Categories

(Core Graveyard :: Viewer App, defect, P3)

x86
Linux
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dbaron, Assigned: rods)

Details

(Keywords: memory-leak)

On Linux, viewer is leaking 5 nsBaseWidget every run.  This is a somewhat recent
regression (between 02-21 and 03-18).  The following patch fixes it for me, but
I'm not sure if it's the right thing to do, and I'm not sure if it's OK on all
platforms:

Index: nsBrowserWindow.cpp
===================================================================
RCS file: /cvsroot/mozilla/webshell/tests/viewer/nsBrowserWindow.cpp,v
retrieving revision 3.311
diff -u -r3.311 nsBrowserWindow.cpp
--- nsBrowserWindow.cpp 2000/03/15 01:19:42     3.311
+++ nsBrowserWindow.cpp 2000/03/19 18:19:09
@@ -240,13 +240,13 @@
       }
 
    DestroyWidget(mBack);         
-   mBack = nsnull;
+   NS_IF_RELEASE(mBack);
    DestroyWidget(mForward);      
-   mForward = nsnull;
+   NS_IF_RELEASE(mForward);
    DestroyWidget(mLocation);     
-   mLocation = nsnull;
+   NS_IF_RELEASE(mLocation);
    DestroyWidget(mStatus);       
-   mStatus = nsnull;
+   NS_IF_RELEASE(mStatus);
 
    if(mThrobber)
       {
@@ -256,7 +256,7 @@
       }
 
    DestroyWidget(mWindow);       
-   mWindow = nsnull;
+   NS_IF_RELEASE(mWindow);
 
    return NS_OK;
 }
I'll take this one
Assignee: rickg → rods
I am almost wondering if the release shouldn't go into the DestroyWidget method. 
 But we have to look and see why the mWindow isn't being released.
Status: NEW → ASSIGNED
This fixes it on WinNT and Linux, I have also added asserts to notify us of 
leaks in the future.
Summary: Viewer leaking widgets → [FIX]Viewer leaking widgets
changing to M15
Target Milestone: --- → M15
fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reopening.  I don't think NS_ASSERTION evaluates its arguments in an optimized
build.  Therefore this will still leak in optimized builds, but not debug.  (I
really don't see the need for the assertions.  If things leak, they can be
caught by setting XPCOM_MEM_LEAK_LOG.)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Very good catch, I'll check in the fix tmorrow.
Status: REOPENED → ASSIGNED
fixed again
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.