Closed Bug 204374 Opened 22 years ago Closed 21 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 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: 21 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: