Closed Bug 204374 Opened 21 years ago Closed 20 years ago

GDI Resources are used until the UI/website displays faultily

Categories

(Core Graveyard :: GFX: Win32, defect)

Product:
Core Graveyard
Component:
GFX: Win32
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 205893

People

(Reporter: sven.burmeister, Assigned: smontagu)

References

Details

(4 keywords, Whiteboard: Please see workaround in comment #147)

Attachments

(9 files)

GDI object monitor that works on win2k
10.94 KB, application/x-zip-compressed
Details
Taskmanager durring incident
24.95 KB, image/gif
Details
Google groups corruption (text missing, icons missing)
33.79 KB, image/gif
Details
Slashdot corruption (text missing)
58.36 KB, image/gif
Details
IE got sick as well
31.57 KB, image/gif
Details
Huge Slashdot page
37.70 KB, image/gif
Details
Screenshot of Issues wiht Mozilla 1.4 RC 3
72.75 KB, image/png
Details
1.5a patch does not fix the problem
14.28 KB, image/gif
Details
DLLs and Handles in use for NS7.2 when GDI is a 9%
8.65 KB, application/x-zip-compressed
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.4b) Gecko/20030502
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.4b) Gecko/20030502

Using latest nightlies for Mozilla and Mozilla Firebird after a few pages
pictures on pages are just displayed in black, or not at all. The UI turns funny
by not longer displaying the skin properly (classic and any other), not
displaying the skin's buttons and pictures. The scroll-bars show a 5 in the up-
and down-arrows. Texts are displayed in random font.
To me this seems like a memory problem. I did not have this until three weeks
ago or so. It happens even if Moz/Firebird is the only program running. When
looking at the GDI Resources they go down every time a new webpage is opened,
even if only reloaded (but less) till it comes to the point that the UI turns
funny and one has to restart Mozilla completely.
This does not depend on the actual number of tabs or windows, but only on the
amount of pages opened, of course having mail open speeds the whole process up.

Reproducible: Always

Steps to Reproduce:
1. Open new websites in one and the same window
2. watch memory going down
3. UI turns funny




I got 192 MB RAM and Moz got 50 MB cache, so it should not be the actual lack of
memory. To me it seems that Mozilla does not know when to stop and uses more and
more memory.
there are multiple bugs open on this:
Bug 192342 Use EnumFontFamiliesEx rather then EnumFontFamilies (gdi leak)
Bug 199443 GDI leak when table cell contains an image, and text is received in
multiple packets
Bug 203667 GDI objects overflow (Win) and X11 server size increase (Linux) when
reloading images by javascript

Bug 199443 has a nice tool in an attachment, GDIusage.exe, which told me that
BITMAPS are increasing.
I´m seeing this error for a long time on some websites, for example reading
forums at http://www.heise.de/foren/go.shtml?forum_id=7308&list=1&hs=0&e=all
Reading threads there you can see the GDI usage (Bitmaps) going up.
But I didn´t notice before, because I had no comfortable tool watching memory usage.
I didn´t see new leaks, only old leaks fixed.
So when did you notice leaking, after change from an old Mozilla release to a
more current? 
I update my nightlies nearly every day. I am not sure about when exactly this
started, I guess that it wasn't three as stated before but one to one and a half
weeks ago. I used that little program you recommended. Bitmaps do go up quite a
bit, I guess I come across this bug because I am on the internet quite a bit and
reload pages with lots of images on them quite a bit without closing the browser
over the day. http://www.lancs.ac.uk/ug/burmeist would be one of them. When I do
this often enough the GUI starts to disappear as described above.
The memory leak problem is an old one, but today with 1.4b seem much worse, and
I'm using Win2K sp2. I often visit pages with thumbs, then I shift + middle
button click each thumb to have the big image opened in another tab while
remaining in the main page. Then I go to the last tab and save the image
(ctrl+s) and close the tab (Ctrl+w). I must also add that the directory where I
save the images is a big one (> 4000 files inside). After a while, the Mozilla
screen seems not to be updated, if I press ctrl+S I can see the save dialog with
the correct picure, but after I press ctrl+W the screen remains the same.
I have to close and restart Mozilla.

I have the same problem with Mozilla ever since I started using it (more than
one year ago).

A couple of days ago I installed a tool that monitors the number of bitmap GDI
objects used by Mozilla.

I noticed that as soon as Mozilla no longer redraws bitmaps everytime I click a
thumbnailed image only two bitmap images were relased and one bitmap GDI object
was allocated. On returning to the page using the back-button the two handles
were allocated again but the new handle was not relased. It seems that as soon
as the bitmaps are no longer refreshed properly Mozilla is no longer able to or
does not release bitmap objects.

It seems that this bug is triggered if too many bitmap GDI objects of large
images are allocated too fast. It never happens when the images are small (i.e.
thumbnails). I have seen this problem too when many large images are loaded on
one webpage so opening the images in another window or in tabs is not necessary
in order to trigger this bug. A webpage that loads many large images triggered
that bug after using Mozilla for some time but it did not trigger that bug after
restarting Mozilla and going to the same page again. After I had used Mozilla
for some time I went back to that page and again the bug was triggered while the
images were still cached.
I've been having a lot of problems with the nightly builds of Mozilla Firebird
as well.  After using it for a while, the images on the toolbars of other
applications don't show up when a new window is opened.  Closing Firebird
remedies the problem.  I've also noticed general Firebird UI corruption -- the
window refuses to re-paint itself, smearing when scrolling, etc.

I thought it may have been my video card, but I just switched from the old ATI
to a Voodoo5, and it still happens.

I filed a bug a little while back that showed similar symptoms:

http://bugzilla.mozilla.org/show_bug.cgi?id=197077

Viewing the attached test case would cause the UI to corrupt in a similar way,
but I don't believe this is still happening with recent builds.

This happens quite frequently on my box, so if there is any info I can provide
to help track this down, please let me know.

Here is a GDI object monitor that works under Windows 2000 -- the one that was
referenced in a previous comment only works under 95/98.
I am currently experiencing some UI corruption with Fb.  Not the total UI
descrution I've seen before, but some icons dissapearing until I click on them,
noise patters in the toolbars, etc.  According to GDIObj.exe (that I just
attached), phoenix.exe is the top consumer of GDI objects with a total of 717. 
Here's the breakdown:

DC:      11
Region:  51
Bitmap:  559
Palette: 7
Font:    13
Brush:   75

This is after using Fb for a while, but now I only have one tab open.

What other programs are you running? I come across this especially, if I have
Mozilla Mail open and browse with Firebird.
Here are some of the top GDI handle consumers I'm running when things start to 
break down:

isqlw.exe (Query Analyzer): 649
wincvs.exe (WinCvs):        494

then it drops off significantly

iexplore.exe (Internet Explorer): 192
feedreader.exe (FeedReader):      163
aim.exe (AOL Instant Messenger):  156

I'll try to get a more accurate picture next time it happens.

I ran the testcase for bug 199433 with the GDIobj program on my laptop (XP pro
SP1, mozilla 1.3) and found that the totals given by it do not agree with the
totals in windows task manager. While GDIobj showed the totals to be roughly the
same, the  total for mozilla in device manager increased as long as the testcase
was running.

In my experience, windows XP does not start to experience graphical corruption
until around 10000 GDI handles are used*. 400-odd handles should present no
problems at all.

To display the total number of handles used in NT-based operating systems, open
the task manager program, select 'View'-->'select columns...', and check the box
for 'GDI objects'. I don't think that the GDIobj program is giving the correct
values in this case, and would discount any reports based on the results from
this program.

--

* Which I can confirm that mozilla does do. Certain webpages (the graphical
album list of globecom jukebox (www.globecom.se/jukebox)) cause mozilla to leak
thousands of handles per load. I've had it leak so many handles that XP cannot
display anything at all (not even the task manager to kill mozilla), and
effectively crashes the machine.

I suspect that comment 2 and comment 3 are symptoms of bug 199433
Ok, after running the test case over night, there was no leak.  The final
numbers are:

total:  87
dc:      4
region: 25
bitmap: 19
palette: 4
font:    3
brush:  32
other:   0

The GDI Object count from task manager was 92, which is close to the total
GDIObj shows given the +/- 3 bitmap fluctuation.  So it seems like there is no
leak in the build I was testing (20030511).


Ok, it happened again, this time with build 20030514.  I believe it started to
happen after I was running Fb for a while then launched WinCvs 1.2 (which is a
quite a GDI Object hog).  The object counts according to GDIObj were:

Total  Dc  Region  Bitmap  Palette  Font  Brush  Other
682    17  67      408     14       84    92     0

I let it run a little while longer to take some screenshots of the corruption,
and before I quit Fb the final counts were:

Total  Dc  Region  Bitmap  Palette  Font  Brush  Other
734    18  87      410     15       97    107    0

For the first time, Fb actually crashed while shutting down.  The talkback
incident ID is TB20126994G.

While I still had Fb open, other programs were acting up.  For example, I had
notepad open and all the text was invisible.

I will attach some screenshots of some corrupted web pages (seem like bold and
italic fonts were not showing up) as well as my process list (with GDI Objects
column)
Attached image Taskmanager durring incident — 

    
    

    
  

      
      
      
      

        Attached image
          
        IE got sick as well
        — 
      

    


  

    
    

    
  
I've been seeing this problem with build 2003050211 on win 98.
I've been Java programming with netbeans (http://www.netbeans.org/), and looking
up stuff on Java.
I've had to re-start a couple of times because of severe graphics corruption.

After some investigation, I found that the worst offending site for causing this
is Hardware Central (http://www.hardwarecentral.com/hardwarecentral/).
Navigate within this site, and you can easily use 30% of GDI resources.
At about 17/16% was seeing some corruption.

Builds from around Moz 1.2.1 period seem not to exibit this problem
(but my evidence is anecdotal)

I think the corruption is an attempt by win98 to get by with limited resources.
It seems to be able to triage resources, and discard them if possible.
I used to see this kind of leak with other progams including IE, and swithed to
Mozilla to avoid it.

I suspect that the GDI leaks on HW Central may be caused by bug 199443.
I am commenting here, because I'm not convinced that this is the case.

    
    

    
  
With Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030507, I'm
experiencing exactly the same problem. Most of the bugs already open don't
explain it, since this is vastly worse under 1.4b.

I used to be able to run 1.4a for days and only get low on GDI resources. With
minor use of 1.4b, my Win98SE machine goes from 72% to 0% in a couple of hours.

There's really no choice from my perspective but to go back to 1.4a until this
is fixed.


    
    

    
  
I agree with the comments above that this has gotten MUCH worse recently.  Using
Mozilla 1.4b Build 20032051408.   Confirming and Changing status to NEW.

Mozilla can take me from over 70% available System resources and over 80% GDI
resources down to ZERO with about 10-12 tabs (often in 2 or more windows) open.  
None of the pages are particularly large.  

I never get back the last 8-10% of each after closing Mozilla.  Have to reboot
at least twice a day to get through the day, where I never had it this severe
before about May 1, 2003. 

I'm going to add the REGRESSION keyword.  Also adding DATALOSS because you can
get so low on resources you have to reboot and lose all the pages you have
displayed, including form submissions.

Also requesting BLOCKING 1.4 status.  This is really severe on my machine.  No
way should we release a final 1.4 version with this bug!

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.4?
Keywords: dataloss, 
          
            regression

    
    

    
  
I fully agree with, and support, comment #19.

I have Win98. I read slashdot every day using tabs (10-12 tabs open
simultaneously), and GDI resources go below 10%. If I try to open pages linked
from the articles, I usually get a unstable windows and I have to reboot.
pre-MAY builds didn't show this behaviour. A 1.4 release whith this problems
will be a disaster.

    
    

    
  
Update:
All tests done using build 2003050211...

Tried the test URL included in bug 199443
(http://homepages.inf.ed.ac.uk/s9902074/mozilla/bug.php).
Didn't see any GDI leak at all.

Tried a workaround for bug 1994433: set
user_pref("browser.cache.memory.enable",false); in user.prefs file.
Success!
On navigating hardware central, saw a leak of >400 new bitmap GDIs (As reported
through GDI Usage tool) when navigating through
over 30 HW central pages, with memory cache on. With memory cache off, new
bitmap GDIs peaked at 77, therefore not a leak?

I'd be interested to know how turning off memory cache affects other users: I
noticed no discernable difference in performance with memory cache off/on with
win98.


    
    

    
  
I don't think that disabling memory caché would be an aceptable workaround. I'm
a bit masochist and rather prefer to "see" the problem than to ignore it or
"workaround" it.

Don't cache GDI objects (I don´t see better display performance in recent
builds, by the way) or limit caching when resources are low would be nice :-)

    
    

    
  
Another Update:
Once agin with build 2003050211...

Disabling memory cache does not improve GDI leaks caused by multiple tabs, as
described in comment #19.

P.S. Should someone start adding the related bugs mentioned in the comments
to the "depends on" field??

    
    

    
  
*** Bug 207061 has been marked as a duplicate of this bug. ***

    
  
Depends on: 192342, 199443, 203667

    
    

    
  
Jim - you say in comment 19 that you have found another bug that appears when
opening tabs. It appears that you are using windows 9x. If this is the case,
could you please download 
http://bugzilla.mozilla.org/attachment.cgi?id=121792&action=view
and try to reproduce the bug?

To use the tool, open mozilla, open the tool, and press 'take snapshot'.
Play with mozilla until the symptoms become apparent, and then press 'compare'.
This should show what type of resources mozilla is using.

If opening a new window and closing all the other ones (then pressing compare)
leaves a large number of objects allocated vs when mozilla was initially opened,
then it has a leak. If all the objects go away again, it is merely using large
amounts of resources. (I suspect the former, as you said closing mozilla doesn't
free them all)

bug 199443 presents itself as a leak of bitmap objects - pressing 'view' to
inspect them shows them to be images used on the webpages visited (often the
same image is repeated hundreds of times).

bug 198816, which I haven't tested on windows 9x, may be a cause of this. IIRC,
it causes mozilla to leak 4 region objects per window, but I don't have a 9x to
test it on at the moment.


As an aside, I don't believe the regression keyword is appropriate for this bug - 

Says http://bugzilla.mozilla.org/describekeywords.cgi
---
regression: The problem was fixed, but then it came back (regressed) and this
new bug was filed to track the regression. Also, for problems outside those
identified in precheckin and smoke tests that were found in current builds that
were known know to be working in previous builds. Tracking these bugs will help
us to identify areas that are fragile, prone to bustage and are good candidates
for adding to smoke and pre-checkin tests.
---

This would not seem to be a problem that was fixed and came back again (If you
take the view that anything that was previously working but now isn't is a
regression, then anything that isn't an RFE is a regression.) On the other hand,
a smoketest for memory and resource leaks might be useful (but may raise the bar
too high for a smoketest).

    
    

    
  
*** Bug 206929 has been marked as a duplicate of this bug. ***

    
    

    
  
Based on the comment above about disabling the memory cache I have discovered
that Firebird still uses a lot of the resources but most of them are returned
when the tab is closed.  If the cache is enabled the resources are not returned
until the task is closed.  This seems like a reasonable approach.  The problem
is that it in the past month or more the consumption of resources has increased
substantially.  Such that I can't run a normal (to me) session without
encountering problems.

I am running WinME, and Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.4b)
Gecko/20030522 Mozilla Firebird/0.6

Additionally I used the GDIUsage.exe to look at things in a little more detail.
 I ran two passes.


#1a
Prior to opening Firebird compared to after opening 11 Tabs.  My resources were
100% gone when the tabs were open, and many of the later tabs were not
displaying correctly at all.
New	Same	Free
834	32	0
120	51	0
0	9	0
0	4	0
5	20	0
215	28	0
91	54	2
0	3	0
0	0	0
0	0	0
0	0	0
0	3	0

#1b
This is after I closed Firebird compared with prior to opening, Almost
EVERYTHING was returned.
New	Same	Free
0	32	0
0	51	0
0	9	0
0	4	0
0	20	0
1	26	1
6	51	6
0	3	0
0	0	0
0	0	0
0	0	0
0	2	0



#2a
Next test.  I opened Firebird, opened one page and took the snapshot.  I then
opened 10 more tabs, bringing me down to 9% free System & GDI.
New	Same	Free
664	132	0
88	81	0
0	9	0
0	4	0
1	24	0
179	36	1
88	75	5
0	4	0
0	0	0
0	0	1
0	0	0
0	3	0

#2b
Now I closed those 10 tabs and left Firebird and the original tab open.
New	Same	Free
2	129	0
16	74	11
0	9	0
0	4	0
0	23	0
2	35	1
8	75	6
0	4	0
0	0	0
0	1	0
0	0	0
0	3	0

For the most part you can see that not too much has leaked and I have returned
to 73 and 78% free system and GDI.

    
    

    
  
The resource consumption problem seems more serious when I also run MailNews and
Composer, which is most of the time.  I also run Norton Antivirus and it scans
incoming and outgoing emails.

Just had Mozilla take me down to 14% System and GDI from 70-80% over a couple
hours.  Closing all the tabs but one only got me back to 30%.  Closing the last
browser window got me back over 70%, still 8-10% less than a clean boot. 

I'm trying to collect some hard info with GDIUsage.exe 

    
    

    
  
Getting resources loss on the Win 95 platform as well with 1.4b.

GDIusage.exe program shows ever increasing Bitmaps, Regions, Brushes, MemDC and
Fonts as surfing progresses. Utlimately screen gets wierd. Last happened surfing
http://linuxtoday.com but cannot verify that this site is particularly good at
bring out problems. At that point, Mozilla mail also get corrupted with wierd
fonts, badly formed windows and widgets. 

The 'Details' button of GDIusage.exe does show many 'invalid handles' as surfing
progresses.

Closing 1.4b brings GDIusage.exe numbers back to prelaunch values in tests so far.

On one occasion, got a blue screen with a 006 fatal exception but can not repeat
this yet (or it may be unrelated to GDI issues). (running with 256meg RAM)

    
    

    
  
Just a reminder that I've seen this bug in Win2k as well.  One thing that I find
is that on my laptop (Delll Latitude CS, NeoMagic MagicMedia256ZX video) is that
Fb can be using over 1,200 GDI handles (as per Task Manager) and everything is
fine.  However, on my computer at work (Voodoo5 video), I get the
corruption/resource problems when Fb has only 400 handles or so.


    
  
Keywords: nsbeta1

    
    

    
  
Just had Fb crash shortly after the standard symptoms described in this bug. 
The talkback incident id is TB20584699G

Another symptom I've seen of this bug is the almost-infinitely huge web page.  I
load a normal webpage (say slashdot) and both the horizontal and vertical
scrollbar handles are tiny.  Clicking the gray area next to the handle (to
advance a page horizontally or vertically) does not move the handle at all --
the page is REALLY big.  I can scroll to the top and bottom of the page, but it
is a long way.  I'll attach some screenshots.


    
    

    
  

      
      
      
      

        Attached image
          
        Huge Slashdot page
        — 
      

    


  
re: my previous comment

    
    

    
  
