Closed Bug 128961 Opened 23 years ago Closed 22 years ago

Image stretched about 2048x crashes Win9x with nvidia cards

Categories

(Core Graveyard :: GFX, defect, P2)

Product:
Core Graveyard
Component:
GFX
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED INVALID

People

(Reporter: alistair.vining, Assigned: dcone)

References

(
URL
)

Details

(4 keywords, Whiteboard: Update your nVidia drivers to v30.82+)

Attachments

(5 files, 1 obsolete file)

Required single-pixel image
43 bytes, image/gif
Details
Testcase reduced from http://www.alternet.org/story.html?StoryID=12420
8.02 KB, text/html
Details
Minimal testcase
115 bytes, text/html
Details
Simple C++ project that crashes nVidia Drivers on Win98
4.09 KB, application/zip
Details
1 pixel stretch patch
1.71 KB, patch
Details | Diff | Splinter Review
The above URL loads partially and then the browser crashes with a 'divide error'. Talkback does not appear. The browser window does not disappear and cannot be removed.
Build: 2002-03-04 03:00 and one from 2002-02-26.
WFM 2002030403/Win2K
Keywords: crash
worksforme with win32 build 03/05
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
There's now someone else who sees this: news://news.mozilla.org/3C9B74AD.1030802%40anon.com , also on Win98SE, so I'm going to have a go at attaching the fairly minimized testcase I'd drawn up. As well as the alternet.org story and http://www.techbargains.com from the newsgroup report, http://www.mongoliatoday.com also crashes with the same error.
Attached image Required single-pixel image —
I just tried the testcase, and got the divide error using build 2002031903 on Win98SE. It didn't crash my machine totally, but Mozilla certainly wasn't happy. In fact, all 3 windows I had open at the time remained in existance, although not responsive (just a blank grey screen). CTRL-ALT-DEL didn't list Mozilla as a running process, and I couldn't restart Mozilla. When I did a restart of Windows it looked like parts of Mozilla were still out there, but unresponsive. This bug needs to be reopened.
A small addition to my previous comment. While I'm running a Talkback enabled build, there is no Talkback session as this wasn't caught by Talkback...
Three's a crowd.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
On a hunch, I did some research on Macromedia Flash, as one of the people on the newsgroup reported used the same version as I'd just upgraded to. In doing so, I found bug #26510 and bug #58339 which seem to refer to the same version of Flash and the same sort of problem as reported here. Now, one could say this is a Macromedia problem. However, with the prevalence of Flash on the Web and as we get close to v1.0 of Mozilla, something needs to be done to at least prevent Mozilla from crashing. ASA: as a Driver, what do you think? Should this be a blocker for v1.0?
Seems to me Flash is a distraction: bug 58339 is Linux-only. (Bug 26510 has nothing to do with Flash). The crash occurs on pages with no flash content. FWIW I'm using the plugin version 5.0 r30 shared with a NS 4.x installation. All the pages do use single-pixel gifs within table layouts. The testcase only crashes when the gif is loaded (or, displayed). Other than that, the mongoliatoday.com site has odd constraints on the height of cells (height=2418, etc.). It's a nasty crash, but if it really happened regularly with complex table layouts, people would have seen it much more. I'll do some more research, but every advance costs 20 reboots.
OK, I agree, it isn't Flash that is doing this. As for the crashing/rebooting thing, it's about now that I really want an OS where a program crash doesn't take the OS with it. (No, this isn't the place to get into a discussion about various OS features). However, I would like to know if this only happens on Win 98?
For what it's worth, Netscape 6.2.1 doesn't crash with the testcase, so this is a regression.
Worksforme with recent build and K6-2. Does this bug only occur on Athlon systems?
I still see this with 2002042908-TRUNK on an AMD K6-2 500Mhz. Same symptoms as I discribed in comment #7.
*** Bug 141365 has been marked as a duplicate of this bug. ***
I do not crash with 2002050208 on win95b on a AMD K6-2 333 In bug 14089 the reporter had the same problem, but it was gone. I'll ask the reporter, what he have done.
*** Bug 140389 has been marked as a duplicate of this bug. ***
Re: Comment #14: no, this doesn't just occur on Athlons (I have a PIII-600). Re: Comment #17: you have the wrong bug no, bug 14089 is about UI typos. Tested today with 2002-05-02 08:00 (trunk) build and it still crashed at the original URL.
Excuse I mean Bug 140389 but he had again the same problems and marked in Comment 18 the bug as dup.
We need a stacktrace or a talkback ID or we can never fix this bug.
Keywords: stackwanted
*** Bug 145172 has been marked as a duplicate of this bug. ***
Hmmm, we have a testcase. Talkback isn't catching this. So, if someone can tell me how to get a stacktrace under Win98SE, I'd be happy to get you one. By the way, it still crashes with build 2002051704-TRUNK.
You must build yourself a debug build to get a stack trace. (You need MSVC++ 6) see www.mozilla.org/build I have a debug build but i can't reproduce this crash...
Oh well, I can't help then. I don't have Microsoft Visual C++. Unless, the Mozilla team put debug builds on their website.
over to those who have time
Assignee: asa → Matti
Status: REOPENED → NEW
QA Contact: doron → imajes-qa
ahve ytou tried with a new profile?
WFM on the 0507 build.
Just tried with a new profile using all default settings. Exact same problem, hang, crash and burn...
Over the weekend I found another web site that causes this "divide by zero" crash. http://www.pioneerelectronics.com I haven't fully sorted out the steps to reproduce, but it seems to have something to do with logging in to get to semi-restricted pages.
There's a gdb backtrace of this bug in Bug #131572. More info on this bug can also be found in Bug #131466 and Bug #134170.
That should be Bug #131446, not Bug #131466.
>gdb backtrace of this bug Why are you sure that bug is the same ?
All of the bugs I mentioned, including this one, cause an error dialog reporting "MOZILLA caused a divide error in module <unknown> at 0000:00000204." Then Mozilla hangs.
I agree with Joshua. Bug #131572 is a dup based on comments (especially number 7) Bug #134170 probably is a dup as comment number 14 is the same as what I get under windows when restarting. Bug #131446 is probably a dup, although there isn't enough information there for me to be sure.
Mozilla just crashed Windows 2000 SP2 and rebooted my computer! When I clicked a link at http://www.abcnews.go.com/ Windows just simply rebooted after writing a minidump file. I don't know if this crash was caused by Mozilla or if it was just bad luck (or a lousy ring 0 driver) and unfortunately I was not able to reproduce it, but maybe this information I found in the minidump file Windows created might help to find out what caused this problem. stack backtrace: kd> KD bcc849bc ???????? bcc849c0 0000001e bcc849c4 c0000005 bcc849c8 a000f213 bcc849cc 00000001 bcc849d0 3dc93d09 bcc849d4 3dc93d09 bcc849d8 3dc93d09 bcc849dc bcc84dac bcc849e0 0000026a bcc849e4 00000020 bcc849e8 ffffff04 bcc849ec 0000021e bcc849f0 00010017 bcc849f4 000002d3 bcc849f8 000000d2 bcc849fc 00000220 bcc84a00 00000155 bcc84a04 00000271 bcc84a08 00000000 loaded modules: kd> LM start end module name 80400000 805a2c00 nt (no symbolic information) Unloaded modules: ba717000 ba73b000 kmixer.sys ba717000 ba73b000 kmixer.sys ba717000 ba73b000 kmixer.sys ba717000 ba73b000 kmixer.sys ba822000 ba846000 kmixer.sys bd1c0000 bd1e4000 kmixer.sys be95e000 be96b000 DMusic.sys be96e000 be97c000 swmidi.sys bd84a000 bd85f000 VGA.dll bd528000 bd85f000 nv4_disp.dll (Nvidia 28.32) eb560000 eb569000 redbook.sys eb800000 eb805000 Cdaudio.SYS eb8d8000 eb8db000 Sfloppy.SYS registers: kd> R eax=ffdff13c ebx=0000001e ecx=bcc849f0 edx=8046936f esi=bcc84dec edi=bcc84d98 eip=804302a9 esp=bcc849c0 ebp=bcc84d7c iopl=0 nv up ei ng nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00200286 nt+302a9: 804302a9 ?? ???
Ok, I built Mozilla RC3, and tried stepping through the testcase above. I'm not at all familiar with the Mozilla source, so please bear with me when I describe what is happening. BTW the machine I'm using is an Athlon 1.4 GHz, 512MB of RAM, and using Win98SE. First off, I noticed that Mozilla won't crash unless the part of the screen that actually displays the webpage is showing. In other words, if I move the Mozilla window down the screen far enough that only the navigation toolbar and the menus show, Mozilla won't crash when I load the testcase. As soon as I move the window back up enough to show part of the webpage, the divide error occurs. I stepped through the code while loading the various webpages that cause this problem, and the divide error seems to always occur at line 617 of nsImageWin.cpp. This line is: ::StretchBlt(TheHDC,aDX,aDY,aDWidth,aDHeight,srcDC,aSX,aSY,aSWidth,aSHeight,rop); If anyone has any suggestions on where to go from here, or any tests you want me to try, let me know.
which video card do you use ? Do you get this crash if you disable Image loading ?
Nope, as I mentioned in Bug #131446, Mozilla doesn't crash when images are disabled. This is true for all of the pages that cause this divide error. My video card is a GeForce Ti200.
dcone@netscape.com: Can you help here ? This seems to be a win98 problem : see also bug 146316, bug 148234 and others...
one strange thing that I noticed (using Elsa Erazor X (GeForce256 chip)) is that when I loaded mozilla with -console option (to press CTRL+C there to shut down hanging mozilla) I do not get the crash at all...
-> GFX for triage
Assignee: Matti → kmcclusk
Component: Browser-General → GFX Compositor
Keywords: regression
QA Contact: imajes-qa → petersen
This link will crash mozilla for me too http://www.alternet.org/story.html?StoryID=12420 (as will http://www.artofcinema.com (which I already reported and is bug number 149773 which might be the same with this one)). I use Windows 98 Se have an Intel P2 350mhz and nvidia Gforce2Mx card 256mb of ram and the latest build Mozilla 1.0 (2002053012). And btw when I try to alt-ctrl-del it Mozilla won't show up (the pages are there). Then I try to shutdown and after some time I think talkback tries to load nd hangs up anything. Then I need to reboot. BTW it doesn't seem to be flash related because I have no flash plug-in installed.
This link will crash mozilla for me too http://www.alternet.org/story.html?StoryID=12420 (as will http://www.artofcinema.com (which I already reported and is bug number 149773 which might be the same with this one)). I use Windows 98 Se have an Intel P2 350mhz and nvidia Gforce2Mx card 256mb of ram and the latest build Mozilla 1.0 (2002053012). And btw when I try to alt-ctrl-del it Mozilla won't show up (the pages are there). Then I try to shutdown and after some time I think talkback tries to load nd hangs up anything. Then I need to reboot. BTW it doesn't seem to be flash related because I have no flash plug-in installed.
I have a question which might help with this bug. Do the people that see this bug use a GeForce video card (or a card using a GeForce chip)? Or, more simply, is there anyway seeing this that don't have a GeForce card? I see a few comments related to GeForce, and I also use a GeForce card.
I can try installing my old TNT1 Card but it's an nVidia chip again. I may install it tomorrow and try again. A friend using a geforce 3 (and a high end pc in general) had no problems (he uses windowsXP tho).
Blocks: 146316
from 146316 : - It goes away if I turn my hardware acceleration 1 or 2 notches (Control Panel->System->Performance->Graphics...)
Attached file Minimal testcase —
Minimal testcase: <HTML><BODY> <img src="http://bugzilla.mozilla.org/attachment.cgi?id=75769" width=1 height=2048> </BODY></HTML> I'm not kidding, this crashes me 100% of the time. Other people, do you crash on this?
Changing summary to reflect current knowledge of what causes the bug.
Keywords: testcase
Summary: Site crashes mozilla and forces reboot → Image stretched to >= 2048 pixels crashes Win9x with nvidia cards
*** Bug 146316 has been marked as a duplicate of this bug. ***
I crash on your minimal testcase. I also noticed that in the original testcase if the height of the image is changed to 99%, it doesn't crash.
I can verify that the problem does go away if I decrease the hardware acceleration. However, in Mozilla 0.9.8 I had hardware acceleration set to full and this problem never occured.
Joshua, could you step through the code again? Maybe StretchBlt() is failing but the return value is not being checked, so the resulting image has zero size, causing a divide error. What do you think?
Joshua: probably it doesn't crash at 99% because 99% brings it under 2048 pixels: if the height of the image in the testcase is changed from 2048 to 2047 no crash occurs.
*** Bug 149773 has been marked as a duplicate of this bug. ***
I verify too that the problem goes away if you reduce hardware acceleration.
I think there may be two bugs here. First is in nVidia's StretchBlt() code, which is causing the actual divide error that makes Mozilla & Windows crash. The second is in the code that scales images. I'm not too sure about the second one, it's just a hunch I have because it used to work in Moz. 0.9.8. If the image in the original testcase is set to 100%, when it finally gets to StretchBlt, the aDHeight parameter is 2059. I'm guessing that on the same page in 0.9.8, aDHeight is <= 2047. What decides what 100% height is? Or maybe I should say what SHOULD decide what 100% height is? Which method is correct, the one in 0.9.8 or 0.9.9 and beyond?
Joshua: height=100% means the the image is as tall as the cell that contains it. The height of the cell is determined by the height of the cell that contains the text, so it is influenced by factors such as text reflow etc. Does 0.9.8 crash on the testcase?
Both testcases load without any problems using 0.9.8.
I've never been able to get my nVidia card to successfully work on my Win98 machine (if I remember correctly, nVidia had some stringent hardware requirements, and my system wasn't up to snuff), so all I can say is that it WFM on Win98 w/Matrox card. First thing I'd recommend doing is updating your nVidia driver and see if the problem goes away. There's also a 1% chance that Bug 87819 will fix this problem. It's DrawScaledImage fix includes checking width & height and exiting before draw(..) if they are 0.
I already have the latest drivers and it still crashes. BTW don't use www.artofcinema.com as a testcase anymore (if you previously did) cause I deleted the stretching images and replaced them with table backgrounds so I won't crash anymore.
How about the latest DirectX drivers? If I remember correctly, nVidia required the latest DirectX drivers. It's a long shot, but worth a try.
I redownloaded and reinstalled the latest nVidia drivers, and have the same problem. I also had a quick look at their FAQ's, but there didn't seem to be anything interesting there.
Yeah and the latest directX. I did some testing. I got a big image (640x480) and stretched it's height to 2500 and opened the html with mozilla and I was about to hit reset when I noticed...It didn't crash! So it's more like it's stretched more than 2048 times of it's original size which means that the 640x480 image should be strethed to 640x(480x2048=983040). I think you should change the summary again. I will do some more testing tho.
Ok I was right. Made a 1x2 image. Height Worked size 1000 ok 2000 ok 2049 ok 3000 ok 4000 ok 4097 crash
Nick, could you try Height of 4096 on that 1x2 image so we can determine if crashes at > 2048x or >= 2048x.
While we know there is a problem with Height, is there a similar problem with Width? Based on an educated guess, does a width > 2561 cause the same problem? For those who care, my educated guess is based on max resolution (at least on my card) and memory support.
I tested 4096 height and it crashes too. The weird thing is that I also tested 4095 and it crashes again (!) So I tested the whole 4090-4095 range and the lowest height that crashes the program is 4095 (always talking about an image with a 2 pixel height). So i thought it's maybe 2048x -1 so i tested a single-pixel image at 2047 but it worked fine. So 1 pixel height crashes>=2048 2 pixel height crashes>=4095 I am too tired and sick of rebooting today so I won't test a 3 pixel or 4 pixel height image (to see if it keeps the 2048x -1 if it's over one pixel or it goes like 2048xN -(N-1) (N=Original image height) or maybe even something like 2048xN -(N-1)^2 ). I may test the rest tomorrow morning (it's 23:25 here) if there is still a need for the results. About the width I didn't try it but I guess it should be crashing too. The thing is that we probably won't see any images with width stretched that much. I can test it but if it crashes it's the same bug. If it doesn't will only know that the bug affects height only (which I don't think it's the case)
I'd like to know if a 1x1 jpg image will crash at a 2048 stretched height, or if this is just a gif thing? Can someone test and post their results?
Width crashes it too (did some more tests). Now something weird A 5 pixel images crashes at 10232. So we have 1 pixel at 2048 2 pixel at 4095 5 pixel at 10232 I can't seem to find a pattern here. it looks close to 2048xN -2x(n-1) but that's not it... I will test the jpeg thing now but I am 99% sure that it will crash too...
As I expected Jpeg crashes it too. I can't find the algo for the crash size/height size. It may be logarithmic (or some other mathematic terms that I don't know how they're called in english (native language is greek and I am studying maths in University of Athens). Whatever the case I need some more tests. I will try to make them tomorrow if the developers think it is important (still I think that my tests are not very important for the bug solving -It's the stretching code that has bugs and needs a new way to hadle stretching (one that will not make nvidia cards crash) (the pattern would be more useful to nVidia now that I think of it)).
The pattern is n*2048 - 2^(n-2). Is this bug something that Mozilla should compensate for, or should we try to get nVidia to make their driver behave properly?
We shouldn't be drawing anything >= 2048 height in the first place. We should be only drawing the height of the image that's currently in display. This would make the crashes only occur on Win98 with video modes > 2048. I'll look into how much work it'll be to "draw area only needed for display, not area needed for image"
You're right about the pattern. I filly silly for not figuring it out in the first place. (boy I need some sleep). Telling nVidia about it should be a solution but then again isn't there a way to fix it in mozilla? I mean how does IE6 manage to handle it with no problems? Arron's idea seems nice. I suggest telling nVidia about it AND finding a way around it..
Actually I'm not sure about my pattern now. It turns negative when N=18. Also, I couldn't get a 5 pixel high image to crash at 10232. Maybe it is different for different cards?? At any rate, I agree, Arron's idea sounds good.
In that case 2048xN -((N-1)^2)/2 seems to be right if 1/2 is treated as 1... ĂŚ am pretty sure it crashes at 10232 to me.
I am observing the same crash using Mozilla 1.0 {Build ID: 2002053012}. AMD Duron 1.0Ghz (Morgan Core) 256Mb SDRAM NVIDIA GeForce2 GTS-V (Detonator driver version 28.32) Windows ME Seems like the same crash as http://bugzilla.mozilla.org/show_bug.cgi?id=131446 as Lorenzo Colitti pointed out in comment #20.
Yes Bug #131446 is a dup of this one. Can someone who has the appropriate authority mark it as so?
It appears Opera has/had the same problem: http://groups.google.com/groups?threadm=MPG.170958b8d75d26189896c0%40news.opera.no After looking into the code, I believe this bug can not easily be compensated for. We depend on the OS (& thus the video card) for stretching bitmaps. The reason we always pass the full height of the stretch is to give a consistent stretching. I could probably put a HACK in that would take care of images with 1 height being stretched. It's not my preference though. The best solution is for nVidia to fix their Win98 drivers, and in the mean time, for Win98 people to change Video Accelleration to number 2 (basic accelleration) as the Opera thread mentions. I'll look some more
*** Bug 131446 has been marked as a duplicate of this bug. ***
I'm guessing more along the lines of: 2048 * (2047*(n-1)) My theory is that nVidia Win98 video drivers can not StretchBlt/StretchDIBits one line to 2048 lines (or beyond). So a 5 height image should crash at 10236 (4 of the lines stretched to 2047, and one at 2048), but not 10235 (5 lines stretched to 2047) The more we can nail this down, the more likely nVidia will listen.
Well I am pretty positive that it crashes at 10232 at my machine with a five pixel high image.
Having nVidia fix their drivers is ok but 1) IE manages to do it. 2) (and more important) it works with mozilla 0.9.8..!! Can't you just see how 0.9.8 handled stretching?
Hmm. The article Paper posted refers to Windows 3.x, but the same problem is present in Windows 95/98/ME: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q269585 However, I think that in this case it's the graphics driver that is failing, not the software GDI emulation, because the problem goes away if hardware acceleration is turned down. It might be useful to find out what the real cause of the crash is: is it actually in StretchBlt or is it caused by StretchBlt failing and the next operation trying to work on a 0x0 bitmap? Unfortunately, I don't have MSVC, so I can't figure it out. :-(
*** Bug 148910 has been marked as a duplicate of this bug. ***
Paper, do you think you write simple test app that opens a window, creates a 1x1 bitmap and stretches it to 2048x1? I would do it, but I don't have MSVC. Once we have the app, we could see that it crashes and burns on Win9x with nvidia cards but not with other cards and send nvidia the source and binary. If manage to show a driver developer that a few innocent lines of code blow up their drivers, but not other manufacturers', under Win9x, maybe they will fix it, or more likely give us a workaround.
Has anyone tried other builds to find out exactly when it started happening? Attachment 81771 [details] [diff] might be the cause of this... see bug 102321, comment #80.
No longer blocks: 146316
Lorenzo: I single step through the code, and it crashed when I try to execute the StretchBlt line. I don't have the opportunity to execute anything after that. The problem wasn't in 0.9.8, but is in 0.9.9, so it must have appeared somewhere between 02/04/02 and 03/11/02, right? Is there a way we can get really old nightly builds to narrow it down further? Also, it appears that IE had this problem, at least in version 4.72.3110: http://groups.google.com/groups?hl=en&lr=&threadm=ab4901c20a53%2465e428d0%2439ef2ecf%40TKMSFTNGXA08
Based on http://support.microsoft.com/default.aspx?scid=kb;EN-US;q269585 I would say that this is fundamentaly a Windows problem, that just happens to happen to nVidia cars, maybe due to the following quote from Q111865 "Most display drivers do not implement their own StretchBlt() or StretchDIBits() so GDI must simulate these calls.". And it does this in a 64kb area. Thus the solution for Mozilla, is to work on StretchBlt() so that a zero value is returned, or divided by. That being said, it looks like a problem that shows up the most with nVidia cards. I'm going to try working with GDI to see if there is a fix by MS for this.
David: What you're saying makes sense, but in Bug #131572, there's a person who experiences this crash under RedHat Linux.
That is a possible unrelated crash and/or his X-Server ha also a problem.
Well, my experiments with GDI have got me nowhere. However I did take a look at Bug #102321, and it may be possible that it created this problem. I'm going to repeat my earlier thought about checking for zero before doing a divide.
OK, I'm not much of a C programmer (read I'm really really bad), and C++ is a complete foreign language to me. However, looking at the fix for Bug #102321, and specifically nsImageWin.cpp along with http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bitmaps_9cok.asp I think that all calls to StretchBlt should be checking for zero return code as per this sentence on the MSDN page :- Return Values If the function succeeds, the return value is nonzero. If the function fails, the return value is zero. Mind you, I have no idea what to do when the return code *is* zero.
Bug #102321 was checked-in beyond 0.9.9. I don't think it's the cause. The latter patch in 102321 (checked-in on May 1) actually just reverses a patch in Bug 135226 (checked in on Apr 16). From the reports, I believe checking if StretchBlt returns anything will not help. It sounds like it crashes while executing that line, so we'd never get to the next line to check the result. Let's try to find someone with some nightlies between 0.9.8 and 0.9.9. I know there are some pack rats out there that keep binaries from every version. ;)
You're probably right. One question for the Windows Developers out there. Is StretchBlt in GDI.EXE or is it in GDI32.DLL? After playing around with GDI.EXE I think I've totally wasted my time as I should've been looking at GDI32.DLL. Also, tomorrow I'll test this on my machine at work which I don't think has any nVidia chips in it anywhere.
I looked through the CVS log for nsImageWin.cpp, which is here: http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/gfx/src/windows/nsImageWin.cpp It seems there are only 4 checkins between 0.9.8, which froze on 2002-01-16, and 0.9.9, which froze on 2002-02-20. The checkins are between versions 3.86 to 3.89. The ones between 3.86 and 3.88 fix background tiling to use PatBlt, but looking at the code it seems that the optimizations are turned off under Win98. The 3.88 -> 3.89 checkin looks more relevant. Does anyone have a nightly between 2002-02-27 and 2002-03-06? If these builds don't have the problem, the crash probably started happening in v3.89 (7 March).
My mistake, 0.9.9 does not contain version 3.89 because the 0.9.9 branch froze before that checkin. However, it differs from the 3.88 trunk version and contains a 3.88.2.1 (checkin by saari to the 0.9.9 branch only), which does things like ::SetStretchBltMode(TheHDC, HALFTONE); This might be the cause of the problem in 0.9.9.
I did a pull from Feb 28, compiled it and zipped it up to: http://animecity.nu/mozilla/Feb28.zip (8M) Simply unzip it in a new directory, and run. This is right after 0.9.9 was branched (but before another nsImageWin.cpp check-in was done). In theory it will crash. If it doesn't, then there's something in 0.9.9 branch that did it (and was added to the trunk later) Oh, the build ID will be 000000000000 because I compiled it.
I don't know if this effects this bug, but here's something I noticed: http://lxr.mozilla.org/seamonkey/source/gfx/src/windows/nsRenderingContextWin.cpp#452 452 if (palInfo.isPaletteDevice) 453 ::SetStretchBltMode(aNewDC, HALFTONE); 454 else 455 ::SetStretchBltMode(aNewDC, COLORONCOLOR); isPaletteDevice gets set by: mPaletteInfo.isPaletteDevice = RC_PALETTE == (rasterCaps & RC_PALETTE); Which is most likely true (nVidia probably a palette-based device). If indeed it is true, HALFTONE will be used. And from http://msdn.microsoft.com/library/en-us/gdi/bitmaps_6cth.asp : "This option [HALFTONE] is not supported on Windows 95/98/Me." Prior to Apr 16, this was used in nsRenderingContextWin.cpp#452 ::SetStretchBltMode(aNewDC, COLORONCOLOR);
Ok so replace the palinfo check with an OS check and you are done.
The Feb 28 build crashes on on the minimal testcase. So the problem might be in the PatBlt code checked in between Feb 18 and Feb 26 for bug 122996 and bug 127513, by dcone. Looking through the directory's CVS logs, the only other checkin that looks related is the bug 124686 checkin to nsRegionWin.cpp (but only vaguely). The PatBlt changes seem more likely, although supposedly they're turned off on Win9x. Regarding comment #97, I don't know what I was thinking. That change is not in 0.9.9 at all, it was checked in on April 3.
As I promised in Comment #87, I've just tested this on my work machine. It runs Win98SE, but has a Number Nine graphics card which uses a Savage4 graphics processor. It did not crash or anything. Now, this may be due to it not being a palette based device, as mentioned in Comment #99. I'll see if I can find anything that confirms that nVidia cards are palette based.
Well even if nVidia is not pallete based the bug is still a bug. If there is a palette based card on your system and you have win9x/me Halftone will be used and....crash.
On the other hand, this doesn't explain why it crashes with 2048xn-(whatever). If halftone is not supported shouldn't it just crash (or be problematic) in general? I mean whatever the height is...
There is no denying this is a bug, but where is the bug. Is it a Windows 98 bug that Mozilla will have to work around? Is it a nVidia bug that Mozilla will have to work around, or convince nVidia to fix the problem? Is it a Mozilla bug? Should the RELNOTE keyword be added. Hmmm, should the RELNOTE2 keyword also be added (for Netscape v7 PR2)?
taking
Assignee: kmcclusk → dcone
From some brief searching around the internet, it appears that nVidia is Palette based, which makes the HALFTONE option invalid. Although, as mentioned in comment #104, why doesn't it crash in all cases? Maybe the actual MS response is that HALFTONE is only partially working, so they decided to say it doesn't work.
Pulled Feb 15, compiled, zipped dist/bin to: http://animecity.nu/mozilla/Feb15.zip Don't forget to exit Mozilla before running this one (or the other one), otherwise it'll just open a new window with your current build.
Feb 15 build crashes on the minimal testcase.
Feb 1 build crashes with the minimal testcase too.
Lorenzo has also tested 0.9.8 compile from me (to make sure it wasn't my compile options causing the crash), and a Jan 17th compile (right after the 0.9.8 freeze). Both worked (no crash) So it's somewhere between Jan 17th and Feb 1. Could someone try these (in the following order): http://animecity.nu/mozilla/Jan24.zip If it crashes, try: http://animecity.nu/mozilla/Jan21.zip (will be up in about 2 hours) If Jan24 didn't crash, try: http://animecity.nu/mozilla/Jan28.zip This will give us a 3 - 4 day span. Hopefully that will be enough to determine via Bonsai where the problem code is.
Jan 24 & 28 builds didn't crash.
http://animecity.nu/mozilla/StretchBltTest.zip (19k) Contains StretchBltTest.exe which tries to stretch a 640x1 image to 640x2048 (source also included) This better crash :)
I had a quick look at Bonsai and nothing jumped out at me. So I started guessing and thought maybe v3.10 of mozilla/gfx/src/windows/nsDrawingSurfaceWin.cpp where nsCRT::zero was replaced by memset is the problem. From my ultra limited c knowledge, I would think that memset should be a memcpy. Oh well, hopefully someone else has more luck.
Arron: Your StretchBltTest does crash with the same divide error that Mozilla does.
Good. Thanks Joshua. Could you try one last one? http://animecity.nu/mozilla/StetchBltTest2.exe I've added a check to see if the video card supports stretchblt (according to GetDeviceCaps). If it doesn't, you will be notified. If you get to the messagebox that says "Ready to stretch.." then just click cancel because it will crash.
Both stretchbit tests crash for me. Btw nvidia released some new drivers today but the crash still occurs.
Arron, are you working on a possible patch, or should I continue looking at Bonsai?
I believe the bug was introduced on Jan 30 by this: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&date=explicit&mindate=01%2F30%2F2002+14%3A17&maxdate=01%2F30%2F2002+14%3A17 Specifically, the code in gfxImageFrame::SetMutable that calls mImage->Optimize(nsnull); Once mImage is set to optimized, the next nsImageWin::Draw will call StretchBlt instead of StretchDIBits. Before Jan 30, the image was not being optimized, so only StretchDIBits was being called. I am currently writing up an e-mail to nVidia. The only e-mail address that I could find that looked promising is DeveloperRelations@nvidia.com. If anyone can find a better e-mail address to send it to, please tell me. Let's hope they take the problem seriously.
Didn't we conclude that it is a Windows problem and the only problem with nVidia cards are that they are palette based? I will say once again : can't you just change the Palette check with an OS check (win9x won't use HALFTONE and others will)...?
Nick: no, this appears to be a bug in the nvidia drivers, in the implementation of the StretchBlt() function to be precise. It used to work because the old (and less efficient) code in 0.9.8 doesn't call StretchBlt() but StretchDiBits().
Well, there are two problems here. nVidia's drivers are broken and need to be fixed. (ARRON: That eMail address is the best I could find as well). Mozilla doesn't catch the unsuported function in windows (which is normally handled by the video card). From the code Arron found, and using pseudo code (in caps) to explain what needs to happen (remember my c skills are really bad). if (!aMutable) AND NOT WINDOWS98 mImage->Optimize(nsnull); Who out there wants to turn this into C++?
However, until nVidia fix their driver, Mozilla is going to have to work around it. And even then, when nVidia do fix the driver, this will need to be release noted to get people to upgrade their nVidia drivers.
Only nVidia has this problem. Turning it off for all Win98 people would mean everyone else on Win98 would become slower. The Opera thread suggested turning down the video acceleration to mode 2. Has anyone tried this with Mozilla? I think the best thing to do is to write a relnote. But I don't have the last word on it.
I just tried the hint from Opera to turn acceleration down to two. It still crashed exactly as before with build 2002061104. Also, does MSVC have function calls to determine OS and what video card is being used?
Does anyone know what performance penalty of going back to using StretchDIBits() instead of StretchBlt() is? Paper?
Reducing Hardware acceleration makes the problem go away for me. Wait I think I misunderstood something. the code is : 452 if (palInfo.isPaletteDevice) 453 ::SetStretchBltMode(aNewDC, HALFTONE); 454 else 455 ::SetStretchBltMode(aNewDC, COLORONCOLOR); So if the machine has a palette based device (like an nVidia card) Halftone will be used. And Halftone is not supported in windows 9x. So hypothetically someone else with a non-nvidia but palette based card would crash too right? Because Halftone should be used with win 9x. So regardless if nVidia is more problematic than others an OS check is required there. Am I wrong?
Then again if I am right reducing hardware acceleration should have no effect on wether it crashes or not.
*** Bug 147551 has been marked as a duplicate of this bug. ***
Seen this crash on 95OSR2/98(4.10.0)/98SE(4.10.222.2). WinME is fine.
Nick, the HALFTONE thing is a red herring. Even if the video card doesn't support that mode, it shouldn't crash, it should just ignore it. This is what every video card seems to do, including nVidia. The crash is not caused by HALFTONE. -- Are we just looking for a temporary fix until nVidia fixes their drivers (or until Win98 is extinct)? I can probably get rid of 70%+ of the crashes by implementing a "1 height patch". This will stop the crashes for all images with 1 height (or 1 width) that are stretched beyond 2047x. Crashing would still occur on 2 height images (when stretched to 4095 or more), however, the chances of a website using a 2 height spacer as opposed to a 1 height spacer is almost nill. I have the "1 height patch" working on my own build. Thoughts?
A temporary fix would be nice - we all know how slow & ignorant nVidia can be. :\
... and while reducing the hardware acceleration seems to make this bug to go away, one can't expect the user to do that. Even my little XP1700+ is soooo slow that way :-/
Arron, while I really don't like temp fixes, they are better than nothing, and are better than waiting on nVidia to "maybe" fix the problem. It also avoids a release note which can cause bad press. And, if HALFTONE isn't what's causing the problem, what is the problem? And finally, may I suggest you add your patch to this bug so that we can start heading towards a fix (temporary or otherwise).
Paper, what does your "1 height patch" do? Does it check if an image has a width or height of 1 and if so unoptimize it (turn it back into a DIB) and stretch it via StretchDIBits?
Re Comment #128 See http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnargdi/html/msdn_primitiv.asp Although I add this small quote from that MS article is referance to StretchDIBits:- "The total memory usage in this operation is significant."
Now I'm really annoyed. Just got this error at http://www.microsoft.com/windows98/downloads/corporate.asp I'm looking for a newer version of GDI32.DLL in hopes that will help with this problem. The newest version comes with Windows CE (according to TechNet) for those who are interested. If anyone who is running Win CE or Win2K who can send me their GDI32.DLL I would be very happy. You should find it in /windows/system.
Attached patch 1 pixel stretch patch (obsolete) — — Splinter Review
Speed up 1px stretches by only stretching image for the height or width of the dirtied area.
David, the problem is mentioned in Comment 120 and Comment 122. Also, I wouldn't recommend copying a GDI32.dll from another OS version.. I'm pretty sure the GDI32.dll is build differently for each platform. And yes, just about any page (especially Microsoft ones, but they are biased) talking about DDB and DIB will say that DDB is faster. How much faster depends on your video card. DDB allows the video card to do whatever it wants to the image, like put it in it's own video memory (which is far far faster than conventional memory). Whether the card puts the image into it's own video memory is up to the card & the driver. Cheap video cards don't do anything, and sometimes end up being slower on DDB. I'm not sure how DDBs effect the memory footprint of Mozilla. It could be that once the image has been "DDB'd" and moved to the video card, it no longer registers in Task Manager. I have no idea. Lor, the patch does not turn off optimization. I'm trying to find solutions that prevent us from having doing that.
In case anyone wants to test this patch and do not have a compiler: http://animecity.nu/Mozilla/gklayout-1px.zip gklayout.dll with patch for Mozilla 1.0 Final ONLY. --- I ran a test on gfxImageFrame with the optimization call, and without it on my Win98 machine (sorry, no nVidia.. it has a Matrox G200 card). The test with the optimization on (DDB) went 2x faster then with the optimization off (DIB). I don't believe it's acceptable to force all Win98 users to use DIB just because of nVidia. I'll give the test stuff to Lor once we speak again, and we'll find out the results on a nVidia card.
Paper, you rule!!! Your dll fixes all the cases I was crashing on. Kudos to you!
You were serious about that Mozilla 1.0 spec. I just tried it on todays trunk build and Mozilla crashed on startup.
With Paper's test methodology, optimization is almost 2x faster on my nvidia (Geforce2 MX), too: 15% CPU usage vs. 27% without optimization.
*** Bug 134170 has been marked as a duplicate of this bug. ***
Keywords: patch, review
Summary: Image stretched to >= 2048 pixels crashes Win9x with nvidia cards → Image stretched about 2048x crashes Win9x with nvidia cards
*** Bug 151944 has been marked as a duplicate of this bug. ***
Arron, thanks for the patch. :) Have you contacted nVidia already? Any reaction from them?
Excellent job, my test case works fine as well. I think this bug should now be marked as Resolved (or is it Fixed) either way it works properly now.
no, its not fixed for builds from the branch/trunk since the patch isn't checked into the tree...
This bug is annoying, it hits me quite often, doesn't speak for the webmasters of the pages (one shouldn't use pixel spacers! There's CSS), but it's not really a Mozilla bug, even though it were nice to check this patch into the tree, so it's in the next nightly build (would really appreciate it). I can't understand why there's no address on the NVidia webpage to report bugs, I really looked everywhere, but I couldn't find any helpful address (there are some addresses in the developer section, but they are rather for developer questions and so on and not for contacting the driver programmer). Even though not directly related to the bug, I get strange crashes when running Java applications as well and after the Java application has been terminated, there's a logilfe in the directory, created by the JVM, saying that an unexpected exception took place in native code and location it provides is always C:\WINDOWS\SYSTEM\IMAGEHLP.DLL so can someone here tell me if this might be related to the same problem and when this DLL tries to stretch an image, the JVM craches? I can't test it, as I can't provoke such a crash - they seem to happen randomly, but I never had any of these before I installed the latest NVidia drivers... unfortunately I updated the JVM at the same time (from Java1.4.0 to Java1.4.0_1) and thus I can't say which one is the cause and just asked before I will bother Sun with a bug report. I just wanted to mention that even though the current patch will circumvent the problem for HTML rendering, a Java applet may still crash Mozilla by scalling a single pixel that way as Sun's Java 1.4 also uses DDB in many cases. So it's unavoidable that NVidia fixes that bug.
Alias: nvidea
*** Bug 152735 has been marked as a duplicate of this bug. ***
Just encountered this bug (was #152735) - ouch. One possible contact address for NVidia is: DeveloperRelations@nvidia.com
*** Bug 152735 has been marked as a duplicate of this bug. ***
A reply from nVidia! I removed the e-mail address for spam reasons. I still think the patch should be put into the trunk.. if not for the temporary nVidia fix, but also for the speed improvement on scrolling of long pages. Subj: RE: StretchBlt on Windows 98 w/Detonator XP Driver Date: Mon, 24 Jun 2002 12:54:47 -0700 From: Matthias Wloka <@nvidia.com> ---------------------------------------------------------------- Yes, your email has reached the right place. I apologize for the inconvenience this issue has caused, but thanks to your repro exe, we have been able to reproduce the problem. A future version of our drivers will fix this issue. Thanks again for alerting us to this problem! Matthias
Yes, the patch should go into the Trunk. Otherwise a release note will need to be done for all future Mozilla (and Netscape, and possibly AOL) releases for those that use nVidia based videocards to tell them they may get random "divide by zero" errors. And, there is currently no fix from nVidia for this problem.
Comment on attachment 87375 [details] [diff] [review] 1 pixel stretch patch >+ } else { >+ float t2p; >+ aPresContext->GetTwipsToPixels(&t2p); >+ // Stretching a 1 px high image is only expanding the one line, >+ // so we don't need to update the whole mComputedSize.height >+ if (NSToCoordRound(r.height * t2p) == 1) { >+ nsRect validArea; >+ validArea.IntersectRect(inner, aDirtyRect); >+ d.y = validArea.y; >+ d.height = validArea.height; >+ } >+ if (NSToCoordRound(r.width * t2p) == 1) { >+ nsRect validArea; >+ validArea.IntersectRect(inner, aDirtyRect); >+ d.x = validArea.x; >+ d.width = validArea.width; >+ } Any reason this code has to be in the |else|. And shouldn't you be operating on |d| instead of |inner|? (Would that allow it to work?) Pavlov should probably review this, though...
Attached patch 1 pixel stretch patch — — Splinter Review
w/dbaron's changes David: Yes, |d| is probably a wiser choice than |inner| (most of the time they are the same which is why I didn't notice) The only reason I had the code in wrapped in the else is because the corresponding if statement (seems to only) runs on print preview. Print Preview is so screwed for (stretched) images over multiple pages, and I didn't want to have anything to do with the mess. :P The code out of the else, since it appears it doesn't effect print preview any worse than it's affected now.
Attachment #87375 - Attachment is obsolete: true
Great news Paper! If nvidia fixes the problem we can relnote it and leave the code as it is. Something like "If you are using an nvidia card under Windows 9x/ME, Mozilla may crash when viewing some pages. To fix the problem, upgrade your nvidia drivers to version X or later" Regarding the patch, I have my doubts. Is it a good idea to add special-case code only for 1-pixel images? Yes, there is a performance improvement, but only for 1-pixel images. Does this justify modifying the source? For example, would you patch the source to special-case 2-pixel images? Or square images? I think the best thing would be to try to check this in to the branch only, so it can be a temporary fix for the stable 1.0.x releases until nvidia fixes the drivers. As far as I can see, it works: I have been running your 1.0 DLL all the time for almost two weeks now and Mozilla works fine and Doesn't Crash (TM). People, what do you think?
Alias: nvidea → nvidia
Yes, this should be in the Trunk. I'm also thinking it should be in the branch as well as that is the "public" version of Mozilla (if there is such a thing as a public version). However, I think it should be put in the Trunk, see what happens, and then consider the Branch (or see if nVidia have new drivers yet).
I'm all for including the fix/workaround in the trunk - regardless of who is to blame for this particular problem, crashing because the divisor isn't supposed to be zero is not a graceful way to handle the error! Mozilla probably isn't to blame for this, but the fact that Mozilla uncovered the bug does make it look bad, and that isn't fair. As long as the code doesn't break anything else, put it in the trunk - everyone is happy, and Mozilla looks good.
As Paul said "Mozilla looks good", which is important as then Netscape will look good. This patch should be included in the 1.1beta, and hopefully in 1.02 (if it happens). What I'm not sure about is this. When (or if) nVidia fix their problem, should this patch be removed? I'm on the fence on this one, so would appreciate any comments (either posted to this bug, or eMailed direct to me).
> When (or if) nVidia fix their problem, should this patch be removed? no. you can't expect that the mass of the people upgrade to a new driver of their gfx-card, just because there is a new one. So even monthes after the release of a fixed driver Mozilla would still crash for probably more then 90% of the nVidia users, and there are A LOT of nVidia users. writing a small comment into the release notes wouldn't help, since no one is reading them anyway and even if someone does, he probably wouldn't assign a pseudo random crash with the crash mentioned in the release note. Maybe there should be a comment in the patch mentioning that there might be a crash with nVidia gfx cards and a link to this bug.
Well, that convinced me rather easily. Mainly because of your comment "Maybe there should be a comment in the patch mentioning that there might be a crash with nVidia gfx cards and a link to this bug." If this comment appears in the patch, then everyone should be happy. So, when's this going to land?
Excuse me, but this is *an nvidia bug*. You do realise this, right?
Yes, this is a problem with the nVidia drivers. However, when Joe Public uses Netscape v7 and gets a "divide by zero" error, guess who they are going to blame. And anyway, it is bad programming to allow a divide by zero condition to happen in the first place (with apologies to all Mozilla code writers). So, while nVidia has to fix the problem, Mozilla should never, ever attempt to divide by zero. So, it's a Mozilla problem as well.
No, it is 100% nVidia's problem code-wise. The computer crashes while executing code in nVidia's driver. This is demonstrated by the C++ project that Arron made. Mozilla performs no division operation that crashes the computer (at least not in this bug). Also, the error that occurs isn't a "divide by zero" error, it is simply a "divide error." I don't know if this is still the case in Windows, but in the old days a "divide error" meant that the result of the division operation was too big to fit in the accumulator. Not that it really matters, since it isn't Mozilla's problem, but I just thought I'd clarify.
OK, I went back and re-read everything, and I was still thinking of the HALFTONE problem. My mistake. Apologies all round.
*** Bug 155632 has been marked as a duplicate of this bug. ***
Since this is a fix for a windows problem, could this be moved into gfx/windows by having DrawImage call GetDimensions on the target surface and clip against that?
hmm, I had thought this patch would be a perf gain, but I spent the day testing it and saw no performance gains. Apparently Windows is smart enough to say "gee, Mozilla is trying to stretch a 1x1 image to 30000x30000 and draw it all, but the window size is only 900x500, so I'm only going to think about 900x500". I don't know if other platforms also have these smarts. At any rate, my ambition to get this patch in is now diminished. tor, I'll look into moving it to gfx/windows. It's on my low priority list, however. Maybe when 1.1final gets closer, and if nVidia hasn't come out with a new driver by then, I'll make this bug more of a priority. and yes lor, I'll make a .dll for 1.0.1 when it comes out. :) Maybe even a 1.1b .dll. Of course, anyone else is welcome to move the patch over to gfx/windows. :)
*** Bug 156622 has been marked as a duplicate of this bug. ***
Priority: -- → P2
*** Bug 157213 has been marked as a duplicate of this bug. ***
For those that are interested, I provide the following :- The latest official driver from nVidia for Win98 is 29.42. Using an alpha/beta copy of version 29.80 and 30.30 of the drivers, I see the same problem, so nVidia haven't fixed the problem yet. For those who aren't interested, I apologise for the spam.
URL WFM 2002071904/win98se/nvidia GeForce2Ti/Detonator 22.50
*** Bug 158485 has been marked as a duplicate of this bug. ***
*** Bug 160861 has been marked as a duplicate of this bug. ***
I'm experiencing the same problem with a Nvidia TNT2 64M card, driver update 29.42.
OK, I've been trying very hard to get this crash as I've done some upgrades and wanted to see if I still had the problem. And, I can't get it to crash. So, what have I updated? Well, I'm now on DirectX 8.1b, and I've also upgraded by nVidia drivers to 30.82 (not supported by nVidia as they're alpha/beta versions), and I'm now on Mozilla build 2002080204-TRUNK. Any one of those three could have fixed it (or I'm just not trying hard enough to crash my PC), is there anyone else out there running DirectX 8.1b and/or the same Mozilla build and still having the problem?
I am running DirectX 8.1b and can still reproduce the crash, but I never expected anything else, because it is a bug in the NVidia drivers and thus a new DirectX version won't fix it, it's not the task of Micro$oft to write work-arounds for buggy NVidia drivers into their code. David, if you want to verify if it's the latest Mozilla build that doesn't cause the problem any longer or your new driver, download and run the test EXE file: http://animecity.nu/mozilla/StetchBltTest2.exe If it says "Ready to stretch...", hit Okay. If this causes a crash, the bug has not been fixed in the drivers and Mozilla just doesn't use the stretch method any longer. If it doesn't crash, NVidia finally found a way to avoid the bug. Where can one download the beta drivers of NVidia for testing purposes?
OK, it looks like nVidia have fixed the problem. Using StetchBltTest2.exe I didn't crash and got the Success message. Now, if you want to download these drivers, I must first say that they aren't supported by nVidia (or anyone else who OEM's their cards). Also, I would treat them as Alpha drivers at best, so don't blame me if your system stops working after installing these. So, having said that, go to http://www.guru3d.com/files/detonator/ and follow the links to version 30.82 of the driver.
The new detonator drivers fix the problem indeed.
I've added some comments to the Whiteboard. I would recommend, IMHO, that this bug stay open until nVidia make an official release of these drivers and a retest has been done.
Whiteboard: Alpha nVidia drivers fix problem (waiting for official release).
*** Bug 161095 has been marked as a duplicate of this bug. ***
Version 30.82 has been officially released. See below link. http://www.nvidia.com/view.asp?PAGE=windows9x
The bug seems to be fixed in the new drivers. I just installed them and the pages which previously crashed Mozilla are now working fine.
Great. All we need is a release note. I'm not sure what the process is, but it would be nice to get the note added to the existing 1.0 release notes as well as the upcoming 1.1 and Netscape 7 notes.
Keywords: patch, review, stackwanted → relnote
Whiteboard: Alpha nVidia drivers fix problem (waiting for official release).
Well, who is it that writes the release notes? From digging around the v1.0 release notes, I see that asa, timeless & endico were the main contributors. I'm going to eMail them (outside of this bug) to see if they can help with the release note. Also, added RELNOTE2 keyword for Netscape v7 PR2 (if it ever happens).
Keywords: relnote2
FYI, Bug #155243 is a tracking bug for release notes on v1.0.1 of Mozilla. Bug #155244 is a tracking bug for release notes on v1.1 of Mozilla. The info about the nVidia driver upgrade has been added to both bugs. Thus, will be in the release notes when those versions come out. Thanks to timeless for this info, and for being patient with newbies like myself. Hmmm, does that mean that this bug is now Fixed?
*** Bug 162299 has been marked as a duplicate of this bug. ***
Latest Nvidia Detonator driver, v30.82, resolves this problem on my TNT2.
Well, with the release notes, for 1.0.1 and 1.1, to include pointers to the fix from nVidia, I'm marking this bug Fixed.
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
Adding solution to Status Whitebord so that it will be easier for people who happen upon this bug to find out what to do. :)
Whiteboard: Update your nVidia drivers to v30.82+
This is not fixed in mozilla.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
-> invalid (nvidia driver bug)
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → INVALID
My apologies, I was using a big picture scenario, where the problem has been fixed. Reading the Mozilla definitions, I realise that you are correct, this bug is Invalid. Fixed would indicate that a patch has been checked into the tree, and the patch never got checked in, as far as i can tell.
> This is not fixed in mozilla. That is right, it is not fixed in Mozilla, because it never was broken in Mozilla. Mozilla did it right and the NVidia driver did it wrong (as NVidia admitted and that's also why they fixed it). It's not that NVidia is working around a Mozilla bug here, we were actually trying to work around an NVidia bug, but should Mozilla really start doing that? Then were does it end? There are maybe 100 different graphis drivers people use today, do we have to find all of their bugs and work around them? Or should we do it how we want it to be done and rely that drivers do it correctly? But maybe should file a feature request, as some source code posted in this bug shows that through some tricks one can load pages using pixel spacers (those are usually one pixel in width or height) faster and that is maybe desirable. Pixel spacers are bad, CSS spacing makes them obsolete, but they are still used and it's not illegal cheating to treat certain cases specially. A lot of programs have a piece of code that is designed to handle all possible cases, however, for some cases that appear very often or that are handled very slowly by the code, often an own piece of code is added that is only used in these special cases, because it makes slow or often uses cases faster, uses less memory or just handles them otherwise better.
i changed only the bug solution. This is no mozilla bug, it's an nvidia bug and this bug is invalid. Paper can file a new bug about a performance improvement. (I dunno if his code improces the performance on all win32 OS.)
*** Bug 162126 has been marked as a duplicate of this bug. ***
It's still a problem for me, I just crashed with a divide error on 1.1. My video card is Elsa Erazor X 32mb, using nvidia Gforce256 chipset. The company has ceased to exist, no driver updates possible. Even their website is gone... Is there any workaround?
Hi irve@hot.ee, The newest Elsa drivers are on this page:http://www.elsa.com.tw/e/driver/index.htm This version haven't the latest NVidia Driver 30.82 (You can see the used NVidia Detonator Driver on the last part of the Elsa driver Number! p.e Elsa v4.1381.2942 have the 29.42 NVidia Detonator). But you can also load the latest Detonator Driver from NVidia. Mostly there are no problems with them. The NVidia Drivers are referenz drivers for all NVidia Cards an can be modified by NVidia vendors (as Elsa is).
True, just use the drivers from nVidia. My card is a PNY card officially, but the drivers from nVidia haven't been any problem.
*** Bug 166334 has been marked as a duplicate of this bug. ***
*** Bug 153160 has been marked as a duplicate of this bug. ***
*** Bug 160930 has been marked as a duplicate of this bug. ***
*** Bug 164324 has been marked as a duplicate of this bug. ***
*** Bug 172187 has been marked as a duplicate of this bug. ***
*** Bug 172522 has been marked as a duplicate of this bug. ***
(from the creator of bug report 172522...) Is this not still a TalkBack error? Should not the bug reporting tool catch failures and report them? Further, is it correct to categorize the problem as entirely an nVidia driver problem? The defunct Mozilla process was not successfully terminated, removed from memory, or removed from the process tables. Further, the lingering browser zombie successfully prevents user logouts and (in 50% of my replications) successful shutdown of the machine. (Hangs at "Windows is shutting down" placard.) My point is that the browser didn't fail in a graceful manner. It blew up, splattered chunks everywhere, and interfered with simple user procedures to rectify the problem. (and now I head out to nVidia's site to get new drivers and shake my fist at their old drivers...)
fuzzyeric: it's a *driver bug*, not a mozilla bug. mozilla calls a legitimate function, with legitimate parameters. The driver fails to handle it and causes a divide error, at which point the OS terminates mozilla but doesn't do it properly because the error occurs in the driver and not in the mozilla. So it's the driver and the OS's fault, not mozilla's. As regards talkback, I don't know how it works, but probably a crash in the graphics driver can't be caught by the means talkback uses (and it wouldn't make much sense either, as talkback is designed to spot errors in the program and not in the graphics driver).
Well, I agree that this bug has nothing at all to do with Mozilla. The old nVidia drivers are buggy. In fact, if you look closely at nVidia.com, you will see that all drivers are supplied as Beta drivers. However, I think the main culprit is Windows, in that it can't gracefully handle a "divide by zero" error in a third party component. In any event, nVidia has fixed the problem. It's just a pity that the Mozilla release notes don't say anything about this problem (refer Relnote keywords).
*** Bug 170744 has been marked as a duplicate of this bug. ***
*** Bug 177445 has been marked as a duplicate of this bug. ***
*** Bug 164991 has been marked as a duplicate of this bug. ***
*** Bug 181624 has been marked as a duplicate of this bug. ***
*** Bug 188456 has been marked as a duplicate of this bug. ***
*** Bug 195125 has been marked as a duplicate of this bug. ***
*** Bug 196583 has been marked as a duplicate of this bug. ***
verified
Status: RESOLVED → VERIFIED
*** Bug 206991 has been marked as a duplicate of this bug. ***
*** Bug 206959 has been marked as a duplicate of this bug. ***
*** Bug 208009 has been marked as a duplicate of this bug. ***
*** Bug 210100 has been marked as a duplicate of this bug. ***
Crashes (Win98SE, NVIDIA GeForce4 MX 440) on 1x1 pixel GIF image in offline or online modes. The URL which reproduces the crash: http://news.google.com/en/us/entertainment.html (the downloaded page causes crash in offline mode). The crash doesn't occur if the file "/images/cleardot.gif" from this page is removed (in offline mode) or if loading of images is disabled. ---------------------------- The windows reports crash as: MOZILLA caused a divide error in module <unknown> at 00de:00000204. Registers: EAX=89800000 CS=003b EIP=00000204 EFLGS=00000097 EBX=00010001 SS=28ef ESP=00000fd0 EBP=0000a698 ECX=00000001 DS=202f ESI=d7e7d000 FS=12df EDX=00000000 ES=50b7 EDI=d810c0c0 GS=366f Bytes at CS:EIP: cd 30 cd 30 cd 30 cd 30 cd 30 cd 30 cd 30 cd 30 Stack dump: 003b0204 3f000006 0246033f 366fa698 7f680000 00008098 12c00000 7f001787 021f8098 021701b7 00280037 003b0204 00000000 00000000 00000000 00000000
I get a 404 (Page not found) error on that URL.
*** Bug 214511 has been marked as a duplicate of this bug. ***
*** Bug 210371 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
Blocks: 741105
No longer blocks: 741105
Alias: nvidia
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: