626192 - firefox crashes when attempting this URL (XF86DRIQueryVersion) [@ libGL.so.1.2@0x6d5a0 ][@ libGL.so.1.2@0x73f58 ][@ libGL.so.1.2@0x7714c ][@ libGL.so.1.2@0x5b38e ]

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Steve Roylance]

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0b9) Gecko/20100101 Firefox/4.0b9
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b9) Gecko/20100101 Firefox/4.0b9

try to navigate to http://abc.net.au/tv/ and http://abc.net.au/tv/guide/ and firefox closes unexpectedly.

firefox/3.6.13 , works

Reproducible: Always

Steps to Reproduce:
1. navigate to http://abc.net.au/tv/
2. firefox closes unexpectedly

Actual Results:  
firefox closes unexpectedly

Expected Results:  
web page should open

firefox/3.6.13  works

Comment 1

[Matthias Versen [:Matti]]

Please post a crash ID https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report

Comment 2

[Mats Palmgren (inactive)]

STR is 100% reproducible for me with a 2011-01-14 nightly on Ubuntu 10.10
bp-635d7364-fce1-486c-965e-5890f2110116
bp-19255e3e-3582-4c2c-ba43-bac862110116

Comment 3

[Steve Roylance]

checked webpage with Mozilla/5.0 (Windows NT 6.0; rv:2.0b9) Gecko/20100101 Firefox/4.0b9 on MS-Vista instance on VirtualBox(4.0) and page loads.

Comment 4

[Mats Palmgren (inactive)]

Attachment: crash stack with libGL.so symbols (local x86-64 DEBUG build)

Comment 5

[Mats Palmgren (inactive)]

#0  XF86DRIQueryVersion () from /usr/lib/fglrx/libGL.so.1
#1  XF86DRIQueryExtension () from /usr/lib/fglrx/libGL.so.1
#2  ?? () from /usr/lib/fglrx/libGL.so.1
#3  ?? () from /usr/lib/fglrx/libGL.so.1
#4  glXQueryVersion () from /usr/lib/fglrx/libGL.so.1
#5  mozilla::gl::GLXLibrary::EnsureInitialized (this=0x7fffe9714f30) at gfx/thebes/GLContextProviderGLX.cpp:167
#6  mozilla::gl::CreateOffscreenPixmapContext (aSize=, aFormat=..., aShare=-265895936) at gfx/thebes/GLContextProviderGLX.cpp:552
#7  mozilla::gl::GLContextProviderGLX::CreateOffscreen (aSize=..., aFormat=...) at gfx/thebes/GLContextProviderGLX.cpp:672
#8  mozilla::WebGLContext::SetDimensions (this=0x7fffd22c1c00, width=300, height=150) at content/canvas/src/WebGLContext.cpp:480
#9  nsHTMLCanvasElement::UpdateContext (this=0x7fffd24a0f20, aNewContextOptions=0x0) at content/html/content/src/nsHTMLCanvasElement.cpp:611
#10 nsHTMLCanvasElement::GetContext (this=0x7fffd24a0f20, aContextId=, aContextOptions=..., aContext=) at content/html/content/src/nsHTMLCanvasElement.cpp:534
#11 nsIDOMHTMLCanvasElement_GetContext (cx=0x7fffe0a6c000, argc=, vp=0x7fffe53fe270) at dom_quickstubs.cpp:20390
#12 CallJSNative (this=0x7fffffffcf80) at js/src/jscntxtinlines.h:692
...

Comment 6

[Mats Palmgren (inactive)]

-> Core/Graphics for further triage.

Comment 7

[Mats Palmgren (inactive)]

Possibly the same as 
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/647731

Comment 8

[Mats Palmgren (inactive)]

Attachment: assembler + registers

Comment 9

[Mats Palmgren (inactive)]

Also crashes at http://www.w3.org/html/logo/
bp-2171f761-13f8-449a-b192-280cd2110118

Comment 10

[Steve Roylance]

still crashes at http://abc.net.au/tv/
Mozilla/5.0 (X11; Linux i686; rv:2.0b10) Gecko/20100101 Firefox/4.0b10
built from source this morning

Comment 11

[Steve Roylance]

http://abc.net.au/tv/ - loads properly
Mozilla/5.0 (X11; Linux i686; rv:2.0b11) Gecko/20110210 Firefox/4.0b11

Comment 12

[Mats Palmgren (inactive)]