-> smontagu
Assignee: kmcclusk → smontagu

    
    

    
  
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-

    
    

    
  
*** Bug 207734 has been marked as a duplicate of this bug. ***

    
    

    
  
I believe that Talkback # TB20623160x is a dump caused by this bug. Symptom
which triggered the dump was a crash after a print failure fram an earthlink.net
web mail access pop-up window.

    
    

    
  
1.4b RC1 (Gecko/20030529) still growing GDI resources relentlessly.

    
    

    
  
Mozilla 1.3.1
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3.1) Gecko/20030425
Is doing the same. Using the GDI resources relentlessly.  Quitting and
restarting Mozilla occasionally is a workaround, that frees things up.  I was
not aware of this problem until I moved up from 1.21

    
    

    
  
*** Bug 205799 has been marked as a duplicate of this bug. ***

    
    

    
  
Good day, everyone!  I am delighted, in a way, to find this bug.  For the past,
oh I don't know, year or so, I have been dealing with an issue on my workstation
whereby windows (many/all applications) stop being able to repaint their windows
correctly after several hours of workstation usage.  For the longest time, I
thought that the issue was related to my video card, or more to the point, the
video drivers.

Two things made me think it was not related to any specific application: 1) Many
applications were affected, and 2) I have an "unusual" display configuration of
three 1600 x 1200 x 32b displays powered by a single nVidia Quadro4 NVS 400.  I
sort of "naturally" drifted toward focusing the blame on my video configuration.
 But just you try to downgrade from 4800 x 1200 once you're addicted.

Anyhow, curiously enough, I have been using Mozilla for much longer than I've
had this video card.  I can't say for certain when the issue really
started--previously I thought it coincided well with the installation of this
video card, but I can't really rule out the fact that it could have coincided
with the installation of some new (at the time) release of Mozilla.

Basically, what happens on my computer is that after about 3 or 4 hours of
usage, applications begin failing to paint the contents of their windows.  The
window frame is correctly painted, but none of the contents.  If I drag the
window off the bottom of the screen and drag it back up, sometimes I can force
the contents to be repainted.  Sometimes, though, this just results in one of
those funny-looking window painting scenarios where the you see a "rippled" wave
of repeated content.

The applications most readily affected are Mozilla, Eclipse (SWT error, baby!),
Trillian (and Yahoo Messenger), and my e-mail client, AK-Mail.  Of course, these
are the applications I most often have open, so who's to say, really?  If I let
the problem persist for a while due to a reluctance to reboot every 4 hours,
other applications will start failing as well.  For example, Microsoft Excel. 
And, in general, just about every application will eventually be unable to
repaint their title bars correctly.

After dealing with this issue for so long, I would be on one hand bummed that
Mozilla is at fault (if it is), but on the other hand, so delighted to see it
vanish (if it can be made to vanish).  I hope it -is- Mozilla, because, well,
there's Bugzilla.  If it's nVidia's drivers, I don't think they offer a
bugzilla.nvidia.com.  :)

I don't know if I can help the effort to fix this bug much, but I can definitely
run some tests with the GDI object monitor on my bizarre box if anyone can tell
me the scenarios that would be fruitful to test.  Good luck to the people
working on this bug and thanks!

    
    

    
  
Hang noted in comment 19.

This is a very serious bug. It leads to instability, and furthermore makes
Mozilla look really bad. Should be fixed for 1.4.


Keywords: hang

    
    

    
  
Brian Hauer (comment 40):

You didn't mention which versions of Windows or Mozilla you're running.  This
bug specifically addresses a worsening of the resource problem sometime around
May 1.  (If you're not using a recent build, I'd suggest you DON'T upgrade as it
could make your problem worse!) 

You mention that you've had the problem for about a year, so it's not this bug. 

Your problem is a textbook example of running out of resources, but it wouldn't
surprise me if your video configuration would be very likely to cause that.  
You've got a lot of objects open on a desktop that big.

Most of the reports on this bug appear to be Windows 98 or ME.  

Some additional info:
My video card is NVidia GeForce2 MX, and updating my drivers didn't help.  

By the way, I'm pretty sure this problem started between releases 20030422 and
20030507.  If comment 38 is correct, the patch causing it was checked in to the
1.3.1 branch on or before 4/25/03.

    
    

    
  
Jim-- Thanks for the response.  I'm running Moziall 1.4RC1 (generally, I always
run the most recent build available on the Mozilla home page) on Windows 2000
Server SP3.  I hear what you say about this bug pertaining to a worsening of the
situation since 1.4, and the general GDI resources issue I described has
-definitely- affected affected me since way before Mozilla 1.4.  To be honest, I
wouldn't really say that my environment has been any more or less reliable since
installing v1.4.

I have used dozens of nVidia driver releases since the problem started (again,
for me, it may be a general GDI resource problem that is well beyond the scope
of this bug).  Incidentally, if anyone knows of a way to dramatically increase
the size of the "pool" available for GDI resources on Windows 2000, I'm all ears
for some off-line correspondence.  Thanks!

    
    

    
  
*** Bug 208149 has been marked as a duplicate of this bug. ***

    
    

    
  
Jim,

I just wanted to add that I agree that somewhere in this thread the discussion
focused on the worsening of the GDI resources problem.  And it has, most
definitely.  Yet it has always been an issue, just not this bad.  And the title
doesn’t specifically state it as a regression or worsening lately.  Not that any
of that matters other than to say I do think the issues are one and the same.

Now, on Win9x the amount of resources available (system and GDI) I believe are
limited to 64K, that amount can’t be changed, and it is significantly less than
on Win2K/XP.  I suspect this doesn’t crop up as an issue for most people running
those OS’s.  But the issue and problems are the same.

Lastly I want to re-iterate that disabling the caching has helped the problem
significantly for me.  The browser still uses just as many resources, but when
that tab is closed they are freed up.  Prior to that they would only be released
when the entire browser was closed.

Regardless 8-10 open tabs and I can be toast.  Once things hit the limit I don’t
think it ever fully recovers.  I suspect that some other tasks or system
processes need a resource and can’t get it, they are then forever messed up.

So I whole heartedly agree that this has become a sever problem and reflects
very badly on the whole browser and needs to be fixed.  I do hold out hope that
most casual users never use the browser to the extent I (we) do and don’t really
encounter the problem.  For instance my wife has never had an issue with it. 
Generally she doesn’t use more than one tab and she is running XP.


    
    

    
  
Re: comment 42

I've been following this bug for the exact same reason that Brian Hauer (comment
40, comment 43) is.  Over the past year or so, I've noticed a great tendency for
my computer to run out of resources very rapidly.  I spent a long time tweaking
with my settings and fiddling with video drivers and so forth to no avail. 
However, I finally realized that Mozilla was the primary culprit (certainly
there are other resource hogs, but Mozilla is the worst offender, especially
given the fact that I tend to view several websites at the same time). 
(Currently running Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b)
Gecko/20030529 Mozilla Firebird/0.6, though this has certainly not been limited
to this build, and I've been experiencing difficulties for quite a very long time)

What I have found is that each website that is open (either through additional
tabs, or via new windows), especially sites with extensive images gobbles a ton
of resources, even if the page is not currently the visible window (hidden or
minimized).

Perhaps this needs to be filed as a brand new bug, but the summary of the new
bug would be identical to this bug "GDI Resources are used till the  UI/website
displays faulty" (which is why I added myself to cc and voted for this bug
rather than creating a brand new bug that probably would have simply been
described as a duplicate)

I'm not familiar with filing attachments or test cases, so I'll just describe
what will consistently wipe out 60% of my system resources:

I have a group of tabbed bookmarks that I title "News" which consists of a
series of websites devoted to news.  The sites are (in order):
http://www.cnn.com/
http://msn.espn.go.com/main.html
http://www.signonsandiego.com/
http://www.washingtonpost.com/
http://www.timesonline.co.uk/
http://wwwa.accuweather.com/adcbin/public/local_index.asp?zipcode=92054&partner=accuweather
http://www.weather.com/weather/local/92054?lswe=92054&lwsa=WeatherLocalUndeclared

I haven't been able to open this set in a very long time and have resorted to
opening one at a time (kind of defeats the advantage of having tabs for me)

When I DO try to open these in tabs (choose "Open in Tabs" from the Firebird
menu, or simply clicking on the grouped tabs in Mozilla), the tabs open and
begin to load.  By the time they are finished, my GDI resources drop from 70% to
0% and the entire computer becomes unusable: icons vanish or turn into
gobbledeegook, the desktop becomes completely hosed, the fonts revert to some
sort of funky system font, mozilla toolbars and menus vanish, and so forth. 
Exiting Mozilla restores the resources (according to Resource Monitor) but the
graphics remain hosed... once you've used 'em all, you can't fix the issue
(note: the resources are NOT freed up if I wasn't using the workaround for
leaking resources of turning off the memory cache that is listed in this bug). 
Note: this was done with ONLY resource monitor running in addition to Firebird.
 All other applications were closed first.  The system runs out of resources all
that much faster with even one or two other applications open.

So, there may be two bugs as I see them, but they both lead to the same problem:
1. Running with the memory cache turned on causes resources to leak out over
time (according to comments, apparently related to images that appear on web
pages within table cells) (this is fixed via the workaround of turning off the
memory cache within user.js... see the comments somewhere above)

2. Each page gobbles a ton of GDI resources whether or not it is currently
visible such that a very small number of websites being open in new tabs or
windows (in this case, 7 pages) can wipe out all the resources (70% to 0%)
(this is not eliminated)

Anyway, just my thoughts... if you feel that a new bug needs to be filed, let me
know and I'll file it, though perhaps more descriptive summaries would be in
order.  If you feel that both bugs listed above should fall under the summary of
this bug report as it stands now, then that's fine, too.


    
    

    
  
I'm going out on a limb and raising the severity to BLOCKER to try to get
someone's attention on this.  

Please make sure you have VOTED FOR THIS BUG at
http://bugzilla.mozilla.org/votes.cgi?action=show_user&bug_id=204374.  That
helps too. 
Severity: critical → blocker

    
    

    
  
Alan-- It sounds as if you're running on a Windows 9x operating system.  Is that
correct?  I think, though, that this issue may still be relevant to NT-based
operating systems.  I am running Windows 2000 Server and have run into this
issue (or, as Alan points out, an issue so closely related that it could
reasonably be declared a dupe of this bug) daily for essentially a year.  That
is to say, way before Mozilla 1.4.

I am not entirely ruling out the fact that Windows itself may not be properly
designed to cope with a -very- large desktop and lots of open windows, but I do
still have a hunch that this bug is indicative that something is awry with
Mozilla.  As I mentioned before, I cannot say with certainty that this issue has
actually been notably worse with 1.4 versus previous versions.  But--and this is
an important aspect I should have mentioned earlier--I can say with confidence
that I -always- encounter the first symptoms of this issue while using Mozilla.
 As Alan points out, once Mozilla clobbers Windows' GDI pool, other applications
get cranky and never fully recover.  You can get a few more hours of usage out
of the workstation by closing Mozilla and restarting, but the problem just
builds over time.  Eventually, no apps can paint correctly.

I, too, use tabs religiously and I open just about ever hyperlink in a new tab.
 The more tabs I open, the greater risk I run of witnessing painting issues. 
Having about 10 tabs open is "danger" territory.

I may install Windows XP Pro on this machine in the near future.  I would like
to be able to determine if XP is susceptible to the same issue I am dealing with
or not.

    
    

    
  
Okay, I can DEFINITELY say that I have not seen this condition on any previous
version of Mozilla.  I definitely never encountered it with 1.2, and although I
had some flakiness with 1.3, it was certainly not as bad as this, and may or may
not have been the same problem.  My point:  In eralier versions of Mozilla, I
could open about 50 tabs (REALLY!) and operate quite happily on my 98SE machine.
 With 1.4, I cannot open many more than 20 tabs, and all three resource
categeories (Sys, GDI, and User) decline to exhaustion.  YES, this problem has
gotten very much worse with 1.4.  (And YES, ordinary users use piles of tabs,
including my non-techie wife.  It would be a shame if one of the best features
of Mozilla was only of limited usefulness.)

    
    

    
  
Brian,

Yes I am running WinME (I detailed that back in comment #27, sorry I didn’t
repeat it).  I am getting ready to upgrade my machine to WinXP.  I had been
trying it out on my wife’s machine.  I still have some issues, but it’s about
time to take the plunge anyhow.

Either way I suspect your Win2K box is essentially the same as WinXP as far as
resources are concerned.  However, as someone else asked earlier, there may well
be a way to increase the amount of space allocated for this in Win2K/XP.  I
don’t have the answer there for you though.

I don’t have the luxury of your 3 screen system (single 16x12 display – nVidia
TNT2 card).  So you might well have a larger problem down the line.

Anyhow, to provide a comparison I decided to open my set of “Daily” tabs that
used to be ok, but now drag me down to 3%!!  So I recorded my System resources.
 That is System Resources, User Resources, GDI Resources, as displayed with
Resource Meter.  I then opened the same 8 pages in IE 6.0 (separate windows). 
See the list below:

73/73/84  Start
70/70/80  Firebird Opened
3/63/3    Daily Tab Opened

http://www.dslreports.com/
http://slashdot.org/
http://www.tomshardware.com/
http://cgi1.ebay.com/  (edited- my ebay page).
http://www.dpreview.com/forums/forum.asp?forum=1010
http://www.theregister.co.uk/
http://www.newscientist.com/
http://www.crowfamily.org/kwsn.shtml

62/70/62  All tabs but DSLReports closed
70/70/83  Firebird Closed

(starting out a hair lower as some resources appear to be unrecovereable)

67/67/79  IE Opened
61/61/68  8 Blank IE Windows

49/49/59  Same Pages opened.

I noted that the resources quickly (two windows) dropped to 50% range, but
really didn't go any farther down.  And as pages get covered some of the
resources are returned.  It seems that Mozilla uses the resources continually,
while IE may only consume the larger portion of them when the actual window is
displayed.

71/71/83  Everything closed again.

    
    

    
  
This might be related to bug 184933, "loading lots of images makes moz forget to
repaint everything".

    
    

    
  
Let's focus on what's causing this, and how to fix it. We know it's it's an
inefficient use of system resources. Footprint.
Keywords: footprint

    
    

    
  
Right, following on from Andrew's comments.....
What do the developers need from the reporters to help fix the bug?
And more importantly, what do the developers *not* need from the reporters?

For instance, do the developers really need any more URLs to be added to fix
this bug?
Also, are reports of GDI monitor dumps useful for anything beyond prooving the
leak exists?

I'm going to follow this bug closely as I've had similar problems in windows
programs I've developed.

    
    

    
  
Bug 184933 was also put forward as possible dupe against 133132.
In bug 133132 there are suggrestions that some resource/memory leaks have
been fixed.
I therefore tried build 2003060305 from 1.4 branch.
I still see this bug in this version.

    
    

    
  
Could this be related to bug 198806 (1.4 blocker) ? Does the image-reference
hold a GDI resource ?

    
    

    
  
Further tests with build 2003060305 from 1.4 branch...

Tried the about:cache stuff from  bug 198806.
Couldn't reproduce the memory cache going over limit.

Did see a couple of interesting things though:
1. When memory cache was almost full, the GDI resources were almost gone.
2. When the memory cache was almost full, doing a refresh on about:cache showed
the cache usage decreasing for a couple of seconds. Didn't see any GDI release.
3. When tabbed browsing, the resource consumption for tabs was greater with
memory cache off than on.


    
    

    
  
Rob,

Thanks for looking into things a little more.  I have been running with the
memory cache turned off as it seems to return the resources as each tab is
closed.  However, I just re-tested thigns and discovered exactly what you did,
that in fact the browser uses far fewer resources when the memory cache is
turned on than when it is off.  And interestingly with this test at least, it
does seem to return some (but not all) of the resources when tabs are closed.

    
    

    
  
I'll post one additional clue for those following along at home,
and for developers still looking for clues:

Win98 machine, running Mozilla 1.4RC1, 2003052908

Run resource meter.  Launch Mozilla.  Browse until your meter
drops to yellow.  Go to Edit->Preferences->Advanced->Cache.
Clear your cache.  See the meter go green.

Apparently the resources in contention are tied to the cache
in a very physical, deleterious manner.  Now go fix it!


    
    

    
  
I think bug 196182 could be the same issue.

    
    

    
  
Crazy thought just occured to me:
Could this problem be as simple as the memory cache being set too large?
Has anyone tried decreasing the memory cache limit, then doing the usual tests?

    
    

    
  
AFAIK, the caching of images allocates GDI handles which are not released when
you leave a page or close a tab. This is done by design, so gecko does not need
to reload and decode the image when you return to the page. The memory cache
controls how many images are cached so setting it to a low number should also
decrease the GDI handle usage. Win98 and WinME have a smaller pool of GDI
handles so if the memory cache is large your system may run out of GDI handles
before it runs out memory cache. To solve this on Win98 and WinME there probably
needs to be a maximum number of images that may be cached instead of basing it
on memory consumption to avoid consuming to many handles.

    
    

    
  
*** Bug 196182 has been marked as a duplicate of this bug. ***

    
    

    
  
Re comments 60 and 61:
If the memory cache needs to be made smaller for Mozilla to not use all
resources and kill your machine, then it's still not "simple". Either every
Windoze user needs to get full information on how to configure it not to do
that, or Mozilla needs to be fixed so that it configures itself appropriately.

Since this problem is new to 1.4b, removing whatever was inserted since 1.4a to
cause it seems like a much better solution to me.


    
    

    
  
Thinking about the suggested workaround (disable cache), I've just tried an
idea, and it works: When your GDI resources are running out, go to mozilla's
Preferences/Advanced/Cache and press "Clear Cache" button. Tipically you recover
a lot of GDI resources.

