198916 - GDI leak opening new window

Status: VERIFIED FIXED

(Core Graveyard :: GFX: Win32, defect)

Description

[Lewis Jardine]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312

Mozilla seems to leak GDI handles every time a new window is opened. 

Opening a new window allocates 8 new handles; closing it frees 4. Over the
course of a week, my mozilla hit windows XP's (apparent) limit of 10000 handles
per process, and various rendering problems occurred.

Reproducible: Always

Steps to Reproduce:
1. Start mozilla
2. Open a new window
3. Close it

Used GDI handles can be viewed per-process by opening Task Manager, and clicking
view-->select columns...-->GDI objects
Actual Results:  
Used GDI handles has increased by 4. Doing this 10 times increases GDI handles
by 40. Doing this 2500 times will probably crash even XP.

Expected Results:  
Used GDI handles return to previous value.

Does not seem to matter if 'hide tab bar if only one tab is open' is checked.
Some webpages seem to produce additional GDI leaks, but I cannot reproduce
consistently.

Certainly, I don't think it got all the way to 10000 through only this bug :) .

Comment 1

[Lewis Jardine]

Attachment: Screenshot of graphical corruption when mozilla reaches 10000 GDI handles

Comment 2

[Alan Monroe]

I have experienced similar problems on windows 2000. When GDI objects column in
task manager reaches around 1024 or thereabouts, for the Mozilla process, the
Mozilla window stops repainting itself if obscured, parts of the window
disappear until you mouse over them, etc. I have to exit and relaunch. I was
able to duplicate the "closing it frees 4" behaviour by opening and closing the
About screen a few times.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021126

Comment 3

[Jim Dunn]

Seems like multiple problems are being talked about.
Opening new window is *probably* the result of rects/brushes...
btw, if I try this using trunk 7/7 build, open blank mozilla,
hit "cntrl n" 4 times (on win2k), I go from 133 -> 178 -> 224 -> 267
gdi Objects used.  Deleting them take me from 267 -> 247 -> 206 -> 159.
So definitely more than 4 gdi objects for me...

comment #3 is probably similar to bug 205893

Comment 4

[Daniel de Wildt]

I looks like the same bug still exists in 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
The GDI leak appears in nearly EVERY mozilla window (create message, show source
code ...). But not in t he preference window.

I found a useful tool 'GDILeak' on the microsoft website
http://msdn.microsoft.com/msdnmag/issues/01/03/leaks/default.aspx
http://msdn.microsoft.com/msdnmag/issues/03/01/GDILeaks/
You can make a gdi snapshot and compare it after opening/closing the window. The
results are the kind of the gdi resource and the memory.

The three gdi leaks I have are two 'bitmap' and one 'palette'.

Comment 5

[Daniel de Wildt]

Maybe I have found a reason for the 2 'bitmap' leaks.
I don't know if the following remarks are correct, because I'm not firm with the
Mozilla code, but maybe this will help other people.
I think that in
http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsWindow.cpp#5491
different taskbar icons are loaded. The first two ::LoadImage didn't use
LR_SHARED. Icons loaded without LR_SHARED should be destroyed with destroyed
with ::DestroyIcon.
See also MSDN
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/Resources/Icons.asp
and
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/Resources/IntroductiontoResources/ResourceReference/ResourceFunctions/LoadImage.asp

Also see bugs 57576 and 180150

Comment 6

[Daniel de Wildt]

I will fill a new bug with these issue, because it seems that the original bug
contains more then one bug.

Comment 7

[Rene Pronk]

Windows 2000, Mozilla 2003102204

Still happens. After running the leaktest I'll attach in a minute for an hour or
2 Mozilla was using around 110MB ram and was holding 10,000 GDI handles. Having
this many handles open drove Windows completely insane. Closing Mozilla solved
it again. So besides a GDI leak we also appear to have a memory leak. I'm not
sure if one is causing the other. We'll have to see that if one is fixed and
then open a new bug if necessary.

According to #4 this bug occurs in nearly every window being opened. It should
block 1.6 somehow I think.

Comment 8

[Rene Pronk]

Attachment: Testcase - part 1

Comment 9

[Rene Pronk]

Attachment: Testcase - part 2

Comment 10

[Daniel de Wildt]

I used the refcount balancer and it looks like that nsDocLoaderImpl or
nsDocShell is not freed. (The list is incomplete, it contains 11 not freed
classes like nsLoadGroup or nsDeviceContextWin. But I think that one of those
two classes will be source. I will post a bloat.log and a calling tree tomorrow
if it's necessary.)

This is maybe bug 153395

In addition to comment 5:
The start of the GDI-palette leak is in nsDeviceContextWin (which is not freed)
The GDI-icon leaks are filed in bug 222387

Comment 11

[Daniel de Wildt]

Attachment: bloat.log with leaks. Created after starting and closing an empty browser

The number of leaks for DeviceContextImpl, nsDocLoaderImpl, nsDocShell,
nsDocShell::InterfaceRequestorProxy, nsFontCache, nsLoadGroup, nsWebShellWindow
depends on how often you open a new window. Browser with content produces als
leaks in other classes.

Comment 12

[Daniel de Wildt]

Attachment: Calling tree for nsWebShellWindow

Smallest calling tree of an leaking instance from the classes in comment 11
Is it normal that nsAppShellService::CreateTopLevelWindow is called, but not
nsAppShellService::CloseTopLevelWindow?

Comment 13

[Daniel de Wildt]

I think the leak is in nsWebShellWindow::~nsWebShellWindow()
The persistent timer contains a reference to the "this" but this reference is
not released. This should be a bug.

There could be more then only one reason for this bug. I will fill a new bug,
because the bug I described could be only one of it. 

This bug should depends on the new bug (and also on bug 222387)

Comment 14

[Randell Jesup [:jesup] (needinfo me)]

Please retest this now that 223736 and 222387 are fixed for 1.6b

If you also test on Win98, that's a plus too, but it shouldn't matter much (just
will die that much sooner)

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Marking fixed based on recent fixes.  If someone observes that this bug is still
a problem in builds from 2003-11-24 or newer, please reopen.

Comment 16

[Daniel de Wildt]

The reopening of bug 223736 seems to be formal, the patch is still checked in.
Opening and closing windows with 2003-11-25-08 doesn't result in a GDI leak =>
verified