I still crash in 20110210 4.0b12pre:
bp-cee151a6-abc7-418d-ba00-a7de32110210

Comment 13

[Steve Roylance]

system for comment 11 is Fedora 14
$ uname -r
2.6.35.11-83.fc14.i686.PAE
nvidia-xconfig:  version 260.19.36

Comment 15

[Robert Haas [:scenor]]

Same problem here on Ubuntu 10.10 Self-built, among others on sf.net
bp-b28b7939-f8b9-4197-b6e9-c63ae2110215
However, all crashreports here are on x86_64, is someone experiencing it on other platforms?

Comment 16

[Steve Roylance]

I am using 32bit see comment 13 referring to comment 11, system crashed with b09 and b10, but worked with b11

Comment 17

[Michael testing]

Crash probably relates to the use of the ATI graphics driver fglrx with nVidia graphics card.
See here:
https://wiki.ubuntu.com/X/Troubleshooting/NvidiaDriverSwitching
for how to switch drivers

Switching drivers resolved the issue for me

Comment 18

[Karl Tomlinson (:karlt)]

Can those who can reproduce please attach their output from glxinfo?

Comment 19

[Mats Palmgren (inactive)]

Not much to show:
# glxinfo
name of display: :0.0
Segmentation fault

# lspci
05:00.0 VGA compatible controller: ATI Technologies Inc RV630 [Radeon HD 2600XT]
... no other video devices listed ...

# ldd /usr/bin/glxinfo |grep libGL
        libGLEW.so.1.5 => /usr/lib/libGLEW.so.1.5 (0x00007fb2bf26d000)
        libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00007fb2beffb000)
        libGL.so.1 => /usr/lib/fglrx/libGL.so.1 (0x00007fb2bee21000)

If I force glxinfo to use /usr/lib/mesa/libGL.so.1 instead I get:
# (LD_LIBRARY_PATH=/usr/lib/mesa/ /usr/bin/glxinfo)
name of display: :0.0
X Error of failed request:  BadRequest (invalid request code or no such operation)
  Major opcode of failed request:  155 (GLX)
  Minor opcode of failed request:  19 (X_GLXQueryServerString)
  Serial number of failed request:  14
  Current serial number in output stream:  14

Comment 20

[Mats Palmgren (inactive)]