In any case, this bug is SEVERE and a Mozilla 1.4 release with it will be a
complete disaster. We are already running "release candidate" versions and the
issue smells fishy :-(

Reporter, could you posibly mark the bug as "1.4 blocker"?. Problem is big
enough to justify to make some noise.

    
    

    
  
I don't think it's a new problem, but fixing bug 105344 has made it worse. Since
the memory cache is now much larger than before (mine went from the default 4MB
to 9MB), we'll keep many more GDI-resoruces in memory.

The size of the memory cache is now calculated automatically (see about:cache),
but you can still set back to the old default by setting
'browser.cache.memory.capacity' to 4096. You'll probably have to create the
resource in about:cache first.

PS: see also bug 205893

    
    

    
  
Well, on my 720MB machine going back to 4096K has brought performance back
to near what I used to experience.

For instance I can now open > 36 tabs from www.theregister.co.uk site before
GDI reaches 20%, would previously be low, or gone.

I also now notice the problems mentioned in bug 198806. For instance, with > 36
tabs open, Cache is as follows:

Number of entries: 	168
Maximum storage size: 	4096 k
Storage in use: 	16764 k
Inactive Storage: 	0

If I added 5 tabs from the new stories on the Fotrean times website, I'd get
the following:

GDI at %7,

and Cache as follows:

Number of entries: 	261
Maximum storage size: 	4096 k
Storage in use: 	19115 k
Inactive Storage: 	0 k

Non-tab tests:
Navigating HW central now seems to result in minimal GDI consumption, stays
between 50-60%. Cache remains below it's maximum.


    
    

    
  
*** Bug 201221 has been marked as a duplicate of this bug. ***

    
    

    
  
This was a huge issue with me when i had 2 monitors and video cards.  i removed
one of them and it works ok now.  it only crashes when i have like 15 different
copies of mozilla up.

    
    

    
  
Jo Hermans, Comment #65: 

I think you're on to something!   I think the fix to Bug 105344 is causing this.
 Setting browser.cache.memory.capacity to 4096, I was able to open 20 tabs in
each of 2 browser windows.  

I'll post a comment in Bug 105344.  If someone can verify this, I think they
should REOPEN Bug 105344.  

To review the steps to try this:
1. browse to about:config
2. scroll down and look for browser.cache.memory.capacity.  (It shouldn't be
there, but if it IS, right click, pick modify and change to 4096. skip next step.)
3. right click, pick NEW, pick INTEGER, type in browser.cache.memory.capacity,
click OK, type in 4096, click OK.  
4. restart Mozilla.

    
    

    
  
Haven't we kinda known this for a while? Somebody said a long time ago that the
workaround was to turn off the memory cache.

Anyway, let's keep in mind that this problem wasn't created by bug 105344, just
exacerbated by it. This behavior has been around for awhile. Backing out of
105344 shouldn't be considered a permanent fix, if it comes to that.

Also, it's not just Win9x, contrary to some of the comments here. It's been
reported on Win2K and XP.

    
    

    
  
My point (Comment 69) is that the cache size is getting set too agressively
(large) now, and that the OS should be taken into account when setting the size.
The time of the fix to Bug 105344 seems to coincide with the major worsening of
the symptoms this bug mentions around May 1.

My 384MB Windows ME machine was defaulting to over 18K memory cache size.  

It's not necessary to turn the cache off, just set it smaller.

    
    

    
  
Regarding Comment #70 & #71:

We've been skirting round this issue for some time:
We discovered that turning the cache off improved GDI performance in some areas,
but degraded it in others.
What's new is the discovery that a smaller cache gives better performance than
either no cache or a large cache.

Regarding what should be done, these would be my suggestions to the developers:

1. As a temporary fix, back out Bug 105344, or intoduce upper bounds to it's
   algorithm.
2. Investigate either a. not cacheing GDI handles, or b. limit cache entries
   to number of GDI handles.
3. Investigate resource consumption for multiple tabs.
4. Investigate single pages with high GDI consumption.
5. Investigate any GDI leaks.

That's a lot of work, but my guess is that only 1. & 2. are necessary.


    
    

    
  
Keying in browser.cache.memory.capacity into about:config and setting it to
something less tha the algorithmic default of 18m (6.25% of max my ram of
256Meg)is not a cmplete solution. I tried 7024 K. When I loaded
http://www.exactaudiocopy.de/ (which has a big image), the memory cache expands
beyond 7024 and stays that way ( use about:cache to see size ), so number could
get bumped up to a large value (which would the cause GDI problems later) in any
case. This test done on Win 9x. 

As  a minor aside, the old Netscape 4.79 runs just fine all day on a memory
cache of 7024K and 0 disk cache (although it seems to ocassionally ignore the 0
disk cache and write .css files there every once in a while). 

In hunting over various bugs related to this one, I see that there once was a UI
to set memory cache value for Mozilla (Netscape 4.79 has a UI for this) but it
was removed from Mozilla. Why?

    
    

    
  
@ comment 73 : The UI to set memory cache value for Mozilla was removed from 
Mozilla because someone thought it was a good idea to reduce UI Bloat and use 
allways a certain percentage of memory, leaving Users who wanted to force Mozilla 
to use fast virtual memory instead of slower disk cache or who have a network 
connection faster than their virtual memory on disk (laptops) standing in the
rain. To reintroduce the UI makes sense to me beyond a workaround for this bug.


    
    

    
  
...okay, so there used to be a UI for cache size and now there isn't.  But how
much will restoring this UI help the average user?  Look how long the vested
group took to figure out that the resource problem was linked to cache - and how
many pairs of eyes it took, working in concert, to make the connection!  What
chance does the solo user have to find this correlation?

No, Mozilla needs to deal with this problem automatically.  It should not be so
hard to determine tolerable limits for differnt OS types and establish a
reasonable default for each target OS.

    
    

    
  
Would someone please go over to Bug 105344 and help me get someone's attention
there.  I don't know if anyone in a position of authority is yet working on this
problem.  Reopen 105344 if you feel that's justified.

    
    

    
  
The underlying problem is that our memory cache should not store GDI handles.
Keep images in memory if needed, but only create the GDI handle when we actually
have an image frame that needs drawing. GDI resources are much more limited than
memory... even with 1GB RAM, the winGDI systems impose a finite limit on how
many handles can be allocated.

    
    

    
  
There are many old bugs, dating back even past one year, that seem to fall under
the "memory cache should not store GDI handles" rubric. (See previous comment.)
I'm thinking we should dupe them all to this bug, as it has the most information
on the problem. Or set them all to depend on this bug? I'm uncertain. Somebody
make a decision.

    
    

    
  
It would seem the the appropriate fix lies somewhere between: 

1) post #75 [Mozilla should set memory cache automatically], 
2) post #76  [would someone reopen bug 105344 - which was the discussion of what
percentage of max RAM should be used for an automatic memory cache sizing algorithm]
3) post #77, 78  [GDI handles shouldn't be in the memory cache because when the
cache is big, GDI resources become overloaded in many of the platforms]
4) post #73 [there should be a UI for memory cache size (as in Netscape 4.79),
which UI has explanation of why use it,  for concerned people standing in the
rain (as opposed to sbout:config insertion of browser.cache.memeory.capacity for
nerds and tweakers).] The UI would set memory cache value different from an
algorithmic default value for people who have memory to burn and want to
optimize/force rendering speed by setting memory cache high and disk cache low.
5) post #70 [a rather thorough formulation of all the possible contibutors to
the problem]

So the decision variables are: who fixes, which of the fixes and when?

What can reporters do to move this along?

    
    

    
  
BTW, I just tried the prescription in comment #58 (use
Edit->Preferences->Advanced->Cache->Clear Cache to temporarily release GDI and
System resources), and it DID NOT WORK for me.  As far as what is documented in
comment #58, I am running the exact same configuration as Christopher Wanko. 
Why it worked for him and not for me, I do not know, but anyway, here's a little
more mud in the water!

    
    

    
  
CCing gordon@netscape.com, cacheqa@netscape.com, benc@netscape.com, &
mkaply@us.ibm.com, who were involved in implementing Bug 105344 so they can see
what problems they've caused.

    
    

    
  
*** Bug 208712 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 208086 has been marked as a duplicate of this bug. ***

    
    

    
  
For writer of comment #80 <http://bugzilla.mozilla.org/show_bug.cgi?id=204374#c80>:

Run rsrcmtr or another resource metering utility.

Run Mozilla, browse some big pages like your eBay account, a handful of Amazon
pages, maybe six c|net news pages.

Check your resource level.  It should be off the green map now, down in yellow
or worse.

Goto Edit->PRef->Adv->Cache clear your cache.

Resources should imrpove, if not to green then to something higher than what it was.

My cache has been set at 16 Megs for a week now.  Not that I see any big
improvements, but at least I get some benefit of caching and not too many
handles can (potentially) be used.

And for those playing at home, my about:cache settings are 16 Megs apiece, 
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030529, on Win98SE 4.10.2222A





    
    

    
  
Re:  Comment 84:  No, this DOES NOT WORK for me.  As I have already remarked
(comment 80).  As my comment #80 indicated, I already tried this and it had no
effect.  I have now turned cache off, and initial results indicate that I am
receiving some relief.  I will post again if this is really effective for me.

    
    

    
  
Christopher, try this:

1. Navigate, observing GUI usage.

  **IMPORTANT** Do not open lots of windows, but reuse them. That is, try to
navigate thru 20 pages using online 2-3 windows/tabs, for example.

2. GUI resources will go down.

3. When resources are low, use the "clean cache" tip as indicated in #64.

The important issue is that MOZILLA *DOESN'T* release GDI resources when you
close windows. This workaround seems to do it.

But if you open zillions of windows, without closing them, there is no wai
cleaning up the cache to release GDI handles.

So, current Mozilla has two problems:

1. No timely release of unused GDI handles (in cache).

2. Open windows/tabs eats too many GDI resources. I can crash mi OS (win98)
opening about 20 tabs, for example.


    
    

    
  
...there's always one:  I disabled cache
(about:config->browser.cache.memory.enable=false), and ran out of resources even
quicker, and it behaved worse, too:  Display was even more wacked-out (e.g.,
systray developed a white background color), AND I got the "Low Resources"
dialog, AND my Win98 hung.  I am using Win98Se, Mozilla 1.4 [Mozilla/5.0
(Windows; U; Win98; en-US; rv:1.4) Gecko/2003052908].

Sorry, but I am not totally buying the "cache is at fault" explanation.  Cache
is clearly part of the stimulus chain, but my guess is that the problem preceeds
that caching step in the code.

    
    

    
  
We already know that no cache can be worse than some cache.
Try setting your memory cache to a smaller size.
See comment #69 for how to do this.

Comment #56 descibes the first time I saw worse perfomance with no cache.
How does that compare to what you a seeing?

It might be worth reviewing the all the comments on the bug so see if you missed
any other hints. There's gold in them there comments ;-)


    
    

    
  
Rob said
>------- Additional Comment #88 From Rob North  2003-06-12 09:50 -------

>It might be worth reviewing the all the comments on the bug so see if you missed
>any other hints. There's gold in them there comments ;-)

I don't think so. We are testing, we are not looking for a workaround.  This
problem needs to be fixed.  Not minimized.  

    
    

    
  
I'd rather have a tete-a-tete than a tit-for-tat, but I feel that I need to
answer comment 88:  First, my point in mentioning my experience was to mitigate
those who confidently assert that clearing cache, disabling cache, or changing
cache size will reduce symptoms.  For me, NONE OF THESE have made any
significant improvement in my experience.  (Yes, I have tried ALL THREE
approaches; I am currently running with cache on at the recommended 4MB limit).
 My intent is to ensure that we are not barking up the wrong tree in researching
and fixing this problem.  Is there a cache relation to this problem?  Extremely
likely.  But let's make sure that our bug investigation includes ALL the
evidence, including unusual outliers like my experience.  That's all I mean to say.

    
    

    
  
Thanks Christopher, that makes things clearer.
Didn't know you were using the 4Mb cache size.
I think you should provide more details of what you're experiencing, as
outliers like you often provide the key to cracking a bug.
For instance, I only see problems with cache disabled when opening
large number of tabs. Do you see problems in other situations?
And when exactly do you get problems with a 4Mb cache?
Also what are your resources before you sart browsing?

As for me? I can't really add anything, for me a 4Mb cache is an adequate
workaround.

In terms of a fix, I think us testers will be left hanging till someome gets
around to looking at the blocking 1.4 flag.

    
    

    
  
I think we need to concentrate on GDI usage.  A larger memory cache allows
ImgLib to store more images and exacerbates the problem.  Having no cache at all
eliminates reuse of images, which also makes the problem worse.  A larger memory
cache improves page load performance, so I'd hate for it to be limited because
we can't find a way to manage GDI resources.


    
    

    
  
I've talked with Darin and Asa, and we're considering masking this problem in
the memory cache for Win95/98/ME platforms.  I think we still need to address
the underlying problem, but it will probably take longer than 1.4 final.

    
    

    
  
gordon or darin, can one of you make a 1.4 branch patch for setting smaller
cache on win9x? We can look for better solutions on the trunk or possibly 1.4.1. 
Flags: blocking1.4? → blocking1.4+

    
    

    
  
mmmmmm....what's this? Branch patch and faking it for Win9x????? I have been 
having ballooning GDI on Windows 2000 and an occasional GDI hang there. Not as 
easy to repeat, but it happens. Careful guys.

    
    

    
  
Hmm, yes, I'll agree with comment 95.  I use Windows 2000 and deal with this
problem every day!  Actually, every few hours.  And then reboot.  It's a total,
unmitigated nuisance.  I tolerate it because I am addicted to Mozilla, tabbed
browsing in particular.  I hate Internet Explorer with a passion and can't get
used to the UI of Opera.  But this is a -major- issue and its effects are by no
means isolated to the Windows 9x lineage.  I feel I am a Mozilla evangelist, and
yet this problem infuriates me endlessly.

I've tried an empty memory cache, a 4 Mb memory cache, a 12 Mb memory cache. 
None of these "fixes" have helped in any way that I have witnessed.  Again, no
outright system crashes for me.  Just massively frustrating window repaint
failures.  At least I can save my work and reboot.  Bleh.

    
    

    
  
Should the summery hint that picures AND fonts are displayed faulty and
(re)painting canvas AND chrome breaks down?

Perhaps these Bugs and their dupes are (partialy) related:

Bug 105363 We hold onto way too many font resources while rendering intl pages

Bug 133132 Window & chrome redraw, black & white image, and cache problem
(P1, topembed)

Bug 147845 [Matrox video card] Graphics corruption when scrolling 

Bug 153864 Chrome corruption, not updated

Bug 157256 Repainting of most widgets is not happening under Win98 after a
period of time


    
    

    
  
Drivers, the problem has been significantly exacerbated since 1.3 came out.
Thus, the need for this regression to block 1.4. We need more than just a kludge
here. The full solution could wait until 1.4.1 or 1.5, but applying a single
bandaid for 1.4 won't be enough.

    
    

    
  
I just want to contribute to this discussion a workaround, that helped me
enormously. I just set "browser.cache.memory.capacity" to a value of 1. This
disables the cache not completely (avoiding the problems due to less re-use of
images), but just enables it to hold the working set of all currently displayed
images. When windows or tabs are closed or new pages are loaded the cache
shrinks back very quick and resource usage stays in the green. At least this has
allowed me to get through the surfing day ;) consistently for about 2 weeks
without Mozilla induced reboots.

    
    

    
  
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5a) Gecko/20030612
After reading comment #66, I wanted to see my numbers, 
computer: 480 MB ram, Win98SE, running GDIUsage-tool, tabs loading in the
background.
loading 26 tabs from theregister.co.uk added 501 fonts to the existing 49.
When I looked through the tabs, the windows resourcemeter got yellow, down to 30%
Closing all tabs but the starting one regained the ressources.
I then limited the memory cache to 4096, and repeated the process, with similar
results.
On my favourite newsticker, www.heise.de, there is a different behaviour.
Depending where I am there, in the forums, or the news, threaded view, I´m
losing 2, 3, or 4 bitmaps, when I load the next article/comment into the same
tab. Closing tabs doesn´t regain the lost handles, I opened a new window, and
closed the old one, to no avail. Only way is closing mozilla.

    
    

    
  
*** Bug 209256 has been marked as a duplicate of this bug. ***

    
    

    
  
Gordon/Darin, would you like to work on comment 94 in a separate bug for branch?
I want to test the impact of a solution along the lines of comment 77 on Win9x
systems with different amounts of memory.

    
    

    
  
ok, given that folks are seeing this bug with small memory caches indicates that
this is probably more related to the problems gordon and i saw with cache
entries getting leaked.

    
  
Depends on: 209354

    
    

    
  
I don't thing the bug that has appeared in the GDI lately, seems to be new.
Since I have experienced the same problem on the latest release of netscape
based on the old mozilla builds. So it may have been pre-existing on Windows 98.

    
    

    
  
What language are you using C/C++?
Which files in mozilla do you use, that may be connected to the GDI?

If you could tell me, maybe I would spend some time to crack it.
I know some programming, it may be some loop.

    
    

    
  
gfx/src/windows uses GDI stuff
possibly widget/src/windows too, but that seems less likely to me.

Mozilla uses C++ (and javascript).

    
    

    
  
I've just seen memory problems with the 4MB cache workaround for the first time.
It was a long & complicated browsing session, with lots of windows opened by
scripts on web pages, many tabs open to numerous sites.
I.e. Not buch use in pinning down this bug.

The question that arises out of this is the following:
Is there any tool to save part of the browser history, or to play it back?
And even more important, is there any way to record how a page was opened, such
 as:
In tab in particular window, In the same window/tab or in a new window, by a
script on page?

Without such a tool I doubt I'll be much help in narrowing this bug down :-(



    
    

    
  
*** Bug 209502 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 157256 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 209947 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 209948 has been marked as a duplicate of this bug. ***

    
    

    
  
Ditto to all about this using up of memory until the program dies.  From 1.2 on,
Mozilla has become more and more troublesome in memory use.  Frankly, this is a
Moz-killer if it can't be fixed.  As it is now (up through 20030617 and 1.4 RC2)
is simply not able to be used all day by our staff without failing after a
couple of hours. 

Sincerely,

George  Beker
Vice President /
   Director of Communications (pro bono)
The Soho Center
   http://www.child2000.org
   540-923-5012

    
    

    
  
I've had GDI problems since 1.0, but 1.4RC1 made things greatly worse.  I've had
Java disabled since 1.0.  After reading these bugs I changed mem cache to 4096
and turned off type ahead.  Have been running without a problem until I did a
google images search.  Clearing cache using the prefbar brought me back to a
normal state.

Win98, 196 RAM.  ATI.  I'm also running some memory hogs (Excel and
Arachnophilia).  And the full Norton SystemWorks 2002.  Mail client is OE 5.5
also always open.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030529

So far it is much better than before, but I do miss type ahead.


    
    

    
  
I'm currently running 2003061905 - win98 SE (which should have the fix for bug
209354 in), and bumping my memory cache back up to the 8MB it was before I
manually changed it to 2MB, it took me less than 30 minutes of surfing before I
lost all my chrome again, and pages stopped displaying correctly and all the
other symptoms of "this bug" showed itself. Strangely enough, at that time the
resource meter still showed 42% GDI resources left, while before that had always
dropped down to <10% when this bug would show itself...
Anyway, I don't know to what conclusion that leads, but are we _certain_ that
it's the GDI resources causing these display problems?

    
    

    
  
Marked Bug 159298 "win98 GDI handle leak on table background changes" as dependency.
I can reproduce it with Gecko/20030619, i see brush usage skyrocketing, 
the resource display tells me i lost 12% of my GDI-handels in 5 seconds. 
Has table involved like 199443, but looks different.
Depends on: 159298

    
    

    
  
FYI,

If you want to search Mozilla code for GDI functions, you can use
http://lxr.mozilla.org/seamonkey/  along with
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bitmaps_9qg5.asp

the later being a list of GDI functions, structures and macros.

    
    

    
  
*** Bug 210099 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 210203 has been marked as a duplicate of this bug. ***

    
    

    
  
Interesting that this problem has both seemingly not been fixed, and is missing
from the known problems list in 1.4rc2.  

Or has the GDI memory problem been resolved? Maybe I missed it. 

    
    

    
  
well, we can't put all 25,000 open bugs into the release notes...

    
    

    
  
But this bug is among the very few remaining 1.4 blockers.

    
    

    
  
oh, indeed; yeah, this bug does probably deserve being mentioned in the
relnotes... unless it gets fixed before 1.4, of course :)

    
  
Blocks: majorbugs

    
    

    
  
With 57 CCs, this bug now blocks Bug 163993 - [META] Mozilla Bugs with Large
Community Interest

    
    

    
  
COMMENT:

Loaded and used 20030620 over the weekend - disaster.  The GUI continues to 
break up in weird ways.  Just for fun (and old time's sake) I went back to 
NS4.8.  What an absolute joy in comparison.  Memory stays high, no leaks even 
after hours of use, no GUI failure, stable - everything that Moz *should* be 
able to do.  If there was a way to put tabs into NS 4.8, that's where we'd be.  

Please understand, I haven't a clue what needs doing - but folks like me and our 
staff are users - and if the users don't use Moz; Moz is dead.  If this memory 
issue isn't fixed, it *will* lose a lot of those of us who had high hopes for 
Moz.  That would be a shame - but the issue has been around for weeks now - 
where's the fix?

Sincerely,

George  Beker
Vice President /
   Director of Communications (pro bono)
The Soho Center
   http://www.child2000.org
   540-923-5012

    
    

    
  
this may be a duplicate of bug 199443.  i noticed that there is a reference
cycle between imgRequest objects and the cache entries they create.  the cycle
is not always broken.

    
    

    
  
Darin: you may be right, however, if you dup this, please carry over the 1.4
blocker flag to Bug #199443

    
    

    
  
George Beker just wrote, "...the issue has been around for weeks now..."  I hate
to keep repeating the same thing, but this problem is by no means that new for
me.  The gradual deterioration of the Mozilla user interface after several hours
of usage has existed for what seems like a year or so.

And, as I mentioned, as GDI resources are consumed, other applications start
falling over.  Eclipse, Yahoo Messenger, Trillian, Microsoft Office apps, you
name it.  They all slowly fail to repaint or outright crash.  If I let the
problem persist long enough, eventually even the desktop fails to repaint.  It's
odd to hit the minimize button on Mozilla and still -see- Mozilla.  It's not
there, of course, but I guess explorer.exe just didn't have the GDI resources it
needed to paint the desktop.  Doh!

I've said this before, but it bears repeating.  Mozilla is a great program. 
It's because of its myriad excellent features that I have steadfastly refused to
ditch Mozilla (even after discovering that it's likely the root cause of my
repainting problems).  Maybe it's just that the other browsers suck (IE) or cost
money (Opera).  It's hard to convince IE users to switch when I'm sitting here
griping about GDI (my newfound scapegoat for all life's ills) all day long.

All kidding aisde, this bug really is a huge pain to deal with every day.  I
hope that eventually one of the developers will discover the real cause of this
and it won't be "fixed" with some cache hack or similar tricks.

    
    

    
  
These GDI leaks are being actively looked at.
Problem is there are several bugs that may or may not be dups of
each other... but we are looking and we are trying to fix them.


    
    

    
  
You know what would be cool?  A Mozilla that was so light and lithe that it made
IE 4 look piggy.  Moz (and other OS projects) should not just be ON PAR with MS
products, but should outperform MS products in every way, and by orders of
magnitude.  It CAN be done!  Don't tell me that Redmond has all the talent!

In other news:  My non-techie wife is beginning to use IE because she cannot do
some of her ordinary tasks (e.g., researching hotel prices) in Moz because of
the GDI/resources bug.  She used IE today!  Ahhhh!  - She loves tabbed browsing,
but will give it up because of this bug.


    
    

    
  
What Graphic Cards is everybody using, might these be related to Graphic Card 
drivers.
I use an ATI Radeon 64DDR. I think everyone should tell what Graphic Card he's 
using.

    
    

    
  
Fareed, I doubt it's related to the graphics card.  I've seen this on 3 systems,
one with an ATI Radeon 9700, one with Intel i845GE, and one with S3 ProSavageDDR.

    
    

    
  
I'm using a G550 of Matrox and have the same problem

    
    

    
  


  
I tested Mozilla 1.4 RC 3. It has improved, but after a while the issues
return,
as shown in this screenshot: Fallback on system fonts (see searchbar), GUI and
canvas are not repainted. I was able to close Mozilla, but as side effect The
Gimp crashed.
The next start of mozilla took 3 times as long as usual, but i lost no data.

    
    

    
  
Card type is probably a red herring. Getting failures on S3 Virge, Ati Rage,
Nvidia Gforce 4 max 440 SE

    
    

    
  
Forget video cards.  Moz 1.3/1.4/1.5 fails on two versions of plain vanilla
Matrox cards - and (more important) - it didn't fail back in the 1.2 days. 
There is a hole somewhere in the current architecture and it dies on all cards.

Beker

    
    

    
  
Running Win98SE: over time (~30 min. or a certain number of pages loaded), GDI
and SYS resources are used up (free percentage drops) until the display starts
going haywire (memory/resource leak?).  The first symptom was fonts going bad,
along with garbage in the right-hand slider tool (overflow?), then system
freeze.  I finally realized what was happening by running TinyResMeter.  All 1.4
versions through RC3 exhibit this symptom -- 1.3 does not.  If I exit and
restart the browser, the process starts over.  I have not yet tried 1.4 under
Linux.  I am not a programmer, just a knowledgeable user -- I really wanna use
this thing!  Thanks.

Athlon XP 1800+ / GigaByte GA7-DXC MB / 512 MB PC2100 DDR
GeForce2 MX gfx w/32MB RAM
Win98SE - all patches - all drivers up-to-date


    
    

    
  
Renom for nsbeta1.  This bug had 2 dups when it was marked nsbeta1-, but now has
about 16 dups and blocking1.4+.
Keywords: nsbeta1- → nsbeta1

    
    

    
  
They idea of me thinking it's behind a graphic card, cause ATI once I was 
looking for updates on my Graphic Driver. And their was a new driver release 
and in some of the fixes they were listing Mozilla bug involving ATI driver 
issues.

Does anybody know since when the tab browsing was implemented. I used Netscape 
7.02 it was based on Mozilla 1.02 (called stable). Which did the same thing on 
my computer. GDI resources down, until nothing can be done other than closing 
Mozilla.

I think if the whole code was written in C++, it would have not come to this 
point. I think maybe their is a problem with that JavaScript interface used.

And some other people were saying they had the X Server crashing on them. I 
guess from that point it has to do more with the Mozilla code, meaning it's 
platform independent.

    
    

    
  
For those of you looking into the interaction of graphics cards with GDI resources:

I think on win98 the graphics card issue will be a red herring.
My suspicion is that what you're seeing is how different graphics card drivers
cope when GDI resources are overwhelmed. I think you will see this variation when
pushing GDI over the limit with any intensive app.
If you want, you could push other resource intensive apps such as Internet
Explorer till all GDI is consumed, and compare the results for different cards.

    
    

    
  
It's true that any application('s) can ruin the font display etc. It's just that
Mozilla have worsened to the unacceptable at some time between 1.0 (I think) and
now.

    
    

    
  
Reply to Comment #140:

I am suggesting copmaring other GDI hogs to Mozilla *not* to make Mozilla look
better, but to understand how different hardware responds to low GDI resources.

It's my theory you'll see Different symptoms on different hardware, but the 
underlying cause will be the same kind of pressure on GDI resources.
In particular, some hardware will let you back out of a low resource situation,
but others will crash before you can take action.

    
    

    
  
Have been running 20030625.  Maybe it's a bit better but it takes my available
RAM down to 1MB after just a few tabs are loaded (we have 128MB on plain vanilla
WinDoz98se systems).  Release of memory if tabs are closed is very limited and slow.

For comparison. I went to OPERA and loaded their newest 7 version and, guess
what, it's stable and it leaves at least 10MB free after even HOURS of running.
 It's tabbed and that makes us want to move to it.  Too bad that MOZ can't seem
to stem this long-standing memory leak issue - I'd rather use Moz but it's not
feasible if MOZ keeps failing for us.  Sorry.  

    
    

    
  
George: RAM is not the same thing as Resources.   This bug is about GDI Resources.

    
    

    
  
Thanks WD,  I understand that difference.  However, I cannot help but think that
Moz's eating up of all available memory as opposed to the Opera test (and NS4.8
has essentially thge same results) is part of the chrome re-paint problem since
it probably starves the video card and maybe other elements in Win that lead to
the eventual freeze/failure. That was the reason I brought it up.  

Hey, I *want* Moz to succeed - both philosophically and technically - but it has
got to actually work well or us chickens out here looking for a great browser
alternative to MSIE can't use it.

George



    
    

    
  
Two comments:  First, I agree with George that Mozilla should not use tons of
memory any more than it should use tons of User/Sys/GDI resources.  This is
precisely why Netscape 6 was abandoned - huge memory/resource/processor
consumption made it unusuably hoggish for most users.

Second, a nasty little paranoid thought:  How do we know that every OS developer
is contributing code which is designed to help OS SUCCEED?  Is it possible that
there are some saboteurs out there?  Sounds like a Redmondish thing to do!

    
    

    
  
I use Win 98. After Bug 199443 was fixed, this problem became a bit better: The
average time to crash is now (1.4rc3) higher than with 1.4rc2. I say crash
because I have to restart Mozilla every time this happens and other applications
which are open also sometimes crash because of Mozilla. The OS itself does not
crash.

But this problem is still very bad and I think it would be a bad idea to call
Mozilla 1.4rc3 "final" in this buggy state - Moz must not crash other
applications and it should be possible to use it for more than 30 Minutes heavy
(multiple tabs) browsing...
I did not have this grave problem with Mozilla 1.3.1.

    
    

    
  
Just a REMINDER to try this workaround before you post too many GRIPES or
threaten to quit using Mozilla.  (repeated from my comment #69)  

SET THE browser.cache.memory.capacity PREFERENCE TO 4096.

To review the steps to try this:
1. browse to about:config
2. scroll down and look for browser.cache.memory.capacity.  (It shouldn't be
there, but if it IS, right click, pick modify and change to 4096. skip next step.)
3. right click, pick NEW, pick INTEGER, type in browser.cache.memory.capacity,
click OK, type in 4096 (or some other value if you want to experiment), click OK.  
4. Make sure browser.cache.memory.enable is set to TRUE
5. restart Mozilla.

NOTE: Downloading new nightly builds seems to DELETE THIS, SO YOU MAY HAVE TO
REDO IT. 

Whiteboard: Please see workaround in comment #147

    
    

    
  
Juhu. This seems to work (no 147). Sorry for not noticing it at no. 69, but it
has grown a bit this bug :-)

In short, I opened 20 tabs or so while running Kazaa and 3 instances of tmpgenc.
Nice work!

    
  
Depends on: 205893

    
    

    
  
*** Bug 211037 has been marked as a duplicate of this bug. ***

    
    

    
  
Hello all.

OK, I don't know much at all about Windows GUI programming (I'm more a Java
guy), but I want to help with this bug. I've been searching the web on GDI leak
issues and here's my contribution: some pointers to articles and tools.

First an article that explains Windows resources:
"Windows 9.x System Resources"
<http://www.windows-help.net/techfiles/win-resources.html>

Then a nice article that might give some help to someone working on this:
"Resource Leaks: Detecting, Locating, and Repairing Your Leaky GDI Code"
<http://msdn.microsoft.com/msdnmag/issues/01/03/leaks/>

Then there's this commercial GDI usage tracking tool called Itchy that
integrates into MSVC++6 as a plugin (I don't have MSVC++6 so I cannot try it):
<http://www.geocities.com/accentc/itchy.html>. An evaluation version is available.

And then there's MemProof, "a FREE heap memory and resource 'leak' debugger":
<http://www.automatedqa.com/downloads/memproof.asp>


I found MemProof rather interesting, so here's some further info:

You launch an executable within MemProof, and it tracks various Windows API
allocation/releasing calls that the application makes. So it's much like
Rational's Purify in that sense, but not just for memory allocation. MemProof
hooks calls to selected Windows Memory, GDI, User, Kernel and Registry APIs.
Simply launching Mozilla in MemProof and closing it again resulted in about
seven hundred errors (not unique, of course). The errors were mostly in the
User/Timer and Kernel/CritialSection categories, and then there were lots of
general reports of attempts to free nonexisting resources. Browsing for a longer
time exposed GDI leaks, too.

Some points though:

- MemProof is designed "for Borland's family of Windows compilers: Delphi 2, 3,
4, 5, 6; C++ Builder 1, 3, 4, 5; and Borland C++5". I really cannot say how much
this affects the accuracy or correctness of the error reporting. I'd assume that
the Windows API calls that win32 applications make are the same no matter what
compiler is used to produce the binaries, so in that sense the MemProof results
might be usable even though the Mozilla win32 binary is compiled with MSVC++6.
Maybe the Borland-specificness is only seen in the large number of common
Borland library DLLs MemProof seems to recognize out-of-the-box?

- The win32 binaries on ftp.mozilla.org don't seem to have very much debugging
symbols, line numbers, etc. included. Or then it's just that MemProof cannot
display them (maybe it's some Borland/MS binary executable format
incompatibility). So when examining the error callstacks MemProof reports, you
are limited to only seeing the function address (hex offset) and function name,
when available. It's good that you can save the errors into a text file.


Here's what I did to get MemProof configured for mozilla.exe:

1. Start MemProof
2. Configuration: Set all error reporting on (Configure -> Settings, check
everything and set MaxStackTrace to 47 (maximum value))
3. Load the mozilla.exe executable (File -> Open, browse to the mozilla\bin folder)
4. Set the host application to mozilla.exe (Project -> Parameters, set Host
Application to the mozilla.exe executable by browsing to the mozilla\bin folder)
5. Quit MemProof
6. Open the MemProof-autogenerated mozilla.mps file (found the mozilla\bin
folder) in a text editor. There should be two sections, [HostHistory] and
[General]. Add a third section called [Hooked Modules] by pasting in the whole
contents of this file: <http://www.hut.fi/u/tsknorri/mozilla/modules.txt>. The
[Hooked Modules] section lists all executables and DLLs that MemProof should
monitor. The modules.txt file lists all *.exe and *.dll files present in
yesterday's nightly Mozilla trunk Talkback build (mozilla-win32-talkback.zip).
Save the mozilla.mps file.

The above needs to be done once. After that, usage is quite simple:

1. Start MemProof
2. Load the mozilla.exe executable (File -> Open, browse to the mozilla\bin folder)
3. Run Mozilla (F9 or Run -> Run or green play button)
4. Use Mozilla
5. Close Mozilla
6. Examine error list


Hope this helps.

    
  
Flags: blocking1.5a?
Flags: blocking1.4.x?

    
    

    
  
We, at Polish Mozilla community group recive many, really many complaints about
this bug in final Mozilla 1.4. I don't know why Mozilla was relased ignoring
this bug. I know that there is no patch for this yet, or even plan how to fix
it, but 1.4 is a long stable branch. People from my country are sure that 1.4 is
most stable version ever. But it's not.
But what is more strange i can't find (am i blind?) any note about this issue in
relase notes of 1.4.

Is there any chance that there will be 1.4.1 with this bug fixed? Is there any
chance to add clear note about this problem with 1.4 (and of course workaround
from Comment #147)?

    
    

    
  
i thought 'blocker' meant you weren't supposed to ship until it was
resolved.  perhaps mozilla's project manager needs the 11th edition of
Merriam-Webster's Collegiate Dictionary; or perhaps we need a new status
called 'blocker, but only if it's convenient'.

this project is highly transparent; it would serve project leads and mgrs
well to understand that if they fail to follow through on committments and
release policy, they will have a tough time finding someone to pay them to
botch software projects for them.

take that as a wake-up call or idle threat.  you're building a free browser: 
you can afford to take the time to do it right, and to resolve blockers before 
stamping "final" on a release.  it's not like market share matters.




    
    

    
  
I fully supports previous comments. When I see the comment about the release of
Mozilla 1.4 in SlashDot I felt SAD. This bug is VERY SERIOUS, very VISIBLE and
widely REPORTED.

    
    

    
  
*** Bug 211317 has been marked as a duplicate of this bug. ***

    
    

    
  
Off topic, but also to address some comments made. (I apologise in advance for
spam, is you see this as such).

AOL/Time-Warner and Microsoft have created an interesting scenario within the
traditional capatalist framwork. They are both "selling" free products in
competition to each other. Microsoft with Internet Explorer, and AOL/Time-Warner
with Compuserve (uses Mozilla), AOL (investigating Mozilla but using IE),
Netscape (rebadged Mozilla) and finally Mozilla itself.

Mozilla is open-source, it is free, but it must comply with the wishes of
AOL/Time-Warner (its corporate parent and main source of funding).

Back on topic, yes GDI leaks are serious, and I wish Mozilla didn't suffer from
this problem. But then, I also wish that Microsoft products didn't leak GDI
resources either.

From reading many articles at microsoft.com, and investigating Mozilla code, I
have some understanding of how difficult the GDI API is to use. What's more, at
this point, I'd like to thank all who have fixed many GDI leaks that used to
exist, and hope that we all can help to fix the remaining ones.

    
    

    
  
Is this bug a metabug about all GDI leaks, or is it a 
specific bug about the cache leak? Based on the dependency 
list I would guess the former, but based on the comments 
insisting it be fixed (although not volunteering to do it) I 
would guess it is the latter. If it is the former, is there 
a bug about the cache issue?

    
    

    
  
Hixie, it looks to me like the cache issue would be covered by bug 205893.

    
    

    
  
So this is a meta bug? If so, asking for it to be fixed will 
not do much.

Adding meta keyword. Remove it if this bug does actually 
cover a particular known leak.
Keywords: meta

    
    

    
  
Adding META to summary as well.
Summary: GDI Resources are used till the  UI/website displays faulty → [META] GDI Resources are used till the  UI/website displays faulty

    
    

    
  
It's a pity they shipped a buggy Mozilla 1.4 and NN 7.1.

A quick fix would have been relatively simple:
If GDI Resources drop below 15% on Win 9x, flush the memory cache.
Of course this would only hide the real problem, but it does improve the
situation very much. You can test it by hitting "empty cache": (Most of) the GDI
handles are freed again (this is also a workaround).

Instead of this little fix they shipped a crashing Mozilla - I cannot understand it.

    
    

    
  
As far as I know, fixes outlined in posting no. 69 and 147 has cured Mozilla.
Perhaps this could be set as default values in the 1.4 download; then people
would get a better experience while the problem is fixed.

    
    

    
  
I'd suggest that some of you read the initial comments on this bug. It is quite
a specific problem, not a meta bug for everything that burns GDI resources.

1.4 changed the default memory cache size to a much higher value, causing a
default install of Mozilla to run a Win machine out of GDI resources within a
very short time. (About 30 mins for me.)

As discussed before, there are several ways to fix this:
1) Quick and dirty method: Reduce the default memory cache to what it was in 1.3.
2) Other quick and dirty method: Leave the default memory cache as it is, but
put the memory cache setting option in the UI so that users can easily fix it
and put a note in the release notes about the problem so that users know how to
work around the problem.
3) Proper fix: Remove all dependency of GDI resources on memory cache size.
Users should be able to use Mozilla at its default settings. Currently, they
can't. Users should be able to set their memory cache to 100MB if they want to,
without it crashing their machine within minutes.

    
    

    
  
