Closed
Bug 207796
Opened 21 years ago
Closed 21 years ago
display rendering degenerates and dies
Categories
(Core Graveyard :: GFX: Win32, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 204374
People
(Reporter: ddyer, Unassigned)
Details
(Keywords: crash, stackwanted)
Attachments
(1 file)
40.00 KB,
application/x-msdownload
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 Build Identifier: mozilla 1.4 rc 1 this bug was also present in prevvious 1.4 releases. After a few minutes vigorous browsing with 2 windows open, page rendering starts to decay - parts of the screen fail to refresh when scrolling or paging from one page to the next. This effect was so severe I had to uninstall and revert to the stable release. Reproducible: Always Steps to Reproduce: 1. just browse for a while. 2 windows seem to help 2. 3.
Comment 1•21 years ago
|
||
1.4rc1 wfm and several other ppl on Win2k -> does not block development -> not a blocker. Did you properly uninstall Mozilla 1.3.1 before installing 1.4rc1 ? Possibly using add-ons ?
Severity: blocker → critical
Keywords: crash,
stackwanted
no, I just installed the new one into the same directory. If uninstalling the prev version is a requirement, the installer ought to tell me so. (If correct, this makes this an installer bug)
Comment 3•21 years ago
|
||
if that helps, mark this a dup of Bug 123907.
I tried reinsalling to a clean directory, and got similar results. One additional clue is that when I tried to take a screen snap of the corrupted display, the screen snapper reported "not enough storage is available to complete the request" .. but when I gave up and exited netscape, the screen snapper immediately got better. It really seems like the problem is related to memory fragmentation caused by images. The principal page I am browsing on is my photo album page http://www.andromeda.com/people/ddyer/photo/albums.html just go down the page and try all the sample albums. Use several windows at once.
I did some additional dective work to find why "srip32" is unhappy at the same time that mozilla's display rendering is decaying. I found that calls to "CreateCompatibleBitmap" with reasonable parameters are unexpectedly failing. I'm entertaining the theory that the immediate bug in mozilla may be not noticing an unexpected error return of this type. That would be consistant with the observed behavior. There would remain the deeper question of why CreateCompatibleBitmap (or something like it) is failing in the first place, and in this build of mozilla and not in 1.31
Comment 6•21 years ago
|
||
which URL exactly are you visiting ?
Start at http://www.andromeda.com/people/ddyer/photo/albums.html open a second window also at http://www.andromeda.com/people/ddyer/photo/albums.html from the second window, visit each link on the left hand column in turn; on the "sample albums" click to visit the album (seeing thumbnails) and on one of the thumbnailed pictures, then back up to the starting page. My browser starts to go wierd at about "grovestreet.com". There is nothing special about these pages. My current thinking is that the underlying problem is some kind of resource management error in my display drivers, leading eventually to CreateCompatibleBitmap starting to fail, which it should never do. My machine is a new dell running win2k with 512m of physical memory, so it shouldn't be "out" of any common resource in such a short expetiment. However, mozilla's part in this is that it doesn't notice the problem and so looks like it is broken itself.
this program is harmless, or compile it yourself if you're paranoid.
More evidence. The following program fails at bitmap 85 on my win2k machine, which has a hot graphics card (geforce4 mx 420) and 512m main memory. The same program runs all the way to 100 on my old nt machine which had an vanilla graphics card. My guess is that win2k is treating "screen compatible" bitmaps as a limited resource, and the new version of mozilla is using them for general storage of cached images. // See how many screen bitmaps can be allocated // #include "stdafx.h" #include "windows.h" #define DIMW 1024 #define DIMH 1024 #define NUMBER 100 int main(int argc, char* argv[]) { HDC hdc = GetDC(0); HDC hMem = CreateCompatibleDC(hdc); HANDLE bitmaps[NUMBER]; long i; printf("Hello World!\n"); for(i=0;i<NUMBER;i++) { bitmaps[i]=CreateCompatibleBitmap(hMem,DIMW,DIMH); printf("Bitmap %d = %x\n",i,bitmaps[i]); if(bitmaps[i]==0) { break; } } for(; i>=0; i--) { DeleteObject(bitmaps[i]); } DeleteDC(hMem); DeleteDC(hdc); printf("Done\n"); return 0; }
Reporter | ||
Comment 10•21 years ago
|
||
Final word (ha, you wish). Google conversations seem to universally recommend CreateDIBSection rather than CreateCompatibleBitmap; CreateDIBSection is limited only by available memoey, whereas CreateCompatibleBitmap is subject to arbitray and ill defined limitations on size and number of bitmaps.
Reporter | ||
Comment 11•21 years ago
|
||
One more comment. This problem is not new to 1.4, it also occurs in 1.3.1 but with much less frequency. When this problem has occurred, lots of things stop working; I can't take screen snaps, my thumbmailer won't show thumbnails, and launching adobe photoshop crashes. Clearly, a bad state of affairs. I'm fairly certain that the root problem is that everyone is treating device dependant bitmaps as an inexhaustable resource. whereas the video drivers on my system are treating it as a finite resouce. Perhaps this is wrong, but there are probably a few million computers out there with my video board, so it is likely to remain a problem. Mozilla is unneccarily consuming a limited resource. Just use DIBs!
Comment 12•21 years ago
|
||
Marking NEW, since it has an analysis.
Status: UNCONFIRMED → NEW
Component: Browser-General → GFX: Win32
Ever confirmed: true
Comment 13•21 years ago
|
||
Did you look at: Bug 204374 GDI Resources are used till the UI/website displays faulty
Reporter | ||
Comment 14•21 years ago
|
||
*** This bug has been marked as a duplicate of 204374 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Updated•15 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•