BTW, I wrote a minimal test program for this:
int main(int argc, char** argv)
{
    gtk_init(&argc, &argv);
    Display *display = GDK_DISPLAY();
    int screen = DefaultScreen(display);
    int gGLXMajorVersion, gGLXMinorVersion;
    if (!glXQueryVersion(display, &gGLXMajorVersion, &gGLXMinorVersion)) {
... etc ...

It crashes too...
My next step would be to see if I can find a unique symbol
to probe with dlsym that can be used to blacklist this dll.
Let me know if you have other ideas...

Comment 21

[Karl Tomlinson (:karlt)]

Thanks, Mats.  That's in-line with my ideas, and looking for a unique dynamic symbol to identify fglrx might be an option.

I was also wondering whether we could glXGetClientString to identify the libGL.so that is crashing.

http://www.opengl.org/sdk/docs/man/xhtml/glXGetClientString.xml

One possible issue is that "glXGetClientString is available only if the GLX version is 1.1 or greater", though I would hope that the presence of a glXGetClientString symbol means it is safe to use that for a function call.
I assume version 1.1 is old, so we may not need to worry about earlier versions anyway.

Comment 22

[Mats Palmgren (inactive)]

Attachment: wallpaper

After digging some more it turns out my system was misconfigured.
I had both the fglrx and radeon kernel modules loaded.  The radeon
one must be a remnant from some earlier configuration.

Fwiw, I did find a unique symbol in the fglrx libGL.so: AtiCallFGLComposite
This patch also looks for "radeon" in "/proc/modules" to detect my
particular misconfiguration.

Using glXGetClientString is also an option, it returns "ATI".

Comment 23

[Mats Palmgren (inactive)]

Attachment: fglrx crash-on-exit

After fixing the misconfiguration and using the fglrx driver;
forcing GL on by setting MOZ_GLX_IGNORE_BLACKLIST works fine
using it, until I exit where it crashes with this stack
(100% reproducible).  This looks like it might be our fault,
possibly some libGL resource we should release or some such.

A properly configured radeon driver seems to work fine,
but is incredibly slow (overall, not just GL).

Comment 24

[Mats Palmgren (inactive)]

So, since GL is going to be disabled anyway unless the vendor
string is "NVIDIA Corporation"
http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/GLContextProviderGLX.cpp#186
we could wallpaper these crashes by making an early return if
glXGetClientString says "ATI".

Not sure if it's worth it though, https://crash-stats.mozilla.com/
has about 300 crashes on Linux for the past to weeks matching
"libGL.so".  I suspect there are multiple crashes per user that
suffers from this.

Comment 25

[Mats Palmgren (inactive)]

s/to weeks/two weeks/

Comment 26

[Mats Palmgren (inactive)]

Attachment: GL info for fglrx

Comment 27

[Mats Palmgren (inactive)]

Attachment: GL info for radeon

Comment 28

[Karl Tomlinson (:karlt)]

(In reply to comment #22)
> After digging some more it turns out my system was misconfigured.
> I had both the fglrx and radeon kernel modules loaded.  The radeon
> one must be a remnant from some earlier configuration.

Having the radeon module loaded may have resulted in the server having a
different GLX implementation, but still the client libGL should not crash
because of a GLX vendor mismatch.  (The server may be on another machine
even.)

Crashing on GLX vendor mismatch is reason enough to blacklist this libGL IMO.

(In reply to comment #24)
> So, since GL is going to be disabled anyway unless the vendor
> string is "NVIDIA Corporation"
> http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/GLContextProviderGLX.cpp#186
> we could wallpaper these crashes by making an early return if
> glXGetClientString says "ATI".

That would be the way I'd blacklist this.  I fear this crash can happen in
more situations than just having the radeon kernel module loaded.  This
approach also allows us to add a client GLX_VERSION check in the future.

I wonder why we currently blacklist on server string rather than client string?

> Not sure if it's worth it though, https://crash-stats.mozilla.com/
> has about 300 crashes on Linux for the past to weeks matching
> "libGL.so".  I suspect there are multiple crashes per user that
> suffers from this.

Yes, it's hard to interpret crash reports because one user can submit many
reports, skewing the results.  I'm guessing from the way build-ids in some
reports "go back in time", there are two users on nightlies seeing the
libGL.so.1.2@0x5b38e crash.  There is also this one on beta11 with a different
kernel version:

bp-3921d33f-da53-459a-87fb-2285d2110215

There are also a number of different libGL.so.1.2 crash reports that may be
related but it's hard to tell from the failed stack scanning.

beta11:
bp-bfea2a9e-328c-4033-ae7c-5889a2110219
bp-7f95f330-31b4-47cf-bc90-878c62110218

beta12:
bp-07778a18-c26c-488b-ac1a-3208e2110226
bp-df6c44c5-039b-443d-8595-fc2cd2110226
bp-02634b06-91f0-4379-a788-0a8a12110227

nightly:
bp-ea9dab85-1503-49ea-94f8-03b8e2110226

Mats, do you have resources set up to try running something (firefox or
glxinfo) with the fglrx libGL on your machine that had the problem,
but with a different server/DISPLAY, either on another machine or a tigervnc
session or similar?

Comment 29

[Benoit Jacob [:bjacob] (mostly away)]

> (In reply to comment #24)
> I wonder why we currently blacklist on server string rather than client string?

I didn't really know the difference and had to pick one. Feel free to change this.

Comment 30

[Karl Tomlinson (:karlt)]

(In reply to comment #28)
> Mats, do you have resources set up to try running something (firefox or
> glxinfo) with the fglrx libGL on your machine that had the problem,
> but with a different server/DISPLAY, either on another machine or a tigervnc
> session or similar?

Sorry.  Worked out how to do that myself at it was all bad with ati-driver-installer-11-2 on IA32 and amd64.

https://bugs.launchpad.net/ubuntu/+bug/555158 also gives a situation where this is likely to happen: hybrid intel/amd graphics.

Comment 31

[Karl Tomlinson (:karlt)]

All the crash reports in comment 28 have libatiuki.so.1.0 loaded, indicating ATI libGL.

Comment 32

[Karl Tomlinson (:karlt)]

(In reply to comment #28)
> (In reply to comment #24)
> > we could wallpaper these crashes by making an early return if
> > glXGetClientString says "ATI".
> 
> This
> approach also allows us to add a client GLX_VERSION check in the future.

Well, the version check is of limited use because 11.2 already reports GLX version 1.4.  Vendor specific info can be supplied in the form "<major_version.minor_version><space><vendor-specific info>" but none is provided currently.

GLX_EXTENSIONS may be useful for differentiating versions, but so might dynamic symbols.  I guess we worry about that once the bug is fixed.

Comment 33

[Karl Tomlinson (:karlt)]

Attachment: blacklist "ATI" glXGetClientString

I prefer glXGetClientString over library symbol testing mainly because that seems the appropriate API.  I'm yet to test this patch.

Comment 34

[Karl Tomlinson (:karlt)]

Attachment: blacklist "ATI" glXGetClientString v1.1

I left the existing glXQueryServerString/NVIDIA check at this stage because that is what has been tested.  (Changing that to a client string test would allow situations, for example, where the client libGL is from NVIDIA but the server is using Mesa.  It might be reasonably likely that the client library wouldn't crash the browser, but we don't know whether the X server might crash.)

I also checked that Mesa and ATI's libGL make no X server requests during glXGetClientString.

If we want to unblacklist ATI drivers in situations where we expect them to work it looks like we should check for an ATIFGLEXTENSION extension on the server.
There's no reason to do that now though as it will be blacklisted anyway (because it is not NVIDIA).

Comment 35

[Karl Tomlinson (:karlt)]

I generated some crashes with libGLs from different ATI driver packages and got these crash signatures.

driver version 32-bit                    64-bit
10.10          [@ libGL.so.1.2@0x6d5a0 ] [@ libGL.so.1.2@0x5b38e ]
10.11          [@ libGL.so.1.2@0x6d620 ] [@ libGL.so.1.2@0x5b3ee ]
10.12          [@ libGL.so.1.2@0x73f58 ] [@ libGL.so.1.2@0x5f92e ]
11.2           [@ libGL.so.1.2@0x7714c ] [@ libGL.so.1.2@0x61dbe ]

The 32-bit 10.10 and 10.12 signature show in 20 and 10 beta12 crashes from
several different users.
32-bit and 64-bit 11.2 signatures also show in crash reports but in smaller numbers.

There's definitely a variety of users seeing the crash, and so it is something we'd like to see fixed in a stability release (requiring no beta coverage).

Comment 36

[Daniel Veditz [:dveditz]]

I'm going to assume Karl meant to request blocking on 2.0 since the 1.9.2 branch doesn't support WebGL or other acceleration.

Comment 37

[Karl Tomlinson (:karlt)]

Yes, thanks dveditz.

Comment 38

[nemo]

WRT comment #20, I adapted your minimal testcase to more recent GDK, and tried it on my system:
01:00.0 VGA compatible controller: ATI Technologies Inc RV730XT [Radeon HD 4670]
ATI Proprietary Linux Driver Version Identifier:8.78.30

Your sample...
http://m8y.org/tmp/glquery.c
gcc `pkg-config --cflags-only-I --libs  gdk-pixbuf-xlib-2.0 gtk+-2.0 gl` glquery.c
./a.out
Screen: 0
Major/Minor GL version: 1 4

no errors.
But then, you suggested it was due to an odd configuration?  So this wouldn't be typical for linux fglrx users?
'cause, I've also had no problems with the webgl test suite.

Basically, wondering if fglrx errors are rare and if it warrants whitelisting like nvidia.  Pretty sure I've run into people reporting nvidia crashes w/ our opengl game too in the past...

Comment 39

[Joe Drew (not getting mail)]

Comment on attachment 515803 [details] [diff] [review]
blacklist "ATI" glXGetClientString v1.1

We're going to take this in a security/stability (.x) release in the future. When those flags are created, please request approval!

Comment 40

[Joe Drew (not getting mail)]

People who want to turn WebGL off to stop these crashes want to change the hidden pref "webgl.disabled" to true.

Comment 41

[Karl Tomlinson (:karlt)]

(In reply to comment #38)
> But then, you suggested it was due to an odd configuration?  So this wouldn't
> be typical for linux fglrx users?

This crash shouldn't happen in the most common situation, but it does happen in plenty of sensibly configured situations.

> 'cause, I've also had no problems with the webgl test suite.

Did it pass with 100%, or are you saying it didn't crash?

If firefox exits with status 0 on quit after running the webgl test suite (doesn't crash as in comment 23), then we would like to be able to identify/differentiate the version of the fglrx_dri.so and/or libGL.so.1.2 library (not the kernel module or server modules) but I don't know how to do that.

Comment 42

[nemo]

Heh. AFAIK Firefox doesn't pass 100% with any driver :)

Results: (5385 of 5470 passed, 1 timed out)
http://m8y.org/tmp/fglrx_webgl.txt

Exited cleanly, no crash on shutdown, no errors of any kind.

Yeah, not too sure 'sactly what the crucial info is that differentiates these, but gave the ATI fglrx driver version, card type and glx version string already.
OpenGL itself appears to be provided by:
7.9~git20100924-0ubuntu2 which is presumably 7.9 + some ubuntu patches.

Comment 43

[Steve Roylance]

Mozilla/5.0 (X11; Linux i686; rv:2.0b12) Gecko/20100101 Firefox/4.0b12
http://abc.net.au/tv/
worked 06-Mar, crashes today

Comment 44

[Karl Tomlinson (:karlt)]

Steve, do you have hybrid graphics processors on your system?

Comment 45

[Steve Roylance]

$ uname -r                                                                     
2.6.35.11-83.fc14.i686.PAE
video card
NVidia - GeForce GT 220
NVidia driver 260.19.36

Comment 46

[Karl Tomlinson (:karlt)]

Sorry, Steve.  We've accidentally hijacked your bug.
The crash Mats was seeing is quite unrelated to your crash.

I've filed Bug 640071 to track your crash.
Can you link to a crash report there (or mention the lack of crash reporter if missing), please?

Comment 47

[Karl Tomlinson (:karlt)]

http://hg.mozilla.org/mozilla-central/rev/fa658a942728

Comment 48

[Benoit Jacob [:bjacob] (mostly away)]

To Mats / anyone who could reproduce the ATI FGLRX crash (comment 23):
what is your GL_VERSION string ? You can get it by running:

  glxinfo | grep version

I am trying to figure if I can whitelist newer FGLRX drivers based on that.

Comment 49

[Mats Palmgren (inactive)]

I've uninstalled FGLRX now, but it reported 1.4 IIRC.

> I am trying to figure if I can whitelist newer FGLRX drivers based on that.

I tried both the Ubuntu packaged driver and the very latest from AMD -
both crashed on exit.  FWIW, I think we could whitelist it (after we
have fixed our crash).

Comment 50

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to comment #49)
> I've uninstalled FGLRX now, but it reported 1.4 IIRC.

OK -- so it wasn't a very recent version. It's going to get blacklisted by my patch which requires OpenGL 3 for FGLRX (bug 645407).

Comment 51

[Karl Tomlinson (:karlt)]

Note that most GLX implementations report "1.4" for all the GLX versions.
The "OpenGL version string" may have been quite different.

Comment 52

[Mats Palmgren (inactive)]

For the record, the driver I downloaded directly from the vendor:
http://support.amd.com/us/gpudownload/windows/previous/11/Pages/radeon_linux.aspx?os=Linux%20x86&rev=11.2
Their internal version is 11.2, dated 2/15/2011.
Sorry, I have no record of what the "OpenGL version string" was.
(this is the driver I used in comment 23 that cause a crash on exit)

They have a new version now (11.3), dated 3/29/2011.  I haven't tried it.
http://support.amd.com/us/gpudownload/linux/Pages/radeon_linux.aspx?type=2.4.1&product=2.4.1.3.42&lang=English

Comment 53

[Benoit Jacob [:bjacob] (mostly away)]

Mats: I mean the 'opengl version string' as in `glxinfo | grep version`

Comment 54

[Mats Palmgren (inactive)]

So, I installed the latest fglrx driver from AMD, version 10.3.
I tried two different cards, using a low-end Radeon HD 2xxx card:

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL version string: 3.3.10600 Compatibility Profile Context
OpenGL shading language version string: 3.30

and a Radeon HD 5570 card:

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL version string: 4.1.10600 Compatibility Profile Context
OpenGL shading language version string: 4.10

Both seems to work fine with MOZ_GLX_IGNORE_BLACKLIST=1
there's no crash on exit anymore (to my surprise).
I tried both 4.0 and a local mozilla-central debug build (both x86-64).

Comment 55

[Mats Palmgren (inactive)]

s/10.3/11.3

Comment 56

[Karl Tomlinson (:karlt)]

That's good to know.  Thanks for testing, Mats.