Okay, yes, comment 160 gives another possible quick and dirty fix. But blowing
the cache away in order to make Mozilla usable is a terrible method. We might as
well remove some of the bloat by removing all memory caching code altogether in
that case.


    
    

    
  
Question to the Mozilla team : Did you mask this particular bug before the
release of Moz 1.4 at Download.com ? I mean setting the default for
browser.cache.memory.capacity at 4096 would seem prudent.. I have used with this
workaround for some time, for me it effectively eliminates any GDI problems.

Download.com linked the binary:
/pub/mozilla/releases/mozilla1.4/mozilla-win32-1.4-installer.exe (currently ver.
1.4.0.2003062408), which leaves the browser.cache.memory.capacity setting intact
(i.e. determines it algorithmically, which can lead to the expression of this bug)

See also:
http://download.com.com/3000-2356-10211393.html?tag=sptlt

    
    

    
  
>As far as I know, fixes outlined in posting no. 69 and 147 has cured Mozilla.

Not as far as I can tell. I have browser.cache.memory.capacity set to 4096 and I
have extremely bad GDI related crashes. 

I have noticed it is absolutely not necessary to actually be using the browser
for things to digress to a crash and reboot situation.  Twice in the last few
days I have left the computer sitting there idle for a few hours, and if Mozilla
is open (and not doing anything at all) when I return I get blue screen of death
from windows and all other applications, GDI related.  A reboot is necessary. 

This is messy, very messy. The workarounds do not work for me, and Mozilla is
broken.   

I am using IE a lot more lately. A bad situation.   

    
    

    
  
Steve (Comment 165),

It's strange that the workaround doesn't fix your problem.  Maybe you have a
different problem.

1. Are you sure you have browser.cache.memory.capacity created as an INTEGER and
not a string?
2. Are you sure you have browser.cache.memory.enable set to TRUE?
3. Could the site you're leaving the browser idle on be doing anything like
animated or changing graphics, or auto refresh, that might eat up resources
while it's "not doing anything"?
4. What Windows and Mozilla versions do you have?
5. What video card?

    
    

    
  
>------- Additional Comment #166 From Jim Booth  
>Steve (Comment 165),

It's strange that the workaround doesn't fix your problem.  Maybe you have a
different problem.

>1. Are you sure you have browser.cache.memory.capacity created as an INTEGER
and not a string?

Yes.

2. Are you sure you have browser.cache.memory.enable set to TRUE?
Yes.

3. Could the site you're leaving the browser idle on be doing anything like
animated or changing graphics, or auto refresh, that might eat up resources
while it's "not doing anything"?
No. No animations.  I will test further by leaving Mozilla on a blank page. 

4. What Windows and Mozilla versions do you have?
Windows 98 SE

5. What video card?
Nvidia Quadro


    
    

    
  
This is no meta bug! Not knowing where the leak is does not mean that it is a
meta bug. NS 7.1 and Moz 1.4 are out both with this bug, which has not been
found yet. (no comment) According to some comments NS is working on it, if it
would be a meta bug, they would not work on it but on the bugs refered to in
this bug.
The simple reason why this bug has not been found yet is that most of the people
posing her, including me are users, trying to give hints but not able to track
it down in the source code. I hope work on this bug is being held up and
increased, I can already see the postings about 7.1 and 1.4 quoting this bug,
let's hope for a quick update release that fixes this issue not taken serious
enough IMHO.
Keywords: meta
Summary: [META] GDI Resources are used till the  UI/website displays faulty → GDI Resources are used till the  UI/website displays faulty

    
    

    
  
Well, this is a little telling. 

I left Mozilla open, with about:config on it. 
No website. 
I left it there almost 6 hours, unused.  Resource meter open. GDI resources did
not diminish during this period.  

When I returned things were fine.  57% gdi free. 

I clicked on a link to this reporting page.  GDI is now 55%.  This after being
online 6 hours, nothing happened until I actually used the internet. 

I opened a tab, and brought up a static site.  Resources down to 53%, stayed
there after I closed it.   

Note that I did this last night, left Mozilla open for hours with no usage, with
a static site showing and the GDI resources eventually crashed the computer with
a blue screen of death. 

Windows 98SE, Mozilla 1.3.1
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3.1) Gecko/20030425

I went back from 1.4rc1 to see if things improved, they did not. 



    
    

    
  
Just want to note that another GDI fix was checked in yesterday (NZST). Thanks
to those for fixing one more leak.

    
    

    
  
Now after 30 minutes with this bugzilla report page on the screen and a Hotmail
manage folders screen , I have 39% GDI resources left. 

This problem is internet or network related perhaps?  

It didn't occur with the about:config screen after 6 hours.
Blocks: 211643

    
    

    
  
If you're running 9x, please please please please download attachment 118640 [details]
(from bug 199443), and submit its results. The figures given by the System
Rsource meter are completely useless in debugging a resource leak.

I'll repeat: _completely_ useless. 

All the system resource meter can tell us is that on your system, some program
is using some percentage of the resource space. It can't tell if it's a leak,
and it can't tell what kind of resources are being used up.

If you suspect mozilla is causing a GDI leak, please:

Download attachment 118640 [details] 
Start the program
click 'take snapshot'
repeat the bahaviour that you believe is causing the resource usage
click 'compare'
optional: browse through the new entries to see what they look like - under 9x
you can't tell which program is using which resource, but sometimes there's a
dead giveaway, such as multiple copies of images from the website that you just
visited.
post the before, after and difference numbers of every leaking resource type
post as minimal as you can instructions to reproduce the leak

If others can't reproduce the leak, the chances are pretty minimal that it will
ever get fixed. Comments along the lines of 'I had 63% system resources then I
ran mozilla for a while and now I only have 14%. Mozilla sucks!' won't help fix
any bugs. 

Knowing what resource types are leaking gives a clue as to where to look for a
leak, as does knowing what kind of actions cause a leak to happen. 'I started
mozilla and then it leaked 34% of my system resources' gives no clue at all as
to where to look.

    
    

    
  
Using windows 98 SE, Mozilla 

Mozilla 1.3.1

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3.1) Gecko/20030425

Download attachment 118640 [details] 
Start the program
click 'take snapshot'
repeat the bahaviour that you believe is causing the resource usage
click 'compare'

OK, did that.  
Surfed a while. 
Resource meter says GDI resources now 38% free. 

GDI Usage tool says 
              NEW   Same   Free
Bitmap  237   101   231    7
Brush    49    15    49    1
..
Mem DC    110   10   111   0
Font      176   47   176   2
Region    180  178   171   7

Is there a way that I don't see to export data from that program, or do we just
have to read it and type it?  

I am not yet having overt GDI problems, where the icons lose colors, etc. 
I will repost results when I get to that point. 

It seemingly occurs even when the system is idle, static web pages viewed, etc.
 I tested all that and the problem occurred after a few hours with mozilla
browsed to about:config.  That pretty much clinches that this is not graphic
related.  








    
    

    
  
Surfed awhile more. 
Still no overt GDI problems, resource meter now says 22% free. 

GDI usage tool now says 

              NEW   Same   Free
Bitmap  237   249   241    0
Brush    49    16    49    0
..
Mem DC    110   21   109   0
Font      176  135   178   2
Region    180  251   175   1

    
    

    
  
Still testing with the GDI tool 

Surfed some more. 
Still no crashes, however I think I am close. I went to 
http://www.kournikova.com/multimedia/
and played the greeting movie with winamp.  It did not play.  Winamp did not open.  
Resource meter now says 24% free. 

GDI usage tool now says 

              NEW   Same   Free
Bitmap  237   267   242    0
Brush    49    20    49    0
..
Mem DC    110   51   107   0
Font      176  91   167   0
Region    180  1996   185   1

Notice the new in the region item.  That is not an error.  
I just clicked compare again.  Region new is now 2055, and I have not used any
browser since the last compare. 

I looked at the task manager, there is the video, [not respondine]
I ended it with task manager. 

Region new has now diminished to 247.   

I have had lots of trouble since 1.2 version of mozilla.  I never play videos. 
I never use winamp.  If anyone is going to suggest the problem is not with
mozilla and is actually with winamp, forget it.  That would not be a valid
assumption.  

I just played an audio file with winamp off the Kournikova site.  Region new
jumped to 2045.  The clip did play.  The video never did.  

I clicked details and as I scroll through the items the bitmaps look ok. 
However when I got to the MEM DC items almost all are marked as invalid bitmap
handle or invalid memory dc handle. Looking through the Region entries almost
all say null region.  

Not sure what all this means. 



    
    

    
  
Still testing with the GDI tool 

Surfed some more. 
Still no crashes, however I think I am close. I went to 
http://www.kournikova.com/multimedia/
and played the greeting movie with winamp.  It did not play.  Winamp did not open.  
Resource meter now says 24% free. 

GDI usage tool now says 

              NEW   Same   Free
Bitmap  237   267   242    0
Brush    49    20    49    0
..
Mem DC    110   51   107   0
Font      176  91   167   0
Region    180  1996   185   1

Notice the new in the region item.  That is not an error.  
I just clicked compare again.  Region new is now 2055, and I have not used any
browser since the last compare. 

I looked at the task manager, there is the video, [not respondine]
I ended it with task manager. 

Region new has now diminished to 247.   

I have had lots of trouble since 1.2 version of mozilla.  I never play videos. 
I never use winamp.  If anyone is going to suggest the problem is not with
mozilla and is actually with winamp, forget it.  That would not be a valid
assumption.  

I just played an audio file with winamp off the Kournikova site. The clip did
play. Region new jumped to 2045.   The video never did.  

I clicked details and as I scroll through the items the bitmaps look ok. 
However when I got to the MEM DC items almost all are marked as invalid bitmap
handle or invalid memory dc handle. Looking through the Region entries almost
all say null region.  

Not sure what all this means. 



    
    

    
  
*** Bug 211823 has been marked as a duplicate of this bug. ***

    
    

    
  
Hmmm, the region numbers are interesting. From some digging at
www.microsoft.com, especially at :-
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/regions_1x9q.asp
and
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/devcons_1vsk.asp

and some searches in LXR at :-
http://lxr.mozilla.org/seamonkey/source/gfx2/src/windows/nsRegion.cpp#40
and
http://lxr.mozilla.org/seamonkey/source/gfx/src/windows/nsRegionWin.cpp#50

I have to ask, are the Windows builds of Mozilla using GFX or GFX2? The main
reason I ask is that GFX2 looks like it is better behaved with GDI regions.

NOTE: This is initial investigation. It could just be that Mozilla is
mishandling calls to some external helper apps.

    
    

    
  
The "Interesting *patch* to NOT cache GDI's on win98/95" from Jim Dun which you
can find in bug 199443 fixes this problem without limiting the size of the
memory cache.
He said it would slow things down, but I didn't notice the speed loss on my
system. The patched Mozilla doesn't use all the recources any more and doesn't
crash - so I will use it until a better solution is found.

    
    

    
  
How do I implement "Interesting *patch* to NOT cache GDI's on win98/95"?

    
    

    
  
You have to recompile Mozilla with the patch. This takes lots of time...
If you do not have MS VC++ (or time), you can download and try my build which I
have uploaded to
http://www-stud.uni-essen.de/~sw2412/mozilla-i586-pc-msvc.zip
I would like to hear if you notice the speed difference between this build and
an unpatched mozilla.
It works very fine for me, after several hours of browsing Mozilla has still not
crashed, and its gdi handle usage stayed very low.
I think this is the solution for this bug - caching these handles seems to be
one of these "broken by design" features.

    
    

    
  
Re Comemnt #180 and Comment #181. Another way to get this patch is to download
the latest nightly build as the patch has already been checked in.

    
    

    
  
RE: comment #182 -This bug is fixed on the nightlies trunk?

    
    

    
  
*** Bug 211981 has been marked as a duplicate of this bug. ***

    
    

    
  
comment #182
No the fix for bug 199443 is different.  It was a specific example
where we were leaking images (and hence GDI's).  My
"interesting patch" was not checked in.  We are looking at better
more correct solution.

    
    

    
  
My apologies, I misread the attachment list on Bug #199443.

For referance purposes, the URL to the "interesting patch" is
http://bugzilla.mozilla.org/attachment.cgi?id=126044&action=view
although I'm sure that is already mentioned in this bug somewhere....

    
    

    
  
re: comment #181 http://www-stud.uni-essen.de/~sw2412/mozilla-i586-pc-msvc.zip
Thank you very much for this patched mozilla. I´ve used it for hours on Win98
and Win98SE without increasing the bitmap count.
Whoelse did test this, and was the result positive or negative?
Should this patch be checked in? I would say yes, but thats only a feeling.
Dominik, can you make an attachment with this patch, and ask for Review?
Would be nice if we can get this at least for 1.4.1 and 1.5b.


    
    

    
  
Been stable for me. I just checked with the GDI Usage viewer and couldn't find
any bitmaps I could recognize from my Moz. session at all.  The minibrowser I
wrote with VB+NS7.1's Mozilla Controll has every image from every page I've
browsed with it today in there. It looks like when pages go away they GDI
bitmaps aren't released until the app closes.

I'm not a programmer of a calabre to contribute code to Moz., so I don't know
how this GDI-based caching is coded. Is it supposed to be releasing resources as
you browse?  Or is it supposed to hold up to so many bitmaps, releasing them on
an age basis as newer ones come in? I figure either approach would stop
accumulation, barring bugs. The latter would impose a strict limit which would
be most useful for Win9x users, but not so critical for post-Win9x. How's it
being done now?

    
    

    
  
This is a very annoying problem. I've only started to notice it recently (maybe
early July builds of Firebird). I'm running WinXP Pro SP1, with memory cache
turned off (I have the cache set to false and the cache size set to 0). I can
confirm that WinXP won't start to act funny until it gets around 10,000 GDI
objects used, but I've seen this happen several times (especially with Kazaa
Lite open at the same time, the latest versions of that have GDI leaks too). In
my case closing off Firebird does not solve the problem, it does release those
GDI objects but Windows continues to redraw improperly and lag until I reboot. I
also notice that FB does not release memory it's using until the browser
instance is actually closed, though I don't think that's a component of this bug. 

    
    

    
  
See:

http://forums.mozillazine.org/viewtopic.php?p=115350#115350

That brings my Firebird nightly (any recent) or Mozilla 1.4 to its knees each
and every time I do it. Note that my OS is WinXP Pro, SP1. I also posted this in
bug 211643. It will end up looking like the screenshot of Mozilla 1.4 RC3
attachment.

    
    

    
  
See:

http://forums.mozillazine.org/viewtopic.php?p=115350#115350

That brings my Firebird nightly (any recent) or Mozilla 1.4 to its knees each
and every time I do it. Note that my OS is WinXP Pro, SP1. I also posted this in
bug 211643. It will end up looking like the screenshot of Mozilla 1.4 RC3
attachment.

A sample without scantily clad women:
http://robh.net/test.html

    
    

    
  
The fix from dominik.tappe@uni-essen.de works for me.  I tried his patched
version of Mozilla and it has been working fine for me.  No GDI errors as of yet
(surfing for at least an hour at a time).  I also notice that Task Manager
(Coral Software) shows the release of resources that were being used by Mozilla
when I close the browser.  I have Windows ME.

    
    

    
  
FYI...
I am assuming my eventual patch/fix (which is being evaluated now)
for bug 205893 will fix this one.  The only other one that I know
of at this time, bug 198806, deals with yet another issue when you 
right button menu click on "Image Save As", but that will be handled there.

    
    

    
  
*** Bug 212702 has been marked as a duplicate of this bug. ***

    
    

    
  
Regarding the workaround, I've found that setting browser.cache.memory.capacity
to 4096 isn't sufficient to make Mozilla not run me out of GDI resources (on
Win98SE) unreasonably quickly. I've found 2048 works better.

Oddly enough, I tried setting browser.cache.memory.enable to false this
afternoon and found all my GDI gone within about 30 mins!


    
    

    
  
Regarding Coment #195

setting browser.cache.memory.enable to false makes mozilla eat about 1000
Bitmap-Handles per Page-load on some pages. At least on Win9x this would result
in a total loss of free handles and complete loss of usability just half a
second after you have typed in any URL and hit enter. 

This seems to be a different bug, but it may be somehow related.

I can remember the old win 3.1  and 9x Days where I have been told that
GDI-Handles always have to be released as *soon* as possible after painting
because they are only for *temporary* use and usually have to have a lifetime of
some milliseconds only. When the paint-method is done, all handles have to be
released. Using GDI Handles to implement such a huge cache and have the GDI to
care about all those cached bitmaps is at least in my eyes an abuse of the whole
Windows GDI concept.

Just my 2 Cents

    
    

    
  
Re comment 196 :
This was my understanding regarding GDI handles as well, namely they should be
release immediately after use.

    
    

    
  
*** Bug 212894 has been marked as a duplicate of this bug. ***

    
    

    
  
Screen redraws, icons in task bar rendered in black, without colors. I had been
using Mozilla a couple of hours. 

I heard this was fixed, but I have had several crashes today (BSOD Windows),
after upgrading to 1.4 yesterday in hopes of a fix.  This is much worse than the
1.21 release I had downgraded to. 

Is there a fix to this gdi memory problem or not? 
Blocks: 213210

    
    

    
  
I'm running Mozilla 1.4 final on Windows XP.

I opened about 10 tabs with 20 images each, and then suddenly mozilla stopped
redrawing properly. It even affected other applications!

I had to reboot the whole machine.

    
    

    
  
I am seeing this happen frequently on my Win98 box. After surfing the web for
some time suddenly the screen is not redrawn properly. After closing and
restarting Mozilla everything works fine again, until... Very annoying.

    
    

    
  
*** Bug 213371 has been marked as a duplicate of this bug. ***

    
    

    
  
Given the clearly documented need to use GDI resources for as brief a period as 
possible, the clear abuse represented by placing these in a long-living memory 
cache, and the fact that a patch to stop this abuse fixes the problem can we 
PLEASE get a 1.4.1 out that stops the needless suffering (and embarassent!)?

    
    

    
  
Reducing the size of the Mozilla main window "fixes" the repaint, even though
the GDI resource use remains the same. There fore, the GDI resource is not
causative but another symptom of an underlying bug.

    
    

    
  
I have to agree with comment 204 that when the window is sized smaller, the
repaint fixes itself, but that is only a temporary solution.  I have experience
times where it refuses to repaint as a smaller window too.

    
    

    
  
I have the same experience as comment #205.  The only way I can get it to
repaint is to open a smaller window and cover the screen in four steps with the
smaller window.  I can get the tabs and the individual components of the tool
bar to repaint by passing over them with the mouse pointer.

    
    

    
  
