User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b11pre) Gecko/20110131 Firefox/4.0b11pre Firefox/4.0b11pre Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b11pre) Gecko/20110131 Firefox/4.0b11pre Firefox/4.0b11pre In the build of 2011/01/31, about:config crashes. Crash report indicates this is a problem in SetPixelFormat in a call to OPENGL32.DLL (See : https://crash-stats.mozilla.com/report/index/bp-a780f9d8-f128-4286-bce4-fb6e32110131) I have a NVIDIA Quadro NVS140 with the latest drivers, opengl32.dll is version 5.1.2600.5512 (Microsoft), nvoglnt.dll is version 22.214.171.12458 (NVIDIA OpenGL ICD). Reproducible: Always Steps to Reproduce: 1. Open about:support 2. Crash
Summary: Crash in [@ OPENGL32.dll@0x3726 ] when opening about:config → Crash in [@ OPENGL32.dll@0x3726 ] when opening about:support
Tom: Is is about:config or about:support that crashes? In the STR and bug summary you mention about:support but in the description about you reference about:config. Thanks.
The description is an error, it should be about:support.
Severity: major → critical
Component: General → Graphics
Product: Firefox → Core
QA Contact: general → thebes
Version: unspecified → Trunk
about:support creates a webgl context in order to get information about webgl; but why this should crash, I don't know :(
Tom: The crash report in Comment 0 shows quite a few extensions - does the same thing happen in safe mode?
Yes, I also tried in safe-mode, but then the crash also occurs. In the crash-report, the last call is SetPixelFormat. I looked around and found some references that SetPixelFormat can cause an exception. I tried running GLView (http://www.realtech-vr.com/glview/) on this system an it worked fine, so OpenGL can run fine on this machine (so no problem with drivers).
Hmm.. We don't check the return value from one ChoosePixelFormat, when creating gSharedWindowPixelFormat. So we might be passing a 0 to SetPixelFormat there and that might be breaking things. Any reason why we don't have line numbers for that crash? That would help confirm that it's the one particular SetPixelFormat.
Created attachment 508888 [details] [diff] [review] check return value Something like this might help...
Attachment #508888 - Flags: review?(jmuizelaar)
Comment on attachment 508888 [details] [diff] [review] check return value Why not.
Attachment #508888 - Flags: review?(jmuizelaar) → review+
Landed as http://hg.mozilla.org/mozilla-central/rev/5c92181d4b31 -- Tom, can you check tomorrow's nightly and see if this still crashes for you?
(In reply to comment #9) > Landed as http://hg.mozilla.org/mozilla-central/rev/5c92181d4b31 -- Tom, can > you check tomorrow's nightly and see if this still crashes for you? Sure, I will check again as soon as the new nightly is available.
Ok, I can confirm that the patch is working, no crash anymore. Are you sure this exception cannot occurr in other places where SetPixelFormat is used?
Great! Yep, the other call to SetPixelFormat actually uses this same pixel format ID -- and it's conditional on the Initialization function succeeding. I am however surprised that we're not getting any pixel formats; I'm going to mark this fixed for tracking purposes, but can you attach a GL Extension Viewer report to this bug for your card? You can use the "Save as XML" thing under the databases icon in the extension viewer UI. Thanks!
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Created attachment 509364 [details] Dump from OpenGL Extensions Viewer Ok, here is the report from the OpenGL Extensions Viewer.
Thanks; very strange -- there are lots and lots of pixel formats there that would work just fine. Your laptop doesn't do Optimus or anything like that, does it?
No, it is an old Dell D830 laptop.
You need to log in before you can comment on or make changes to this bug.