Have you seen this patch?


------- Additional Comments From dominik.tappe@uni-essen.de  2003-07-07 13:34
-------
You have to recompile Mozilla with the patch. This takes lots of time...
If you do not have MS VC++ (or time), you can download and try my build which I
have uploaded to
http://www-stud.uni-essen.de/~sw2412/mozilla-i586-pc-msvc.zip
I would like to hear if you notice the speed difference between this build and
an unpatched mozilla.
It works very fine for me, after several hours of browsing Mozilla has still not
crashed, and its gdi handle usage stayed very low.
I think this is the solution for this bug - caching these handles seems to be
one of these "broken by design" features.


Also, I have downloaded 1.5 of Mozilla, and the GDI problem appears to be fixed.
 I haven't experienced the problems with the patch version listed above or with
1.5.  I use WINME.

    
    

    
  
Hi,

Just one quick question : Is there anybody from the dev team who can give an 
official status for this bug ???
Or an official position to give up the Windows version ???

Or are we only users reporting the bug here ???

I used to talk about Mozilla around me as a replacement for IE ...

    
    

    
  
requesting blocking 1.5b
Impact of this bug is very high, according to google the number of win98 users
is only about 2 to 3 percent less than that of WinXP-users, both some percent
above 30 percent each, so win98 is still important.
In comment 181 Dominik offered a test build with a patch from Jim Dunn from bug
199443, and this build is working fine for Dominik, me and some others,
but it misses the bugfixes since Moz1.4, as it is a patched mozilla 1.4.
Couldn´t this patch be checked in as soon as possible, to be replaced by a more
sophisticated patch, if and when there is one?

Flags: blocking1.5b?

    
    

    
  
A request of a "strategic" decision.

I have got the impression that the developers sees this as a Windows 98 specific
problem and that coding for solve it would result in non-relevant/problematic code.

Therefore a solution of this dilemma could be that a Windows 98 specific
"branch" was created presumably maintained by voluntarely assigned developers
(hoping that there will be some...).
Maybe I don't know what I'm talking about but for me it seems that the
added/changed code compared to the ordinarie branch will be relatively minimal -
or once created - easy to apply to the ordinarie branch.

    
    

    
  
This bug is *not* Win98-only. The same problem also occurs on WinME and can be
reproduced easily. 

The workaround in #147 doesn't solve the problem on my system (WinME).

The patched version provided by Dominik Tappe in comment #181 works fine for me.
I can't notice any disadvantages like performance problems.

If this bug is ignored any longer, there will be loss of credibility of Bugzilla. 

Unfortunately I can't recommend Mozilla 1.4 on Windows for anything else than
testing & crashing.

    
    

    
  
Until this is fixed I am switching to Opera. 

    
    

    
  
214 comments and it's still not clear that the repainting/GDI issues with
Mozilla are far more widespread than Windows 98?

I have never used a Windows 9x-lineage OS so I can't say for certain how this
bug manifests on Windows 98 or Windows Me.  I have seen the comments above
stating that it actually -crashes- those operating systems.  But I know from
-daily- experience that the repainting/GDI issues in Mozilla are very real and
cause system-wide repainting failure in Windows 2000.  I have never had the OS
outright bluescreen, but nevertheless, a save-work-and-reboot pattern gives my
workstation is daily exercise.

For a moment in history, I had started to undertake the painstaking effort of
installing Windows XP and reinstalling all my apps (I've never trusted a Windows
upgrade process to work--ever used a Windows 2000 box upgraded from NT? 
Something's just not right about that.)

I thought, "Maybe Windows XP has a HUGE GDI pool versus Windows 2000 and
Mozilla's GDI issues will be counterbalanced by the excesses of the OS."  Then I
saw comment 70, comment 189, comment 190, and comment 200.  Those comments
removed any hope in Windows XP "solving" the problem.

It is therefore confusing to me why this issue continues to be pigeonholed as a
Windows 9x-exclusive problem.  Even bug 210 makes a point of comparing the
Windows 9x usage base to Windows XP.  I'd rather not sound critical of the
author, but isn't that point irrelevant when the issue at hand affects both
operating systems?  Fix the bug and both user categories will be happy.

    
    

    
  
*** Bug 213990 has been marked as a duplicate of this bug. ***

    
    

    
  
This issue happened for months on my W2K system until I found comment 147. I
have since switched to Firebird and Win XP and am still using that "fix".

    
    

    
  
I'm on Win98, reducing the memory cache size (#147) does *not* help in my case. 

However, "not caching GDI's" as shown in #179 and #181 works fine. I will be
using this patched 1.4 binary till the bug is officially fixed.


    
    

    
  
Don't know if this helps, but my system runs Multizilla, and I don't seem to get
this bug.

My system:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Multizilla 1.4.0.4A
Windows 2000 Pro SP2, 512MB RAM, GeForce3 w/ Detonator 44.03 drivers (since this
is graphics-related, this might conceivably be relevant)

No manual tweaks (as far as I can remember) - I'm very much an interested
end-user as far as Mozilla goes, rather than a hacker.

Test: with sundry other crud open (several tabs, mailnews, a couple of random
pop-ups) I opened the bug-tickler page linked to from comment #191 (
http://robh.net/test.html )and let it load completely. 

Result: Loaded fine. All other tabs unaffected. All other running apps - there
are several, including Eclipse (a largish Java IDE) - unaffected.

Windows Task Manager reports Mozilla.exe's footprint as:
Mem usage 47,204K, VM size 36,892K, 242 handles, 192 USER objects, 633 GDI objects.

    
    

    
  
*** Bug 208123 has been marked as a duplicate of this bug. ***

    
    

    
  
to comment #218 :
a possible reason might be a different implementation of the tabbed-browsing
feature. Just my personal assumption after reading http://multizilla.mozdev.org/
and rereading the bug descriptions which mention the tabbed-browsing-feature.

hth Andreas

    
    

    
  
1.5a is released. unsetting request.
Flags: blocking1.5a?

    
    

    
  
I'm using Win98 se and the 3rd party build hosted at
http://www-stud.uni-essen.de/~sw2412/mozilla-i586-pc-msvc.zip in comment #181
with the "Don't cache GDI Objects" patch. 

I opened the page http://robh.net/test.html in a new tab, opened a few other
tabs and browsed in them, and served the browser a final hit by browsing to my
site's FF6 art gallery (http://ff6.sm-soft.org/art/art_en.php) which contains
some thumbnailed images (about 54). I opened so many images in new tabs that
tabs would only be large enough to show the icon (in 1152x864). 

I noticed no GDI leaks in mozilla, or in my two mIRC apps (where I usually
notice leaks by Magenta-bg'ed buttons, and icons disappearing here and there).
And that is after using mozilla all day long without closing it, and after
surfing lots of sites with lots of images. Such activity would usually have
caused at the very least one GDI leak that would've required shutting down all
of Mozilla (including mail) and restarting it. I always leave Mozilla Mail on,
and it still is as I'm typing this.

I do believe this patch should be verified and checked in, for Mozilla's sake.

    
    

    
  
*** Bug 214127 has been marked as a duplicate of this bug. ***

    
    

    
  
"Please see workaround in comment #147" What?  (And this bug affects WinMe also,
not just Win98).
1. Would someone please just point to a workaround written for users, as in a
single page/paragraph of complete explicit instructions for a possible
workaround (for those of us not qualified to help, or decifer pith written by &
for developers)?
When I Edit Options, the "workaround" in 147 does not apply.  "1. browse to
about:config"--about what are you talking? 
I've been using Mozilla exclusively since last year & I edit & specify ALL of
the preferences.  There is not about:config.

2. This is a mission critical bug and should be immediately added to the release
notes for Mozilla 1.4.  Users need to be cautioned to CLOSE Mozilla after
viewing several dozen pages, or a few pages with many graphics.  Mozilla now
crashes 5 times as often as Windoze!  It often crashes so hard I can't even
CTRL+ALT+DEl or get a Micro$hit Blue Sceen of Death--I have to force the PC
power off.
3. Comment 160 provided a perfectly adequate fix for now.  SO WHY HASN'T IT BEEN
IMPLEMENTED IMMEDIATELY?   Review request 1 above.
The corporate mainstream will  A. Not use Mozilla, and 
B. Won't even allow their staff to use Mozilla, since it creasheds Windows.
  
I bought a new expensive video card (MX440 SE 128MB ddr) after repeatedly losing
hours of work just from this bug, but now I KNOW the bug IS in Mozilla.  I'm
using Windoze Me, clean install, with all critical service packs (except that
shitware for Win Media Scraper June 2002 & IE6 disServicePack1), 512 MB ram.
Sorry for the rant.
Beware of republicans posing as humans.

    
    

    
  
If I were to tell you to browse to "mywebsite.com" , what would you do?
Alright, if I were to tell you to browse to "about:config" , using that same
logic now what would you do? 

    
    

    
  
>If I were to tell you to browse to "mywebsite.com" , what would you do?
>Alright, if I were to tell you to browse to "about:config" , using that same
>logic now what would you do? 

Well, that is a little obscure.  But I figured it out. 

However how do you delete entries in that view? It seems when they are there
they are there, you can't get rid of them. You can edit values, but cannot
change data types. (yeah, I put something in as a string instead of an integer,
and I can't fix it)

Anyone know? 

    
    

    
  
There are two ways to edit those prefs: about:config and the file in: C:\Program
Files\Mozilla\defaults\pref called all.js.  When you're editing about:config,
you're just editing all.js through the browser instead of a text editor.

    
    

    
  
No! That last comment is wrong! Mozilla never writes to all.js!

You are modifying prefs.js in your profile, not all.js with about:config

    
    

    
  
Trust me, if you want to edit all of your preferences and not just some of them
which are contained in the prefs.js file, you need to edit the all.js file.  You
won't find browser.cache.memory.capacity in the prefs.js file.

    
    

    
  
Sorry, let me rephrase that.  If you want to edit your global preferences, you
have to edit the all.js file.  If you want to edit your profile preferences, you
have to edit the prefs.js file.

    
    

    
  
(this is -so- offtopic for this bug, but as it is already a useless bug, let's
continue here...)

Correct. about:config does edit the profile preferences though, not the global ones.

    
    

    
  
I am pretty sure this is a dup of bug 205893
There are 2 approaches for a fix for this, both are being
discussed.  I don't know when a solution will be checked in.

But let me assure you, we know the problem, we understand the
problem, we are working on the problem... it is just know we
need to make sure the solution is good.

    
    

    
  
I am glad to hear that, as the workaround in note #147 doesn't help at all (I 
entered a duplicate bug last night - there do seem to be searching problems with 
this database). To me, as well, this is the difference between Firebird being a 
nice toy and a serious alternative to IE.

    
    

    
  
I think the possibility of this being a dupe of bug 205893 was discussed before
and thrown out, but I'm not sure. I also just wanted to reiterate that this is
NOT just a Windows 9x problem. I've been running Firebird nightlies on Windows
XP, Service Pack 1, and it's always had this problem. With WinXP's huge GDI pool
it takes a bit longer to happen, but it most definetely does unless the browser
is periodically closed (minimizing does not release ANY resources in my
experience, even the memory usage doesn't seem to go down). 

Another interesting thing I've noticed is that my Memory cache settings are
completely ignored. My about:cache right now reads:

Memory cache device

Number of entries: 	571
Maximum storage size: 	2048 k
Storage in use:        18248 k
Inactive Storage: 	267 k

not sure if that's related to this bug at all, but it certainly isn't right. Is
there a bug for this?

    
    

    
  
Re: comment #234

Yes, bug 198806. Occurs when saving images on disk and
sometimes during page reload. Image data somehow gets
locked in memory cache, increasing GDI objects usage
and leaking memory.

    
    

    
  
For what it's worth, the GDI and USER resources on Win 9x are as follows:

16-bit space:
-------------
One 64K segment for some GDI resources
TWO 64K segments for some USER resources (=128K)

32-bit space:
-------------
One 2M segment for some other GDI resources
One 2M segment for some other USER resources

Between Win95 beta and Win95 gold Microsoft apparently moved some stubs that 
were causing severe resource shortages out of 16-bit space  and into 32-bit 
space (there were some there already anyway). Microsoft claim that this gives 
a "best of both worlds" solution. In particular, creation of new objects in 
the same class as existing ones is not supposed to use additional resources in 
16-bit space. Perhaps if Mozilla were to bear this in mind it could help 
reduce the load on the system, even once these bugs get fixed?

    
    

    
  
I should add that WinME (aka chronic fatigue) is also a member of the WIn9x 
family for those that didn't know that.

    
    

    
  
Bug 207796 (from me) is probably a duplicate of this.   I've
chased this enough to be convinced the problem is related 
specifically to caching device dependant bitmaps, which some
windoze drivers treat as an exhaustable resource.  Please
have a look at 207796.

Also, note that one side effect of resource near-exhaustion
is that OTHER applications begin to misbehave, so strategies to
"fix" the problem by monitoring the resource level (as suggested
in comment 160) are not satisfactory.

    
    

    
  
> ------ Additional Comment #238 From Dave Dyer  2003-07-31 02:39 -------
>Bug 207796 (from me) is probably a duplicate of this.   I've
>chased this enough to be convinced the problem is related 
>specifically to caching device dependant bitmaps, which some
>windoze drivers treat as an exhaustable resource.  Please
>have a look at 207796.

And I notice you are using win2k on a new high end machine.  That should lay to
rest the idea that this is a windows 98 problem.  It's not, 98 is just the
largest population in OS's.  This resource problem has been reported in Windows
98, 95, 2000, ME, and XP on this thread. 

I saw server stats a while ago from a busy web server, and it was over 50%
windows 98.  So that explains why windows 98 seems like the problem. But it's not. 

    
    

    
  
I'd add NT to the list.  It's much less severe than it is on 98SE,
but still a problem 

    
    

    
  
Is there a GDImonitor for Win98.
On my PC it says "PSAPI.DLL not found"



    
    

    
  
>------- Additional Comments From webmaster@beyond-thoughts.com  2003-07-31 08:33 
>Is there a GDImonitor for Win98.
>On my PC it says "PSAPI.DLL not found"

Yes, it's called resource meter, in programs/accessories/system tools. 

Blocks: 214620

    
    

    
  
With the version of Mozilla/Netscape which shipped with RH 8.0, I pulled up a
looping weather map and happened to leave it on screen. After a half hour or so
it ran out of something and locked up the entire box. It's possible that this
bug may affect linux installs also...

    
    

    
  
Re: comment #234

Scott, there are two, somehow connected, issues:

1. Bug 198806, that causes the cache to leak memory when
   handling images. It manifests clearly during image save,
   but leaks seem to happen even while refreshing or redrawing
   images. It's quite severe bug, affecting all platforms and
   causes memory exhaustion, what leads to system crash or
   temporary malfunction.

2. Bug 204374, that causes Win32 GDI handles to be used too
   extensively, what causes Windows systems to malfunction
   or crash. I don't know whether this bug has any impact
   on non-Windows systems.

I hope that soon-to-be-checked-in fix for bug 201455 will
make cache subsystem a little more reliable. Anyway, please
test and vote bug 198806, it makes saving images impossible
(I can make Mozilla consume hundreds MBs of memory in minutes)
and it affects all image-operations.


    
    

    
  
The patch does not work. I've tested it on Win98. Whenever the load from other 
applications is more than light, mozilla consistently takes it over the edge 
(explorer crash, win31 style crash dialog followed by BSD).

This bugs needs to be fixed, I cannot use Mozilla because of this. I cannot 
lose data in other applications or reboot my computer every few hours.

    
    

    
  
Anything that uses/implements Win32 GDI handles has the potential to exhibit
this bug. The main reason Win 9x sees it most is because there are a lot of
users, but mainly because it takes far less time for the problem to occur due to
Microsoft giving those versions of Windows such a small space for GDI to work
in. Win NT, 2K, XP and XP 64bit all suffer from the same problem, it just takes
longer to see it due to them having a bigger space for GDI to work in.

<OT> I wonder if users of WINE see this problem? </OT>

    
  
Flags: blocking1.5b?
Flags: blocking1.5b+
Flags: blocking1.4.x?
Flags: blocking1.4.x+

    
    

    
  
Not that this hasn't been beat to death, but I too can confirm that this is an
issue on both my Win98 home pc as well as my Win2k pc at work...

I just wanted to let the development community that might look in on this bug
occasionally that I'm just watching and waiting for someone to say that a
potential fix is in a nightly build...  Maybe it is already and I don't know how
to make myself aware..

At this point, I'll be able to--and more than happy to--beta test on both my pcs.

    
    

    
  
One must remember that creating a fix for all the GDI bugs in Mozilla isn't
going to be easy. The bugs are in the Browser (Navigator), in Composer, in
Mail/Newsgroups and in IRC Chat (hmmm, and probably in Venkman, DOM Inspector
and maybe the Javascript console).

Also, many thanks to Asa for +'ing the blocker status markers.

Hmmm, if I get really organised, I might see if I can find a nice list of all
the GDI function calls to attach to this bug. In the mean time, you can find GDI
function details at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winprog/winprog/functions_in_alphabetical_order.asp

    
    

    
  
*** Bug 208792 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 214978 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 214620 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 215029 has been marked as a duplicate of this bug. ***

    
    

    
  
This bug was extremely frustrating for me (and still exists in ver 1.4 on
winME), but the hint about turning off the memory cache has kept me crashless
for three days now. I finally had to leave Netscape 4.8 and go to Mozilla about
a month ago, and have been crashing 5 or 6 times a day. I was looking in the
bugs about corrupted history.dat files all that time and only looked here out of
desperation. Is there a way to hook the hint about the memory cache to those
history.dat bugs also? With no crashing, I've also had no history corruption.

    
    

    
  
This bug was extremely frustrating for me (and still exists in ver 1.4 on
winME), but the hint about turning off the memory cache has kept me crashless
for three days now. I finally had to leave Netscape 4.8 and go to Mozilla about
a month ago, and have been crashing 5 or 6 times a day. I was looking in the
bugs about corrupted history.dat files all that time and only looked here out of
desperation. Is there a way to hook the hint about the memory cache to those
history.dat bugs also? With no crashing, I've also had no history corruption.

    
    

    
  
I am also experiencing this problem with both Mozilla 1.4 and 1.5a. The 
Slashdot logo is black, www.mozilla.org/start dinosaur pictures is missing 
(black), sometimes the Mozilla buttons are black and large pictures don't show. 
According to the Windows task manager, only 118 GDI objects are being used by 
Mozilla, less than used by Eudora, Dev Studio, exceed, Windows explorer, Palm 
desktop, or IE. All of these applications, show pictures fine just when 
Netscape is not, so I'm not sure it's an "out of GDI" bug.

    
    

    
  
This bug isn't really about how many GDI resources that Mozilla uses, but rather
that Mozilla leaks GDI resources. In other works, Mozilla seems to be allocating
a GDI resource, and then not giving it back to Windows when Mozilla has finished
with it. Yes, that sounds very like what I said this bug isn't about. It is a
subtle distinction. If one wanted to work to reduce the overall use of GDI
resources, then they would need to file a new bug dealing with the memory (?)
footprint of the running application.

Also, MS Windows doesn't allocate a certain number of GDI resources per
application. Windows it self has a certain number of resources that all
applications must share. So, to get a count of total used to see if it is close
to the maximum, one must count what is used by all applications running in
Windows (including Windows itself).

    
    

    
  
Is there a bug or even a feature request that Mozilla should only allocate as
many GDI resources for itself as user currently needs to look at (eg only the
visible tabs&windows? I believe it would be reasonable to release (at least most
of the invisible/hidden items located on other tabs beside the active one) GDI
resources for windows not currently visible (eg minimized) and allocate them
back as window is raised (or even tab is changed). In case enough GDI resources
can not be allocated, the window could be kept minimized. Maybe still an error
message could be displayed suggesting to close/minimize some windows.

I don't think it allocating a GDI resource again and again would be too costly.
Users might also want a preference like "Release GDI objects on minimize" or
something if it really is an option.

Images being cashed should IMHO still not be connected to uncompressed GDI
resource unless really needed so.


Finally I know - I have read some bug discussions according to the GDI usage and
I'm sorry I am not able to participate in the implementation of it. I just don't
feel so confident in mozilla code.. This message is just a summary of my
thoughts about Mozillas GDI usage. This bug appeared general enough to write it
there. Maybe there already exits that kind of bugs/requests just described here
- I would be glad to read about them and vote :)
I really like using mozilla ant that's all I can currently do for it - follow
bugs as much as I can.


    
    

    
  
I believe it should be noted here that smontagu checked in yesterday (8/7 12:46
Pacific Time) a temporary fix for this bug (and probably some others):

"As a temporary stopgap fix for issues with GDI handles on Windows, don't
optimize images at all. Patch by jdunn@maine.rr.com, r=smontagu, sr=tor, a=asa."

It is most probably the patch from bug 205893.

I made a fresh CVS build and was able to open about 20 windows full of graphics
(which overwhelmed all recent Mozilla builds) even with
browser.cache.memmory.capacity set to -1 (meaning "auto"). Today (8/8) morning
builds will includr this patch. We need to do some testing before 1.5b is out.



    
    

    
  
As Jacek says, I checked in attachment 129188 [details] [diff] [review] from bug 205893. It seems I forget
to reference any bug number in the check in comment, but at least the comment in
the patch says 

 // see bug 205893 & bug 204374

    
    

    
  
*** Bug 215476 has been marked as a duplicate of this bug. ***

    
    

    
  
I downloaded and installed this morning's Nightly, with smontagu's latest
checking, which is, as stated, a tempfix for that GDI leak issue.

I intensely used mozilla all of today, opening lots and lots and lots of sites
with many many pictures (yes, that much). No gdi leak symptom showed up, while,
with a previous build, I should have had to close and restart mozilla about 5-8
times, maybe more.

I'll try to keep mozilla up for as long as I can (usually depends on Windows's
uptime.) and I'll advise if I ever see a leak.

    
    

    
  
In comment 258, Jacek Piskozub wrote:
> "As a temporary stopgap fix for issues with GDI handles on Windows, don't
> optimize images at all..."

Obvious question: 
 - In the testing, does it seem that there is a performance penalty from this fix?
 - Also, does this tempfix affect platforms other than Windows?


    
    

    
  
The new Build 2003080804 works perfectly and there is no more problem.  I ran
Mozilla for two hours tonight and it didn't crash on me.  Furthermore it
shutdown without any problems.  The problem doesn't exist more if you use this
build.  It works.  It should be dropped as a bug now.

    
    

    
  
It looks like its only php pages that goes wakko for my
part. The first sign of a leak is the system-tray background color
changing, windows that can't minimize/restore, graphics and icons
disappear, the desktop not able to refresh itself. If I'm quick I can
close all Nestcape windows in time and I'm out in the clear again, but
just as often the hole machine goes cold and reboot is in place.

    
    

    
  
I see reference in comment #263 to a new build, does anyone know if this will be
released soon? I have no compiler available, so am hoping for a release version
or an installable patch. I'm on winME and setting
browser.cache.memory.enable=false has me crashing out the whole system only once
every 2 or 3 days rather than 3 times an hour as happens when cahce is enabled.
This isn't too bad (livable), except that some URLs won't open at all with
memory cache disabled, even though disk cache *is* enabled and set to 10M.
Setting browser.cache.memory_cache_size down as far as 128K is no help and I
have no browser.cache.memory_capacity setting available in this 1.4 version.

    
    

    
  
This particular problem seems to be solved. 
I downloaded the 1.5 beta release a couple of days ago and this problem has not
reoccurred. 

Mozilla 1.5b
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030808

There are a few other issues with the build but this one seems resolved. 

Get the August 8th 1.5 release. 

    
    

    
  
If this bug is solved, we should be sure about what patch solved it in order to
patch NS 7.1, that suffers from this bug too.

    
    

    
  
Marvin, Steve, Sven: No, this bug is _not_ fixed, otherwise it would have been
marked RESOLVED FIXED. As comment 258 and comment 259 clearly say, a _temporary_
stopgap fix has been checked in.
Sven: comment 259 includes the patch number.
Crassius: I believe you don't need to wait for a release - just download any
nightly build dated 20030808 or later.

    
    

    
  
People, this is no forum and this is no chat or whatever.

comment #267 : This is bugzilla.mozilla.org and you must ask Netscape for a
fixed version if they ever release a new Version

(another useless SPAM comment)

    
    

    
  
>------- Additional Comment #268 From Vaclav Dvorak  2003-08-10 14:48 -------
>Marvin, Steve, Sven: No, this bug is _not_ fixed, otherwise it would have been
>marked RESOLVED FIXED. As comment 258 and comment 259 clearly say, a
_temporary_stopgap fix has been checked in.

Vaclav:
I don't understand your comment. I am beta testing here, and if a problem is
resolved I will be reporting it.  I don't work on the codebase, so those that do
are going to have to figure out the best way to resolve this, but for me this is
resolved.  If I don't report when things change how will those that are working
on the project to know?  

And it may very well be a stopgap fix. I don't work on that part. But beta
testing is reporting what changes.  Like I did for the previous workarounds
which did NOT fix this problem for me. I reported it. That's how beta testing is. 

    
    

    
  
Three days of intensive testing on Windows Me with no side effects (I do not
notice the difference caused by the lack of optimalization). This should
certainly  be part of 1.5beta release (and probably also 1.4.1).

<QA_ignore>
Matti: Asa specificially asked to "try to get some testing across the
various windows platforms to see if anyone can shake out any problems" in
comment 205893#30 (on a different bug but concerning the patch from this one).
Do you expect us to send him messages in bottles?
</QA_ignore>


    
    

    
  
Using Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030810 ,I can
finally go back to having 10-15 tabs open without constantly getting "low
resources" warnings from Windoze. My GDI's still above 50%, instead of hitting
0% all the time and blowing the O/S up.

Thus far, I've seen no downside either.


    
    

    
  
*** Bug 216125 has been marked as a duplicate of this bug. ***

    
    

    
  
So far in 4 days of pushing it hard with lots of Japanese anime-site windows
open, I've had no GDI problems or crashes of any kind on winME using build
2003081004.

    
    

    
  
*** Bug 207796 has been marked as a duplicate of this bug. ***

    
    

    
  
After several days of running 2003081104 / Win98se this problem has nor
reoccured.  Before I was lucky to get half a dozen windows open.  The cache
workaround had no effect.  Now I can run a dozen windows all day.  GDI resources
remain at 50-60%.  I'm a happy camper again.

    
    

    
  
This bug seems to be fixed and resource use is lower than ever Build 200308515
at least for me and Win98 SE. Thanks!

    
    

    
  
_Please_, people, we don't need anymore 'Me too!  This is fixed for me!'
comments spamming this bug.

We know it's temporarily fixed on all of the platforms (the workaround to not
optimize images is in), but a long-term solution is in the works and doesn't
need anymore comments until we land the final fix.

Thanks

    
    

    
  
I hope this isn't a duplicate posting, but I posted something last night and I
don't see it in the log, so I'll do it again.

I've installed the nightly build a few weeks ago that had a workaround for this
bug.  No problems since then.  I downloaded the nightly build on 8/19 and this
bug reappeared for me.  Firebird was also having problems last night.

On the new build, I didn't do the suggestions in comment #147, but then again I
didn't do them when I installed the nightly build two weeks ago with the
workaround (at that time I wasn't even aware of it) but the problem went away.

What is perplexing for me is that when I checked the resource usage under Norton
System Doctor, the "GDI Free" read 70%.  Now I'm not a windows expert,but I
believe that I'm looking at the correct resource as when this resource dropped
below ~15% before, the bug cropped up.  The bugs behavior last night was exactly
what it was several weeks ago.  Could it be a bug in Norton System Doctor?

I don't suspect that it was a system problem as only Mozilla and Firebird were
exhibiting strange behavior.  Someone correct me if I'm offbase on this one (I
hope I am).  This leaves a quite perplexed with the 70% resource usage or are we
seeing another bug?  

Thoughts?

    
  
Flags: blocking1.5b+

    
    

    
  
GDI problems will affect all applications (and Windows itself) if resources get
too low. If you only see the problem within Mozilla, but not in other
applications that are running at the same time, then I would assume that it
isn't a GDI problem.

    
    

    
  
re Comment 280
>> GDI problems will affect all applications (and Windows itself) if resources get
>> too low. If you only see the problem within Mozilla, but not in other
>> applications that are running at the same time, then I would assume that it
>> isn't a GDI problem.

This is only the case if your operating system is a 9x. Under NTs, it's
perfectly possible for mozilla (or any other application) to have GDI resource
related graphical errors without affecting other applications. Of course, if the
application goes on to allocate even more resources, other applications become
affected. 

On NT, it's pretty easy to see if your graphical errors are GDI related - open
the task manager, view --> select columns, and add "User objects" and "GDI
objects". If mozilla is using several thousand GDIs, chances are the problem is
GDI related, while if it is only using one or two thousand, the problem is
likely somewhere else.

    
    

    
  
*** Bug 217175 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 217470 has been marked as a duplicate of this bug. ***

    
    

    
  
Reference comment #280:  

I have Mozilla 1.4 with Windows 98SE.  After switching profiles back a forth a
few times, I do indeed see a significant slowdown of other applications.  It
appears something is soaking up all resources.  If I exit Mozilla, the problem
with those other applications is significantly reduced.  

    
    

    
  
*** Bug 218234 has been marked as a duplicate of this bug. ***

    
    

    
  
I think I'm experiencing this bug with build 2003082704, on W98.
I also had it with 1.4.  After I've been using Mozilla for
a while, bringing up a new page in a new tab, or doing almost
anything, either doesn't refresh the screen, or refreshes only
one frame, or something else weird.  I can fix the display
by dragging the window off the screen then back on;  iconifying
and redisplaying doesn't fix the problem;  exiting and restarting
Mozilla doesn't fix the problem;  Mozilla is the only app affected;
rebooting does fix it, but of course it happens again quickly.

Can someone tell me if these symptoms indeed sound like this bug?

Also, in the workaround recommended in comments #69 and #147,
what is meant by:

   1. browse to about:config

???  Surely you don't mean go to Help/About Mozilla.  I don't
see anything resembling this in Edit/Preferences... -- there is
an entry for Disk cache, but that's not what this is about.  
Where/how do I browse to about:config?

Thanks,
-P.




    
    

    
  
since i didn't see anything in #255 to help peter out, forgive me if this comes
as just redundant spam.

peter:  about:config is something you type into the address bar and hit [enter].
 treat it like a url, basically.

    
    

    
  
Thanks, CJ, and several others who responded privately, for 
instructions on "browsing to about:config.  I've carried out the
changes, and the symptoms appear, so far, to be at least improved.
If this should turn out not to be the case, I'll post again.

BTW, I'm running 1.5b, build 2003082704.  If there is an implication
that the problem was supposed to be fixed in 1.5, it doesn't appear
to have been fixed for me.

If, after a few more days' experience, it should appear that even
effecting the workaround didn't fix it, then it's at least possible
that I'm exprienceing some other bug, or a new twist on this one.

Thanks again,
-P.


    
    

    
  
I want to ask what is the current situation of the GDI leak bug. Is it fixed or 
is their some implementation in the code that helps avoiding it. And what seems 
to be making the GDI leak.

    
    

    
  
A funny coincidence which I just noticed now while reading through all of this 
bug is that explorer.exe on win2k hogs gdi handles like hell when MouseKeys 
(from the accessibility panel) is turned on and shows its icon in the system 
tray.

I've just turned on the GDI handles column in the task manager to see Mozilla 
hog it up but instead explorer.exe peaked at 9,999 at which point I could not 
log out via the start menu but had to press Ctrl-Alt-Del and log out from there.

I started using MouseKeys around the time Mozilla 1.4 came out because I could 
feel the mouse's microswitch deteriorating, and while 1.4 definitely worsened 
the situation as many in this thread can attest, for me it was multiplied by 
this stupid explorer bug which made mozilla close to unusable.

    
    

    
  
If this is a blocking bug for 1.4 and 1.4.1, why is this listed neither as
blocking nor fixed for 1.5?  I have set the question mark for blocking 1.5.  
Flags: blocking1.5?
QA Contact: ian → nobody

    
    

    
  
This is not blocking 1.5. We've addressed our 1.5 problems in other bugs. 
Flags: blocking1.5? → blocking1.5-

    
  
Flags: blocking1.6a?
Flags: blocking1.4.2?
Summary: GDI Resources are used till the  UI/website displays faulty → GDI Resources are used until the  UI/website displays faultily

    
    

    
  
*** Bug 219529 has been marked as a duplicate of this bug. ***

    
    

    
  
I wanted to verify (as I promised I would) that the workaround
described in Comments 69 and 147 do indeed solve the problem for
me, on Win 98, using Mozilla 1.5b, Build 2003082704.

Thanks to those who helped.

-P.

    
    

    
  
I see this crashing problem appears to be back again. I just moved to: 1.5RC-2
20030925, and I'm crashing again too. Also back to losing history.dat at the
crash. No crashes from 1.5b through 1.5RC-1. This acts just like the GDI leak
again in that it happens at graphic rich sites, but the GDI Usage tool mentioned
here doesn't show really high usage. It also doesn't show many resources in the
free column though either. Is there a way to incorrectly free a resource so that
it isn't listed as in use, but still is not available?

    
    

    
  
I have made a new installation of win98 and my problems have disappeared,
running the nightly builds. I am running Internet Exploder 5.05 or so, IE6x
seems to make win98 more unstable. Any other having my kind of configuration?

    
    

    
  
Using Mozilla for some time on Windows 2000 SP4 causes the display to be bad
again. For me it looks like 1.5rc1 was better in handling GDI resources, than
1.5rc2.

Is it possible that the "Temporary fix: remove all Windows GDI optimizations" in
bug 205893 is not included in 1.5rc2?

    
    

    
  
I think there is a problem here.  From many previous comments it had seemed
that the GDI leakage problem was worked around somewhat effectively if not 
fixed.  I don't know about intervening versions, but I have been using
Mozilla Firebird 0.6 and I just tried MozFB 0.7rc3 , and the GDI behavior
looks to me to be identical (!)  Furthermore the problem seems to involve
using "many" tabs.

(Since FireBird bug 214127 is marked as a Dup of this bug, I believe this
bug is intended to cover MozFB as well as SeaMonkey Browser.)

------------------------------
Some details:
 Platform:  P3/900  running winME

 Old version:
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.4b) Gecko/20030516 Mozilla
Firebird/0.6
  (with many extensions installed)

 New (test) version:
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.5) Gecko/20030925 Firebird/0.7
  (with no extensions; installed with a fresh profile)

 My test procedure:
 - Start browser - GDI resources at around 63% available
 - Visit a graphics-rich site, in particular, a long review article
   at  http://www.tomshardware.com/
 - I can page through an entire article (15-20 screens) in one tab, and GDI
    goes down only slightly, to about 61%.
 - BUT, if I page through the article opening a new tab for each page,
    GDI availability goes down by 3% or 4% with EACH page of the article
    (even if it duplicates a page already in a tab).
    GDI availability gets to 0% before the end of the article.
    Get the usual mess.  If I quit MozFB soon enough, all seems
    to recover without a reboot.

BTW, the single-page test, http://robh.net/test.html, in comment #191
  did not crash either of these browsers, nor deplete GDI, even with
  six copies in six tabs.

------------------------------
I don't understand what is being said in Comment #293, but as far as I am
concerned, this bug should be in better shape than this before releasing
Moz-1.5 or MozFB-0.7 .

-Len


    
    

    
  
I concur that something got worse again in the 1.5 release series.


    
    

    
  
Another couple notes to add to my Comment #299:

 - Setting browser.cache.memory.capacity to 4096, as suggested in
   Comment #69 makes NO difference.

 - If, before getting to 0%, I close tabs, the GDI availability goes back
   up to (I think) its original "full" level.

-Len


    
    

    
  
And some more to add to my Comment #299 and Comment #301:

- I get the same behavior for MozFB nightlies  20030816 and 20030903.
  I thought it was supposed to be fixed somewhere in there.
Is my test exercising the same bug?



    
    

    
  
I was happy to see it solved in nighlty around 20030828 or 20030829 (one after 
1.5beta) but now it is broken again in rc2.. :-(

    
    

    
  
The temporary workaround for this bug has been tuned a bit for bug 216430.
Images are 'optimized' again, when they're larger than 128K. That might explain
this regression.

    
    

    
  
I can confirm the regresion. The things go worse again.

I couldn't feel any slowdown without the GDI optimization. Could you possibly
keep it out? :-)

    
    

    
  
the slow down in bug 216430 is very apparent when image optimizations are
completely disabled.  but, of course this bug makes it apparent that we need to
do better.

pavlov, tor, smontagu: do you guys have any suggestions here?  a quick "fix"
might just be to increase the HBITMAP threshold on Win9x.  i know that is not a
full solution by any means, but it might get us into the 99% ballpark.  any
suggestions?

    
    

    
  
I have been playing around with the patch for bug 205893 (attachment 131947 [details] [diff] [review])
that uses Dib Sections however I don't know much about DIB's to understand the
actual details.

What I have found is that using the latest trunk build (build id 2003071814) on
Windows XP is that bug 184933 is no longer fixed.  If you load a ton of images
(these all happen to be large) mozilla is un-usable.  However applying the patch
for bug 205893, mozilla again becomes usable.

I have yet to try Win98 with and without this patch.



    
    

    
  
Jim: Build 2003071814 is certainly not the latest trunk build. It is almost 3
months old!

    
    

    
  
I am SO SORRY for spamming this but my error, i meant build id 2003100708. 

    
    

    
  
Non-programmer trying to repeat an actual programmer's comments:

SetDIBitsToDevice() requires no hBITMAP and renders a memory resident raster
into  an hDC.

I have no idea if this is useful...  Just an offhand comment made by a vastly
better programmer than me when he overheard the problem description.

    
    

    
  
I don't know if it helps, but if this thing happens, the mail client also gets
the same effect (corrupted UI and page mainly when window is maximized). This
also affects Firebird and thunderbird.

    
    

    
  
Darin said:

>the slow down in bug 216430 is very apparent when image optimizations
>are completely disabled.

Are the display routines optimized to only Draw images which are at least
partially in view? My app uses only SetDIBitsToDevice which is slower but not by
much on halfway modern hardware. I couldn't even use StretchDIBits because if
the coordinates stretched over a certain size it would fail. (Hence I stretch
and clip myself and then called SetDIBitsToDevice.)

The problem with the device dependant support is that they are implemented by
the video card vendor so it's 'the ultimate' on some video cards and disaster on
others. To get my app to function consistantly, I render all visual elements to
a screen size dib and call SetDIBitsToDevice a single time to display it.

That's probably not feasable in Mozilla but depending on DDBs is asking for
trouble. I'm looking over nsImageWin.cpp but it's quite large so I'm not sure I
can help much.

I just read through bug 216430 and I suspect that there are some nasty problems
in the 'unoptimized' code. Calling SetDIBitsToDevice or StretchDIBits should not
cause this slowdown. If the code is fine then I suspect that it is being called
way too often. Someone said that selecting text with the mouse is very slow.
This would mean that with each WM_MOUSEMOVE message (which changes only a
character typically) the whole background is being repainted!? Perhaps there is
a clip rect which is not working. I do my own clipping before calling
SetDIBitsToDevice to speed thing way up.

    
    

    
  
*** Bug 222041 has been marked as a duplicate of this bug. ***

    
    

    
  
What's state is the "temporary" patch for this bug with 1.5 release? If image
optimization/ddb is still used without a problem being found and fixed in it
then 1.5 is useless on windows. I'll have to keep using this 20030812 nightly
build...

    
    

    
  
I agree. Summer mozilla builds were wonderful. I must reboot one or two times
every day with current ones. Not nice.

    
    

    
  
Everyone who is able to build from source, please try my patch in Bug #205893.

http://bugzilla.mozilla.org/attachment.cgi?id=131947&action=view

I don't think it will help people running W9x but it should not hurt. I have yet
to find someone who does not benefit from it (provided they experienced graphics
problems at all)

    
    

    
  
*** Bug 220599 has been marked as a duplicate of this bug. ***

    
    

    
  
can someone update severity to something other than blocker, since it's clear
the Mozilla PM doesn't feel the bug really blocks release (implied by the
release of 1.5).

or at least say the bug blocks, say release 2.0?  it's a sad joke to leave this
as a blocker if it's not going to be resolved as such.



    
    

    
  
I agree with comment #318 . This has been on 'blocker' status for many releases.
The blocker status appears to be a sham subject to whimsical override by
marketing(?) pressures, notwithstanding band-aids that may have been applied. It
probably isn't time to think up sabotage/conspiracy theories...yet.

    
    

    
  
This is certainly no blocker. According to the definition it is rather a
critical error. Marking as such.

Anyway, I believe the severity field is less and less important, especially
since the flag field was added.
Severity: blocker → critical

    
    

    
  
Jacek, there's nothing "certain" about that.  It makes Mozilla unusable, in
practice. I'd say this bug easily fits both "blocker" and "critical", since it
makes 1.5beta the last usable version of this browser under Windows.

    
    

    
  
It does not break compilation. It does not break the smoketests. Ergo, it's not
a blocker.

Please, let us not spam this bug to death. 



    
    

    
  
"blocker" status exists for bugs that prevent mozilla from being useful by
developers.  it means that tinderbox should not be open for checkins.  this bug
does not qualify under that status.

"critical" means it deserves increased attention because many users are being
affected.

    
    

    
  
WinME with Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.5) Gecko/20031007
set browser.cache.memory.capacity to -1 after updating Mozilla yesterday, today
I displayed a web page with a large JPEG, and the top half of the screen was
corrupted while the bottom half displayed correctly - used Mozilla to save the
image, and it displayed correctly in a windows viewer

The next page I clicked on locked up the browser, and I could not ctrl-alt-del
out of it - had to pull the power cord - will try
browser.cache.memory.capacity=4096 again.

I don't know if this should be a blocker, or critcal, or what, but I'm about
ready to pull build 2003081004 out of my backups and use that for a while as I
can't afford to crash out the whole system several times a day.

    
    

    
  
rr_mozilla@voicewizard.com: 
> It probably isn't time to think up sabotage/conspiracy theories...yet.

No, but it probably _is_ time for you to think up a patch - or stop spamming
this bug (not only you but all of those who are confusing bugzilla with a
newsgroup).

> This has been on 'blocker' status for many releases.
> The blocker status appears to be a sham subject [...]

Nope. The 'blocker' status has just been set by somebody to raise attention (see
comment #47): 
>I'm going out on a limb and raising the severity to BLOCKER to try to get
>someone's attention on this.

So don't expect _this_ status to mean anything to developers.

This bug (as have been others) is now just a playball for masses of bugzilla
"users", to get rid of their frustration. Do you consider even a small fraction
of the 320 comments really useful? Did you read all of them?
Bugs like this one are avoided by developers and they are right doing so. This
bug _is_ already dead and (most of) you killed it.

craigm@ragingbull.com:
> it makes 1.5beta the last usable version of this browser under Windows.

I am using 1.5final and 1.6a happily under Windows. So there must be something
wrong with your sentence and conclusion...
(There are also many funny definitions of "usable", most of them only invented
to justify calling something a blocker...)

    
    

    
  
From what I have been able to put together this bug happens as a result of the
way in which certain video cards process images. That is why it only happens to
some users and not all. If this is true could changing the video card solve the
problem at least until a fix is worked out?  

    
    

    
  
Yes, everyone affected by this bug should buy a new video card.

    
    

    
  
Can we please stop this? We are one step away from name-calling.

The facts are:
1) This is a very important bug/issue.
2) It's hard to locate because it's not very specific.

Now, if we can all cooperate, we can help the mozilla devs find where resources
are leaked. And I don't think this is one bug, just a general category of bugs.

    
    

    
  
this isn't about a bug being a "playball" or its current status.

it's about ensuring bugzilla is a serious tool for mozilla bug reporting and
resolution.

if it's not a blocker, don't raise the status to "blocker" just to get
attention.  keep it as severe.

if the mozilla team decides this isn't severe, *they* need to downgrade the
status in a timely manner.  it's been reported, and people watching/ reading/
voting want to see some feedback.

if it's been resolved or fixed or doesn't exist in current releases, this bug
needs to be resolved in a timely manner.  i don't believe any single person
working on mozilla is so busy that they couldn't work five minutes of bugzilla
updates into their workday.  believe me, people working on more critical
software projects than mozilla can do it.

the point is that every bug needs a timely update, or you might as well
restricted access to bugzilla, since the dates and statuses have become a public
joke. 




    
    

    
  
> if the mozilla team decides this isn't severe, *they* need to 
> downgrade the status in a timely manner.

And WHO is "the mozilla team" in your opinion?
If you're talking about paid developers, then there are about 5-10 of them now
(a guess). 
But since Mozilla is open source everybody can participate in developing it and
this way gets part of the team!

Actually now by participating in bugzilla YOU are part of the team and YOU have
equal obligation to do the things you want others to do.

> i don't believe any single person working on mozilla is so busy 
> that they couldn't work five minutes of bugzilla updates into 
> their workday.

You have the time? Fine, just go through the 200.000+ bugs and look if they are
still up-to-date. Please report tomorrow, when you are finished. Thanks.

(And how could - and should - a handfull of full-time developers correct the
mistakes many thousands of not-so-full-time developers do? And deal with the
protest some of their actions might cause?)

> the point is that every bug needs a timely update, or you might as well
> restricted access to bugzilla, since the dates and statuses have 
> become a public joke. 

No: bugzilla users should restrict themselves at least by reading, understanding
and obeying the bugzilla rules.
You did not - or can you explain how your comment can technically help solve
this bug?

You are partly right: some parts and aspects of bugzilla are a joke. But they
became one because of people like you who use bugzilla as a newsgroup (how was
your comment specific to this bug?) or people who change fields without the
proper knowledge about them.

    
    

    
  
changing OS to "ALL" as the dups of this bug show that this isn't win98 specific.
OS: Windows 98 → All

    
    

    
  
I'm not sure OS: All is really appropriate. It's very certainly a Win32 problem. 

I've looked through all of the duplicates, and looks like it shows up more
quickly on the Win9x line, and is better-masked on the more modern versions --
but in any case, no reports on old Mac OS (any flavor), Mac OS X, Linux, BSDI,
FreeBSD, NetBSD, OpenBSD, AIX, BeOS, HP-UX, IRIX, Neutrino, OpenVMS, OS/2,
OSF/1, Solaris, or SunOS.

    
    

    
  
> Actually now by participating in bugzilla YOU are part of the team 
> and YOU have equal obligation to do the things you want others to do.

No, I'm not part of the team.  I don't have any ability to change the status of
this bug.  I'm a reporter, for all intents and purposes.  On some, I'm a tester/
researcher.  Believe me, if I could, I'd make my small part of the Mozilla
project current.  But I can't.

> You have the time? Fine, just go through the 200.000+ bugs and look if they 
> are still up-to-date. Please report tomorrow, when you are finished. Thanks.

How do you extrapolate "five minutes a day" to "200k bugs per person"?

Wow, the impact of your statement falls dead at my feet. 

> (And how could - and should - a handfull of full-time developers correct the
> mistakes many thousands of not-so-full-time developers do? And deal with the
> protest some of their actions might cause?)

You just said we're all part of the team.  Empower us, or do your job.

> No: bugzilla users should restrict themselves at least by reading, 
> understanding and obeying the bugzilla rules.
> You did not - or can you explain how your comment can technically help solve
> this bug?

I understand the rules.  When bugs get updated in a timely manner, we'll all get
back on the map.

Until then, fellow rulebreaker, we're going to use bugzilla as a mailing list
until someone steps up and addresses the problem.

You fail to acknowledge that this bug was labeled "blocker" and the release
still occurred without addressing it.  *That* is my favorite joke.

> You are partly right
<snip>

I'm completely right.  That's the problem.  You want it both ways: reporters
report bugs, research workarounds, and see bugs labeled as "blocker" and
"severe" get ignored, without any feedback to the people reporting these bugs or
working to narrow down the problem.

But in your mind, that's okay, because we're too stupid to change the status or
too unreliable to figure out that it's not a blocker, really.  We don't deserve
a rationale or explanation for why this bug doesn't get fixed.

Hey, thanks for the update.

    
    

    
  
Everybody who is posting comments here, unless you have anything technical to
contribute, by which I mean:

(a) a patch that fixes the problem, or
(b) insightful technical suggestions about a possible fix,

please SHUT UP. Every time you post, you are wasting more than 100 people's time
by spamming them with useless comments that do not add any value to this bug. 

Mozilla is open source software. That means:

(a) The developers have NO OBLIGATION to do what you want them to do. Like it or
not, whining will only make this bug less likely to be fixed.
(b) If you want something fixed, FIX IT. You have all the means to do so. If you
don't know enough, learn. You have all the code and all the Internet at your
disposal.

Posting here only makes things worse, because it annoys the only people who have
sufficient knowledge to fix the bug.

    
    

    
  


  
Don't know if this will be of any help, but thought I'd see.  There are 4 txt
files in the zip.  The two named START are snapshots of the DLLs and Handles
being used by NS7.1 right after is was started.  The other two are snapshots of
the DLLs and Handles in use by Netscape when system GDI resources are at about
9%.  Just
about ready to "ugly up" the screen.
Hope this info is of the kind that will give some insite into the problem.
BTW, these shots were done with PROCESS EXPLORER.  If this is useful info and
you would like more please let me know.  
Thanks!

Ken Fowler

    
    

    
  
*** Bug 226297 has been marked as a duplicate of this bug. ***

    
    

    
  
about:config browser.cache.memory.enable = false seems to help
avoid this problem, but due to some other bug, some pages fail
to display at all; see bug 227083

    
    

    
  
If the image optimization code is written correctly and not leaking but the
sheer volume of images is causing problems with some video drivers then perhaps
this would be a good solution. Write an accurate test function to determine if
each individual image is at least partially in view: The main window is in
focus, the tab it displayed in is the one in view, it is not scrolled totally
out of view, perhaps others. Then if this is the case we generate an optimized
copy of the image and display with that. Any optimized copies not in view are
freed or reused. Perhaps a simpler way would be to generate an optimized copy
when ever a image is displayed and after each full screen refresh free any
optimized copies which weren't just used. This way only the 1 to 20 needed are
held in memory, optimization is used always to display images but only as needed.

    
    

    
  
*** Bug 201106 has been marked as a duplicate of this bug. ***

    
  
Blocks: 64401

    
    

    
  
Sometimes more data is cached (in pages with much and big images) then should be
done (bug 213391). So it's possible that the workaround in comment #147 will not
always work.
Depends on: 213391

    
    

    
  
Looking on four machines, two with a quite newly installed win98, and two with
installation done a while back. The old installations exibit the problem, and
the newer don't. Can it be that some program messed up a dll or so? The old
machines had really many installations and removals, so there were many changes
for such a mess-up. One of them had IE6.0 while the other IE5.0. I can't really
think of any special program poking deep into windows except windows media player.

    
    

    
  
*** Bug 230756 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 228750 has been marked as a duplicate of this bug. ***

    
    

    
  
A page which shows this bug immediately is
http://www.scat.demon.co.uk/zertz/strategy.htm

This is in Mozilla 1.6, WITH the browser.cache.memory.capacity workaround
in place.  Also note that the related bug, that some pages won't display
at all if browser.cache.memory.enable is false, is still present in 1.6

Meanwhile, back in mozilla 1.3.1, everthing is fine.  I guess I may
be stuck using 1.3.1 forever.

    
    

    
  
(In reply to comment #344)
> A page which shows this bug immediately is
> http://www.scat.demon.co.uk/zertz/strategy.htm

I believe the above page is demonstrating bug 225977
(though that bug could likely be related to this one)

    
  
Flags: blocking1.4.2? → blocking1.4.2-

    
    

    
  
*** Bug 221414 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 184933 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 234862 has been marked as a duplicate of this bug. ***

    
    

    
  
Duplicate reporters able to compile on their own, try my patch at #205893. This
fixes the problem. And bug the reviewers to have a look at it. I have been
waiting for it for months.

    
    

    
  
Adding bug 98835 (the one bug 213391 was duped against) to the dependencies.
Depends on: 98835

    
    

    
  
Removing bug 98835 from the dependencies as bug 213391 was reopened (wrong dupe,
it seems). Sorry for the spam.
No longer depends on: 98835

    
    

    
  
It seems that the GDI problem was fixed just before ver 1.5RC-1 and is now a new
problem since ver 1.5RC-2. I crash 4 to 6 times a day, always when some number
of large jpegs are loaded on a page that is partly off screen. This is either a
video hardware problem or a CPU problem as I've cloned my system to two other
machines (updating only motherboard & video drivers) and neither of those
machines ever crash (I have several pages that guarantee an immediate crash for
testing). The non-crashers are celeron & athlon with PCI video or AGP video with
oncard memory. The crashing machine is a pentium4 with AGP video using shared
memory.

If anyone here can send me a patched version for testing, or any test tools
they'd like me to try, I have all three machines here and have a good bit of
time this coming week to do tests.


    
    

    
  
(In reply to comment #352)
> The non-crashers are celeron & athlon with PCI video or AGP video with
> oncard memory. The crashing machine is a pentium4 with AGP video using shared
> memory.

The Shared Memory used by your on-board AGP video card shouldn't be a problem.
However, that said, could you send me (via eMail) the make and model of your
motherboard.

    
    

    
  
One thing I've noticed in the last couple of days is that Mozilla isn't always
checking the return code from the WIN32 GDI functions it calls.

I plan to create a new bug for those function calls that don't check the return
code.

    
  
Depends on: 236415

    
    

    
  
(In reply to comment #349)
> Duplicate reporters able to compile on their own, try my patch at #205893. This
> fixes the problem. And bug the reviewers to have a look at it. I have been
> waiting for it for months.

As mentioned in http://bugzilla.mozilla.org/show_bug.cgi?id=205893#c76
which is a bug this one depands on, a Firefox build is now available
that is said to include this patch.

I downloaded this build (along with msvcp71.dll and msvcr71.dll
from http://www.dll-files.com/) .  Then I tried the "Tom's Hardware" 
test that I described in comment #299.

This build behaved EXACTLY the same as before.  Looks like there is
something wrong with at least one of: the build, the patch, or my test.


    
    

    
  
WFM in scragz' build today:
http://forums.mozillazine.org/viewtopic.php?p=429427#429427

*** This bug has been marked as a duplicate of 205893 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE

    
    

    
  
WFM Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7b) Gecko/20040313

strange plugin behavior though in that about plugin is blank even though they
seem to be working

    
    

    
  
As I tried to say in comment #354, I don't believe this problem is fixed.
Could somebody please explain what is wrong with my result, or what further
information you need?

I just tried again with the scragz build:
 -  MozillaFirefox-2004031301-O1-G6-SSE.7z
 -  winME on a P3
 - With FF open, GDI resources start at 69% available
 - visit  http://www6.tomshardware.com/motherboard/20030825/index.html
 - open each new page in a new tab
   - each page reduces GDI by about 3 or 4%
   - same result even if the page is already in a tab
 - after 21 pages GDI is down to zero and the display system starts to fail

Is this the expected/correct behavior?
Does it not demonstrate this bug?
Should it be filed as a new bug?

??????

-Len


    
    

    
  
Len,

I think you are talking about Bug #236415 that I'm working on, albiet slowly.

My theory is that Mozilla isn't checking all the time for a lack of GDI
resources by assuming function calls work. And thus is killing MS Windows.

    
    

    
  
FWIW, In my experiments with Win2K I have caught CreateDIBSection
failing (presumably due to lack of resources) but getLastError()
returns 0.  This ought to be impossible, but given that it occurs,
make sure this doesn't cause a bug.

Also FWIW, noticing resource exhaustion is good, but it's not enough.  
Mozilla is a CAUSE of resource exhaustion, and that also needs to be
fixed.   It doesn't require a malicious program to cause mozilla to
become a resource exhaustion culprit.



    
    

    
  
How is this resolved? 1.6 and 1.7a both exhibit the same behavior. Is it fixed
for the imminent release of 1.7b?

    
    

    
  
(In reply to comment #361)
> How is this resolved? 

You can look far yourself: this is resolved as dup of bug 205893.

> 1.6 and 1.7a both exhibit the same behavior.

To understand that you have to look at bug 205893 comment #84. You will find it
suggests the fix was checked in on 2004-03-12, that's four days ago.
That means 1.7b will have it, while there is no way for 1.7a to have the fix.


    
    

    
  
*** Bug 232824 has been marked as a duplicate of this bug. ***

    
  
No longer blocks: majorbugs

    
  
Blocks: 334359
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: