Last Comment Bug 680644 - [FGLRX] glxtest process crashes the X server
: [FGLRX] glxtest process crashes the X server
Status: RESOLVED FIXED
[sg:dos]
: crash
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: x86_64 Linux
: -- major with 1 vote (vote)
: mozilla18
Assigned To: martin.vogt
:
Mentors:
http://bugs.debian.org/638208
Depends on: 799544
Blocks: 693168
  Show dependency treegraph
 
Reported: 2011-08-20 00:53 PDT by bugzilla-mozilla
Modified: 2014-01-10 10:41 PST (History)
11 users (show)
See Also:
Crash Signature:
(edit)
One statement in the kern.log shows: firefox-bin
[6567]
: segfault at ffffffffeec6a968 ip 00007f97ea8d4ef8 sp 00007fff88217760 error 4 in libX11.so.6.3.0
[7f97ea898000+139000]
In an older Xorg.0.log (also crashed by iceweasel, but not using the gdb) this data can be found: Backtrace:
[ 78.056]
0: /usr/bin/Xorg (xorg_backtrace+0x26)
[0x4a3836]
[ 78.056]
1: /usr/bin/Xorg (0x400000+0x65049)
[0x465049]
[ 78.056]
2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fa079bd4000+0xf020)
[0x7fa079be3020]
[ 78.056]
3: /lib/x86_64-linux-gnu/libc.so.6 (0x7fa0788ef000+0x74125)
[0x7fa078963125]
[ 78.056]
4: /lib/x86_64-linux-gnu/libc.so.6 (cfree+0x6c)
[0x7fa07896633c]
[ 78.056]
5: /usr/lib/x86_64-linux-gnu/libX11.so.6 (XFree+0x9)
[0x7fa070c674a9]
[ 78.056]
6: /usr/lib64/dri/fglrx_dri.so (__driCreateNewScreen_20050727+0x89e)
[0x7fa072a3acae]
[ 78.056]
7: /usr/lib/xorg/modules/extensions/libglx.so (0x7fa0773d0000+0x1c45d)
[0x7fa0773ec45d]
[ 78.056]
8: /usr/lib/xorg/modules/extensions/libglx.so (0x7fa0773d0000+0x1e185)
[0x7fa0773ee185]
[ 78.056]
9: /usr/bin/Xorg (InitExtensions+0x99)
[0x488e69]
[ 78.057]
10: /usr/bin/Xorg (0x400000+0x26e0b)
[0x426e0b]
[ 78.057]
11: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xfd)
[0x7fa07890dead]
[ 78.057]
12: /usr/bin/Xorg (0x400000+0x2729d)
[0x42729d]
[ 78.057]
Segmentation fault at address 0xffffffff00000028
[ 78.057]
Fatal server error:
[ 78.057]
Caught signal 11 (Segmentation fault). Server aborting
[ 78.057]
[ 78.057]
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed
verified
verified


Attachments
apitrace result (1.09 KB, application/octet-stream)
2011-08-22 12:20 PDT, bugzilla-mozilla
no flags Details
apitrace (838 bytes, application/octet-stream)
2011-08-26 11:18 PDT, bugzilla-mozilla
no flags Details
modified glxtest (will still crash) (9.75 KB, text/plain)
2012-08-13 06:12 PDT, martin.vogt
no flags Details
replace GLXPixmap with window does not crash (1.17 KB, patch)
2012-08-13 06:14 PDT, martin.vogt
no flags Details | Diff | Splinter Review
demo for crash in indirect case (includes mesa libGL) (271.86 KB, application/octet-stream)
2012-08-13 06:17 PDT, martin.vogt
no flags Details
for ff 10 (3.68 KB, patch)
2012-08-14 05:04 PDT, martin.vogt
no flags Details | Diff | Splinter Review
for current checkout (ff14) (3.82 KB, patch)
2012-08-14 05:05 PDT, martin.vogt
jacob.benoit.1: review-
Details | Diff | Splinter Review
patch for ff10 V2 (3.71 KB, patch)
2012-08-17 02:42 PDT, martin.vogt
no flags Details | Diff | Splinter Review
patch for ff14 V2 (3.71 KB, patch)
2012-08-17 02:43 PDT, martin.vogt
no flags Details | Diff | Splinter Review
improvement for ff10 V2, which works on nvidia in the remote case too. (4.16 KB, patch)
2012-08-17 02:45 PDT, martin.vogt
no flags Details | Diff | Splinter Review
improvement for ff14 V2, which works on nvidia in the remote case too. (4.16 KB, patch)
2012-08-17 02:46 PDT, martin.vogt
jacob.benoit.1: review+
lukasblakk+bugs: approval‑mozilla‑aurora+
lukasblakk+bugs: approval‑mozilla‑beta+
Details | Diff | Splinter Review
imitate what glxinfo does to avoid crashing the X server on the build slaves (5.76 KB, patch)
2012-08-27 08:17 PDT, Benoit Jacob [:bjacob] (mostly away)
karlt: review+
lukasblakk+bugs: approval‑mozilla‑aurora+
lukasblakk+bugs: approval‑mozilla‑beta+
Details | Diff | Splinter Review

Description bugzilla-mozilla 2011-08-20 00:53:49 PDT
After upgrading to iceweasel 6 the browser crashes when oping a URL from another
program (e.g. from the mail client, from the terminal, ...). One of about every
15 iceweasel calls crashes the browser. An URL which worked before fine will
crash the browser the next time, it's not URL based/related as far as I can see.
Unfortunately the bowser crash also terminates the X-server.


glxinfo | egrep version\|renderer\|vendor
server glx vendor string: ATI
server glx version string: 1.4
client glx vendor string: ATI
client glx version string: 1.4
GLX version: 1.4
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Radeon HD 3200 Graphics
OpenGL version string: 2.1 (3.3.11005 Compatibility Profile Context)
OpenGL shading language version string: (null)
Comment 1 Oleg Romashin (:romaxa) 2011-08-20 10:32:57 PDT
I guess mozilla don't care officially about Fire-forks... try to download official latest Firefox from www.firefox.com, and try to reproduce it there... if it is not reproducible with official version, then you should probably go to http://www.debian.org/Bugs/
Comment 2 Benoit Jacob [:bjacob] (mostly away) 2011-08-20 18:49:53 PDT
This has already been filed as bugs.debian.org/cgi-bin/bugreport.cgi?bug=638208 and I personally asked for it to be filed here.

Actually, this isn't really the kind of thing that would be different in a Firefox fork from Firefox itself, unless the fork does something really weird (can I see the diff / list of patches somewhere?)

In other words I expect that the same (driver) bug would be triggered by Firefox itself and therefore we have to do something about it.

At this point I don't see a much better thing to do than completely blacklisting FGLRX, if we're going to do anything. To help decide that, I'd like this bug to be reproduced. To that effect, can you share details about your system? I would like to know precise versions of:
  - kernel
  - X server
  - FGLRX driver

Also, can you check if the 'glxinfo' command also occasionally crashes the X server? If it doesn't then I'd like to understand why (given that what Firefox does on startup to check GLX information is extremely similar to glxinfo).
Comment 3 Benoit Jacob [:bjacob] (mostly away) 2011-08-20 18:54:25 PDT
Also, how experimental/custom is your set of installed packages for stuff relevant to this (X, FGLRX, kernel)? I just don't want to blacklist FGLRX just based on a bug that happened with, say, an experimental driver or kernel or X server.
Comment 4 Benoit Jacob [:bjacob] (mostly away) 2011-08-20 19:05:15 PDT
To be clear, here's what's going on in Firefox 6. See bug 639842. At startup, Firefox forks a process that creates a GL context and calls glGetString to get OpenGL driver information, to decide whether to blacklist. Doing this in a separate process is needed to work around driver bugs that can crash our process. But the one thing that we can't work around with this approach is a crash of the X server itself. To work around that, we need a solution that doesn't involve creating a GL context at all. Unfortunately, in this case we only have access to much coarser info. We can tell whether we have FGLRX or not by calling glxQueryServerString, but that's about it. We can't get any kind of version info in this way. That's why I say above that the only thing we could do would be to completely blacklist FGLRX.
Comment 5 Oleg Romashin (:romaxa) 2011-08-20 22:21:01 PDT
list of debian patches here:
http://ftp.de.debian.org/debian/pool/main/i/iceweasel/iceweasel_6.0-2.debian.tar.gz
Comment 6 bugzilla-mozilla 2011-08-21 00:52:46 PDT
I missed to point out on thing, sorry.
Iceweasel is already running, having a few tabs open. Calling URLs inside iceweasel (click link, add into URL bar, ...) works without any problem.
Only when trying to open a additional URL from "outside" this crash sometimes happens.
Comment 7 Benoit Jacob [:bjacob] (mostly away) 2011-08-21 05:54:30 PDT
(In reply to bugzilla-mozilla from comment #6)
> I missed to point out on thing, sorry.
> Iceweasel is already running, having a few tabs open. Calling URLs inside
> iceweasel (click link, add into URL bar, ...) works without any problem.
> Only when trying to open a additional URL from "outside" this crash
> sometimes happens.

What happens is that everytime you run firefox, it tries again to create an OpenGL context to get driver info. When you do 'firefox someurl' it does that before checking if another Firefox is already running. That's why it can reproduce the crash even if it's going to just attach to another Firefox in the end. I'm sure you could reproduce this crash just by launching Firefox without any page loaded at all, quitting it, and retrying sufficiently many times.
Comment 8 Benoit Jacob [:bjacob] (mostly away) 2011-08-21 05:57:24 PDT
(In reply to Oleg Romashin (:romaxa) from comment #5)
> list of debian patches here:
> http://ftp.de.debian.org/debian/pool/main/i/iceweasel/iceweasel_6.0-2.debian.
> tar.gz

Thanks, I've now checked that Iceweasel is no different from Firefox in this respect. Method:

$ cd debian/patches
$ grep -Ri glx .
./configure.patch: if test -n "$MOZ_WEBGL_GLX"; then
./configure.patch:        ac_safe=`echo "GL/glx.h" | sed 'y%./+-%__p_%'`
./configure.patch:   echo $ac_n "checking for GL/glx.h""... $ac_c" 1>&6
./configure.patch:-echo "configure:24888: checking for GL/glx.h" >&5
./configure.patch:+echo "configure:25052: checking for GL/glx.h" >&5
./configure.patch: #include <GL/glx.h>
./configure.patch: fi # MOZ_WEBGL_GLX
./debian-hacks/Check-less-things-during-configure-when-using-libxul.patch:@@ -9151,7 +9171,7 @@ if test -n "$MOZ_WEBGL_GLX"; then
./debian-hacks/Check-less-things-during-configure-when-using-libxul.patch: fi # MOZ_WEBGL_GLX

This stuff is just configure checks for GLX headers.
Comment 9 Benoit Jacob [:bjacob] (mostly away) 2011-08-21 05:59:00 PDT
Can you please still answer my questions in comment 2 and comment 3 ?
Comment 10 bugzilla-mozilla 2011-08-21 06:41:47 PDT
(In reply to Benoit Jacob [:bjacob] from comment #2)
I would like to know precise versions of:
>   - kernel
Linux vishnu 3.0.0-1-amd64 #1 SMP Wed Aug 17 04:08:52 UTC 2011 x86_64 GNU/Linux
>   - X server
xorg-server 2:1.10.3-1 (Cyril Brulebois <kibi@debian.org>)
>   - FGLRX driver
fglrx 8.88.7 [Jul 28 2011]
Comment 11 Benoit Jacob [:bjacob] (mostly away) 2011-08-21 06:43:53 PDT
Thanks; can you please also check this:

> Also, can you check if the 'glxinfo' command also occasionally crashes the X
> server?

i.e. just run it a few dozen times...
Comment 12 bugzilla-mozilla 2011-08-21 06:48:58 PDT
To be sure not loosing the entered data, I split the information up into small pieces.
glxinfo has been startet 1000 times without any crash
Comment 13 bugzilla-mozilla 2011-08-21 06:50:42 PDT
(In reply to Benoit Jacob [:bjacob] from comment #3)
> Also, how experimental/custom is your set of installed packages for stuff
> relevant to this (X, FGLRX, kernel)? I just don't want to blacklist FGLRX
> just based on a bug that happened with, say, an experimental driver or
> kernel or X server.

All packages are from debian/sid (or debian testing). None of them is from the experimental branch.
Comment 14 Benoit Jacob [:bjacob] (mostly away) 2011-08-21 19:56:27 PDT
(In reply to bugzilla-mozilla from comment #12)
> glxinfo has been startet 1000 times without any crash

Thanks, that's really interesting. If glxinfo can run without crashing your X server, so should we.

The next most interesting thing would be if you could run Firefox with APItrace,
https://github.com/apitrace/apitrace
capture the output and attach it to this bug.

Let me know if running APItrace is problematic for you. Then we can provide a custom build of Firefox with built-in logging for this stuff.
Comment 15 bugzilla-mozilla 2011-08-22 12:20:14 PDT
Created attachment 554926 [details]
apitrace result

LD_PRELOAD=/path/to/glxtrace.so /usr/lib/iceweasel/firefox-bin
immediately crashed the server.
Comment 16 Benoit Jacob [:bjacob] (mostly away) 2011-08-25 13:22:51 PDT
Excellent, thanks! Sorry for the delay.

$ ./tracedump ~/Downloads/xulrunner-stub.trace 
0 glXQueryExtension(dpy = 0x7f7be636a000, errorb = NULL, event = NULL) = True
1 glXChooseFBConfig(dpy = 0x7f7be636a000, screen = 0, attribList = {GLX_DRAWABLE_TYPE, GLX_BUFFER_SIZE, GLX_X_RENDERABLE, GLX_USE_GL, 0}, nitems = &73) = {0x7f7be6359a60, 0x7f7be635a160, 0x7f7be635a860, 0x7f7be635b660, 0x7f7be63cafa0, 0x7f7be635bd60, 0x7f7be63ca520, 0x7f7be63596e0, 0x7f7be6359de0, 0x7f7be635a4e0, 0x7f7be635abe0, 0x7f7be635af60, 0x7f7be635b2e0, 0x7f7be635b9e0, 0x7f7be63ca1a0, 0x7f7be63ca8a0, 0x7f7be63cac20, 0x7f7be63598a0, 0x7f7be6359fa0, 0x7f7be635a6a0, 0x7f7be635b4a0, 0x7f7be63cade0, 0x7f7be635bba0, 0x7f7be63ca360, 0x7f7be6359520, 0x7f7be6359c20, 0x7f7be635a320, 0x7f7be635aa20, 0x7f7be635ada0, 0x7f7be635b120, 0x7f7be635b820, 0x7f7be635bf20, 0x7f7be63ca6e0, 0x7f7be63caa60, 0x7f7be6359980, 0x7f7be635a080, 0x7f7be635a780, 0x7f7be635b580, 0x7f7be63caec0, 0x7f7be635bc80, 0x7f7be63ca440, 0x7f7be6359600, 0x7f7be6359d00, 0x7f7be635a400, 0x7f7be635ab00, 0x7f7be635ae80, 0x7f7be635b200, 0x7f7be635b900, 0x7f7be63ca0c0, 0x7f7be63ca7c0, 0x7f7be63cab40, 0x7f7be63597c0, 0x7f7be6359ec0, 0x7f7be635a5c0, 0x7f7be635b3c0, 0x7f7be63cad00, 0x7f7be635bac0, 0x7f7be63ca280, 0x7f7be6359440, 0x7f7be6359b40, 0x7f7be635a240, 0x7f7be635a940, 0x7f7be635acc0, 0x7f7be635b040, 0x7f7be635b740, 0x7f7be635be40, 0x7f7be63ca600, 0x7f7be63ca980, 0x7f7be63cb400, 0x7f7be63cb080, 0x7f7be63cb320, 0x7f7be63cb160, 0x7f7be63cb240}                                                        
2 glXGetVisualFromFBConfig(dpy = 0x7f7be636a000, config = 0x7f7be6359a60) = &{visual = 0x7f7be6378188, visualid = 42, screen = 0, depth = 24, c_class = 4, red_mask = 16711680, green_mask = 65280, blue_mask = 255, colormap_size = 256, bits_per_rgb = 8}
3 glXCreatePixmap(dpy = 0x7f7be636a000, config = 0x7f7be6359a60, pixmap = 54525953, attribList = NULL) = 54525954                                                                                                   
4 glXCreateNewContext(dpy = 0x7f7be636a000, config = 0x7f7be6359a60, renderType = GLX_RGBA_TYPE, shareList = NULL, direct = True) = 0x7f7be63c4180
5 glXMakeCurrent(dpy = 0x7f7be636a000, drawable = 54525954, ctx = 0x7f7be63c4180) = True
6 glGetString(name = GL_VENDOR) = "ATI Technologies Inc."
7 glGetString(name = GL_RENDERER) = "ATI Radeon HD 3200 Graphics"
8 glGetString(name = GL_VERSION) = "2.1 (3.3.11005 Compatibility Profile Context)"
9 glXMakeCurrent(dpy = 0x7f7be636a000, drawable = 0, ctx = NULL) = True
10 glXDestroyContext(dpy = 0x7f7be636a000, ctx = 0x7f7be63c4180)
11 glXDestroyPixmap(dpy = 0x7f7be636a000, pixmap = 54525954)


This means that cause the X server crash at this place:

http://hg.mozilla.org/mozilla-central/file/d0700ba932b4/toolkit/xre/glxtest.cpp#l238

  glXMakeCurrent(dpy, None, NULL);
  glXDestroyContext(dpy, context);
  glXDestroyPixmap(dpy, glxpixmap);  // X server crashes here
  XFreePixmap(dpy, pixmap);
  XCloseDisplay(dpy);
  dlclose(libgl);

This is during the final cleanup, after we've obtained the information we need.

There's 2 things I want to try to see if they work around this crash:
 1) don't free this pixmap on FGLRX, just leak it. Anyway it's going to be freed by the subsequent XCloseDisplay
 2) use a larger pixmap. Maybe it's too unusual to have a 4x4 pixmap to back a GL context and FGLRX assumes a larger size.
 3) check what glxinfo does.
Comment 17 Benoit Jacob [:bjacob] (mostly away) 2011-08-25 13:29:23 PDT
glxinfo source code is here:
http://cgit.freedesktop.org/mesa/demos/tree/src/xdemos/glxinfo.c

It doesn't use a glx pixmap at all, instead it uses a XWindow and its size is 100x100.
Comment 18 Benoit Jacob [:bjacob] (mostly away) 2011-08-25 14:02:01 PDT
I've launched a try-build:
http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=a65faf2267f2

This bug will get notified when it's done (in ~2 hours). Please try this build with the following environment variables:

MOZ_GLXTEST_DONT_DESTROY_PIXMAP=1  - makes us not destroy the pixmap, which is what was crashing on your machine.
MOZ_GLXTEST_PIXMAP_SIZE=32    (or any other value) - makes us use a pixmap of given size (default is 4, try something larger like 32).

It will output to the terminal a message confirming that it's picked up your option, for example:

### Not destroying the pixmap!

and

### Using pixmap size 32
Comment 19 Benoit Jacob [:bjacob] (mostly away) 2011-08-25 14:02:28 PDT
When the builds are ready, they will be available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bjacob@mozilla.com-a65faf2267f2
Comment 20 Mozilla RelEng Bot 2011-08-25 15:01:17 PDT
Try run for a65faf2267f2 is complete.
Detailed breakdown of the results available here:
    http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=a65faf2267f2
Results (out of 2 total builds):
    success: 1
    warnings: 1
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bjacob@mozilla.com-a65faf2267f2
Comment 21 bugzilla-mozilla 2011-08-26 08:53:03 PDT
New build still crashes. The number of lines in the apitrace log is the same, doesn't matter if it crashes or not.

no crash:
0 glXQueryExtension(dpy = 0x7f227f862000, errorb = NULL, event = NULL) = True
1 glXQueryVersion(dpy = 0x7f227f862000, maj = &1, min = &4) = True
2 glXChooseFBConfig(dpy = 0x7f227f862000, screen = 0, attribList = {GLX_DRAWABLE_TYPE, GLX_BUFFER_SIZE, GLX_X_RENDERABLE, GLX_USE_GL, 0}, nitems = &73) = {0x7f227f820b40, 0x7f227f821240, 0x7f227f821940, 0x7f227f822740, 0x7f227f8c3080, 0x7f227f822e40, 0x7f227f8c2600, 0x7f227f8207c0, 0x7f227f820ec0, 0x7f227f8215c0, 0x7f227f821cc0, 0x7f227f822040, 0x7f227f8223c0, 0x7f227f822ac0, 0x7f227f8c2280, 0x7f227f8c2980, 0x7f227f8c2d00, 0x7f227f820980, 0x7f227f821080, 0x7f227f821780, 0x7f227f822580, 0x7f227f8c2ec0, 0x7f227f822c80, 0x7f227f8c2440, 0x7f227f820600, 0x7f227f820d00, 0x7f227f821400, 0x7f227f821b00, 0x7f227f821e80, 0x7f227f822200, 0x7f227f822900, 0x7f227f8c20c0, 0x7f227f8c27c0, 0x7f227f8c2b40, 0x7f227f820a60, 0x7f227f821160, 0x7f227f821860, 0x7f227f822660, 0x7f227f8c2fa0, 0x7f227f822d60, 0x7f227f8c2520, 0x7f227f8206e0, 0x7f227f820de0, 0x7f227f8214e0, 0x7f227f821be0, 0x7f227f821f60, 0x7f227f8222e0, 0x7f227f8229e0, 0x7f227f8c21a0, 0x7f227f8c28a0, 0x7f227f8c2c20, 0x7f227f8208a0, 0x7f227f820fa0, 0x7f227f8216a0, 0x7f227f8224a0, 0x7f227f8c2de0, 0x7f227f822ba0, 0x7f227f8c2360, 0x7f227f820520, 0x7f227f820c20, 0x7f227f821320, 0x7f227f821a20, 0x7f227f821da0, 0x7f227f822120, 0x7f227f822820, 0x7f227f822f20, 0x7f227f8c26e0, 0x7f227f8c2a60, 0x7f227f8c34e0, 0x7f227f8c3160, 0x7f227f8c3400, 0x7f227f8c3240, 0x7f227f8c3320}
3 glXGetVisualFromFBConfig(dpy = 0x7f227f862000, config = 0x7f227f820b40) = &{visual = 0x7f227f870188, visualid = 42, screen = 0, depth = 24, c_class = 4, red_mask = 16711680, green_mask = 65280, blue_mask = 255, colormap_size = 256, bits_per_rgb = 8}
4 glXCreatePixmap(dpy = 0x7f227f862000, config = 0x7f227f820b40, pixmap = 54525953, attribList = NULL) = 54525954
5 glXCreateNewContext(dpy = 0x7f227f862000, config = 0x7f227f820b40, renderType = GLX_RGBA_TYPE, shareList = NULL, direct = True) = 0x7f227f8bc180
6 glXMakeCurrent(dpy = 0x7f227f862000, drawable = 54525954, ctx = 0x7f227f8bc180) = True
7 glXGetProcAddress(procName = "glXBindTexImageEXT") = 0x7f2275ee6100
8 glGetString(name = GL_VENDOR) = "ATI Technologies Inc."
9 glGetString(name = GL_RENDERER) = "ATI Radeon HD 3200 Graphics"
10 glGetString(name = GL_VERSION) = "2.1 (3.3.11005 Compatibility Profile Context)"
11 glXMakeCurrent(dpy = 0x7f227f862000, drawable = 0, ctx = NULL) = True
12 glXDestroyContext(dpy = 0x7f227f862000, ctx = 0x7f227f8bc180)
13 glXDestroyPixmap(dpy = 0x7f227f862000, pixmap = 54525954)


crash:
0 glXQueryExtension(dpy = 0x7f1f78062000, errorb = NULL, event = NULL) = True
1 glXQueryVersion(dpy = 0x7f1f78062000, maj = &1, min = &4) = True
2 glXChooseFBConfig(dpy = 0x7f1f78062000, screen = 0, attribList = {GLX_DRAWABLE_TYPE, GLX_BUFFER_SIZE, GLX_X_RENDERABLE, GLX_USE_GL, 0}, nitems = &73) = {0x7f1f78020b40, 0x7f1f78021240, 0x7f1f78021940, 0x7f1f78022740, 0x7f1f780c3080, 0x7f1f78022e40, 0x7f1f780c2600, 0x7f1f780207c0, 0x7f1f78020ec0, 0x7f1f780215c0, 0x7f1f78021cc0, 0x7f1f78022040, 0x7f1f780223c0, 0x7f1f78022ac0, 0x7f1f780c2280, 0x7f1f780c2980, 0x7f1f780c2d00, 0x7f1f78020980, 0x7f1f78021080, 0x7f1f78021780, 0x7f1f78022580, 0x7f1f780c2ec0, 0x7f1f78022c80, 0x7f1f780c2440, 0x7f1f78020600, 0x7f1f78020d00, 0x7f1f78021400, 0x7f1f78021b00, 0x7f1f78021e80, 0x7f1f78022200, 0x7f1f78022900, 0x7f1f780c20c0, 0x7f1f780c27c0, 0x7f1f780c2b40, 0x7f1f78020a60, 0x7f1f78021160, 0x7f1f78021860, 0x7f1f78022660, 0x7f1f780c2fa0, 0x7f1f78022d60, 0x7f1f780c2520, 0x7f1f780206e0, 0x7f1f78020de0, 0x7f1f780214e0, 0x7f1f78021be0, 0x7f1f78021f60, 0x7f1f780222e0, 0x7f1f780229e0, 0x7f1f780c21a0, 0x7f1f780c28a0, 0x7f1f780c2c20, 0x7f1f780208a0, 0x7f1f78020fa0, 0x7f1f780216a0, 0x7f1f780224a0, 0x7f1f780c2de0, 0x7f1f78022ba0, 0x7f1f780c2360, 0x7f1f78020520, 0x7f1f78020c20, 0x7f1f78021320, 0x7f1f78021a20, 0x7f1f78021da0, 0x7f1f78022120, 0x7f1f78022820, 0x7f1f78022f20, 0x7f1f780c26e0, 0x7f1f780c2a60, 0x7f1f780c34e0, 0x7f1f780c3160, 0x7f1f780c3400, 0x7f1f780c3240, 0x7f1f780c3320}
3 glXGetVisualFromFBConfig(dpy = 0x7f1f78062000, config = 0x7f1f78020b40) = &{visual = 0x7f1f78070188, visualid = 42, screen = 0, depth = 24, c_class = 4, red_mask = 16711680, green_mask = 65280, blue_mask = 255, colormap_size = 256, bits_per_rgb = 8}
4 glXCreatePixmap(dpy = 0x7f1f78062000, config = 0x7f1f78020b40, pixmap = 52428801, attribList = NULL) = 52428802
5 glXCreateNewContext(dpy = 0x7f1f78062000, config = 0x7f1f78020b40, renderType = GLX_RGBA_TYPE, shareList = NULL, direct = True) = 0x7f1f780bc180
6 glXMakeCurrent(dpy = 0x7f1f78062000, drawable = 52428802, ctx = 0x7f1f780bc180) = True
7 glXGetProcAddress(procName = "glXBindTexImageEXT") = 0x7f1f6e6e6100
8 glGetString(name = GL_VENDOR) = "ATI Technologies Inc."
9 glGetString(name = GL_RENDERER) = "ATI Radeon HD 3200 Graphics"
10 glGetString(name = GL_VERSION) = "2.1 (3.3.11005 Compatibility Profile Context)"
11 glXMakeCurrent(dpy = 0x7f1f78062000, drawable = 0, ctx = NULL) = True
12 glXDestroyContext(dpy = 0x7f1f78062000, ctx = 0x7f1f780bc180)
13 glXDestroyPixmap(dpy = 0x7f1f78062000, pixmap = 52428802)
Comment 22 Benoit Jacob [:bjacob] (mostly away) 2011-08-26 08:56:29 PDT
Did you try defining the environment variables described in comment 18? Actually, from your APItrace log, it seems that you didn't. It's still crashing in glXDestroyPixmap which isn't called if you define MOZ_GLXTEST_DONT_DESTROY_PIXMAP in this build.
Comment 23 bugzilla-mozilla 2011-08-26 11:18:57 PDT
Created attachment 556080 [details]
apitrace

sorry for not reading the steps carefully.

When not setting a specific pixmapsize and MOZ_GLXTEST_DONT_DESTROY_PIXMAP=1 the trace looks like this:
0 glXQueryExtension(dpy = 0x7ffeaa962000, errorb = NULL, event = NULL) = True
1 glXQueryVersion(dpy = 0x7ffeaa962000, maj = &1, min = &4) = True
2 glXChooseFBConfig(dpy = 0x7ffeaa962000, screen = 0, attribList = {GLX_DRAWABLE_TYPE, GLX_BUFFER_SIZE, GLX_X_RENDERABLE, GLX_USE_GL, 0}, nitems = &73) = {0x7ffeaa920b40, 0x7ffeaa921240, 0x7ffeaa921940, 0x7ffeaa922740, 0x7ffeaa9c3080, 0x7ffeaa922e40, 0x7ffeaa9c2600, 0x7ffeaa9207c0, 0x7ffeaa920ec0, 0x7ffeaa9215c0, 0x7ffeaa921cc0, 0x7ffeaa922040, 0x7ffeaa9223c0, 0x7ffeaa922ac0, 0x7ffeaa9c2280, 0x7ffeaa9c2980, 0x7ffeaa9c2d00, 0x7ffeaa920980, 0x7ffeaa921080, 0x7ffeaa921780, 0x7ffeaa922580, 0x7ffeaa9c2ec0, 0x7ffeaa922c80, 0x7ffeaa9c2440, 0x7ffeaa920600, 0x7ffeaa920d00, 0x7ffeaa921400, 0x7ffeaa921b00, 0x7ffeaa921e80, 0x7ffeaa922200, 0x7ffeaa922900, 0x7ffeaa9c20c0, 0x7ffeaa9c27c0, 0x7ffeaa9c2b40, 0x7ffeaa920a60, 0x7ffeaa921160, 0x7ffeaa921860, 0x7ffeaa922660, 0x7ffeaa9c2fa0, 0x7ffeaa922d60, 0x7ffeaa9c2520, 0x7ffeaa9206e0, 0x7ffeaa920de0, 0x7ffeaa9214e0, 0x7ffeaa921be0, 0x7ffeaa921f60, 0x7ffeaa9222e0, 0x7ffeaa9229e0, 0x7ffeaa9c21a0, 0x7ffeaa9c28a0, 0x7ffeaa9c2c20, 0x7ffeaa9208a0, 0x7ffeaa920fa0, 0x7ffeaa9216a0, 0x7ffeaa9224a0, 0x7ffeaa9c2de0, 0x7ffeaa922ba0, 0x7ffeaa9c2360, 0x7ffeaa920520, 0x7ffeaa920c20, 0x7ffeaa921320, 0x7ffeaa921a20, 0x7ffeaa921da0, 0x7ffeaa922120, 0x7ffeaa922820, 0x7ffeaa922f20, 0x7ffeaa9c26e0, 0x7ffeaa9c2a60, 0x7ffeaa9c34e0, 0x7ffeaa9c3160, 0x7ffeaa9c3400, 0x7ffeaa9c3240, 0x7ffeaa9c3320}
3 glXGetVisualFromFBConfig(dpy = 0x7ffeaa962000, config = 0x7ffeaa920b40) = &{visual = 0x7ffeaa970188, visualid = 42, screen = 0, depth = 24, c_class = 4, red_mask = 16711680, green_mask = 65280, blue_mask = 255, colormap_size = 256, bits_per_rgb = 8}
4 glXCreatePixmap(dpy = 0x7ffeaa962000, config = 0x7ffeaa920b40, pixmap = 65011713, attribList = NULL) = 65011714
5 glXCreateNewContext(dpy = 0x7ffeaa962000, config = 0x7ffeaa920b40, renderType = GLX_RGBA_TYPE, shareList = NULL, direct = True) = 0x7ffeaa9bc180
6 glXMakeCurrent(dpy = 0x7ffeaa962000, drawable = 65011714, ctx = 0x7ffeaa9bc180) = True
7 glXGetProcAddress(procName = "glXBindTexImageEXT") = 0x7ffea0fe6100
8 glGetString(name = GL_VENDOR) = "ATI Technologies Inc."
9 glGetString(name = GL_RENDERER) = "ATI Radeon HD 3200 Graphics"
10 glGetString(name = GL_VERSION) = "2.1 (3.3.11005 Compatibility Profile Context)"
11 glXMakeCurrent(dpy = 0x7ffeaa962000, drawable = 0, ctx = NULL) = True
12 glXDestroyContext(dpy = 0x7ffeaa962000, ctx = 0x7ffeaa9bc180)

With MOZ_GLXTEST_DONT_DESTROY_PIXMAP=1 and a pixmapsize of 128 the browser seemed to take longer (more tries) to crash.
tracedump displays "warning: incomplete call glXMakeCurrent", so trace has been attached
Comment 24 Benoit Jacob [:bjacob] (mostly away) 2011-08-26 14:50:17 PDT
(In reply to bugzilla-mozilla from comment #23)
> With MOZ_GLXTEST_DONT_DESTROY_PIXMAP=1 and a pixmapsize of 128 the browser
> seemed to take longer (more tries) to crash.

Did the X server still crash?

If yes it's looking like the only reasonable response is to completely blacklist FGLRX. Indeed, without risking crashing the X server, I can only know whether you have FGLRX, I can't get more specific information.

Before doing that, since that has quite serious implications, I would like to have another report of FGLRX X server crashes on a different machine / setup though.
Comment 25 bugzilla-mozilla 2011-08-28 06:33:34 PDT
(In reply to Benoit Jacob [:bjacob] from comment #24)
> (In reply to bugzilla-mozilla from comment #23)
> > With MOZ_GLXTEST_DONT_DESTROY_PIXMAP=1 and a pixmapsize of 128 the browser
> > seemed to take longer (more tries) to crash.
> 
> Did the X server still crash?
Yes
> 
> If yes it's looking like the only reasonable response is to completely
> blacklist FGLRX. Indeed, without risking crashing the X server, I can only
> know whether you have FGLRX, I can't get more specific information.
> 
> Before doing that, since that has quite serious implications, I would like
> to have another report of FGLRX X server crashes on a different machine /
> setup though.
I completely agree with you. I tried to modify a lot of parameters in the xorg.conf
file. Unfortunately no adjustment made the X-server survive.

I'm switching to "radeon" instead of "fglrx" driver, having a stable system again.
Comment 26 Benoit Girard (:BenWa) 2011-10-07 13:08:05 PDT
Confirmed once. This needs to be confirmed on more machines before blacklisting GLRX. See comment 24
Comment 27 martin.vogt 2012-08-13 06:10:44 PDT
Hello,

I can reproduce this too, but only in case of indirect rendering.
(local works here)
I have attached a modified glxtest.cpp which does not crash if
the glXMakeCurrent is replaced with a window instead of a glxpixmap.      

So glxtest does not crash, but the bug that glXMakeCurrent
will crash xorg in the indirect case, when used with
GLXPixmap is not solved at all.

I will do a bugreport for fglrx for this. (http://ati.cchtml.com/)   

Additionally I upload a .tgz which demonstrate the crash with
indirect rendering.

regards,

Martin
Comment 28 martin.vogt 2012-08-13 06:12:44 PDT
Created attachment 651343 [details]
modified glxtest (will still crash)
Comment 29 martin.vogt 2012-08-13 06:14:57 PDT
Created attachment 651344 [details] [diff] [review]
replace GLXPixmap with window does not crash
Comment 30 martin.vogt 2012-08-13 06:17:06 PDT
Created attachment 651346 [details]
demo for crash in indirect case (includes mesa libGL)
Comment 31 Benoit Jacob [:bjacob] (mostly away) 2012-08-13 06:20:50 PDT
Yup, replacing the GLXPixmap by a XWindow is the right approach. Please make a cleaned up patch, set review? bjacob and I'll review it!
Comment 32 Benoit Jacob [:bjacob] (mostly away) 2012-08-13 06:21:24 PDT
Also note that you will be able to remove the GLX 1.3 requirement in GLXtest as it was only needed for GLXPixmaps.
Comment 33 martin.vogt 2012-08-13 06:54:12 PDT
The crash for the indirect case is reported 
in the Unofficial AMD Linux Bugzilla:

http://ati.cchtml.com/show_bug.cgi?id=585

Should the diff be against glxtest.cpp in toolkit/xre/ ?
Comment 34 martin.vogt 2012-08-14 05:03:07 PDT
Ok, I made the patch against toolkit/xre for ff10 and the current version.
I have tested the ff10 version, which is in SLES10, and the xorg server
crashes do not occur anymore, so this should be solved.

I have not compiled the other version of the patch, but is applies...
Comment 35 martin.vogt 2012-08-14 05:04:40 PDT
Created attachment 651699 [details] [diff] [review]
for ff 10
Comment 36 martin.vogt 2012-08-14 05:05:29 PDT
Created attachment 651701 [details] [diff] [review]
for current checkout (ff14)
Comment 37 Benoit Jacob [:bjacob] (mostly away) 2012-08-14 06:07:58 PDT
Comment on attachment 651701 [details] [diff] [review]
for current checkout (ff14)

Setting review? :bjacob ensures that I can't forget about it.
Comment 38 Benoit Jacob [:bjacob] (mostly away) 2012-08-14 06:13:42 PDT
Comment on attachment 651701 [details] [diff] [review]
for current checkout (ff14)

Review of attachment 651701 [details] [diff] [review]:
-----------------------------------------------------------------

Almost! Please make the minor adjustments described below:

::: src.org//toolkit/xre/glxtest.cpp
@@ +171,5 @@
> +  swa.colormap = XCreateColormap(dpy, RootWindow(dpy, vInfo->screen),
> +                                 vInfo->visual, AllocNone);
> +  swa.border_pixel = 0;
> +  win1 = XCreateWindow(dpy, RootWindow(dpy, vInfo->screen),
> +                       10, 10, 200, 200,

Please use a smaller size (and check that it still doesn't crash) to avoid needless memory usage. I would use 16x16, a good compromise between small and avoiding corner cases with extremely small sizes.

@@ +208,3 @@
>    ///// possible. Also we want to check that we're able to do that too without generating X errors.
>    glXMakeCurrent(dpy, None, NULL); // must release the GL context before destroying it
>    glXDestroyContext(dpy, context);

Please explicitly destroy the window -- even though the XCloseDisplay below should, I guess, do it.
Comment 39 Benoit Jacob [:bjacob] (mostly away) 2012-08-14 06:15:18 PDT
Comment on attachment 651699 [details] [diff] [review]
for ff 10

Let's first land this on mozilla-central, then backport.
Comment 40 martin.vogt 2012-08-17 02:42:09 PDT
Created attachment 652708 [details] [diff] [review]
patch for ff10 V2

Changes as suggested by Benoit Jacob
Comment 41 martin.vogt 2012-08-17 02:43:15 PDT
Created attachment 652709 [details] [diff] [review]
patch for ff14 V2

Changes as suggested by Benoit Jacob
Comment 42 martin.vogt 2012-08-17 02:45:32 PDT
Created attachment 652710 [details] [diff] [review]
improvement for ff10 V2, which works on nvidia in the remote case too.

Changes as suggested by Benoit Jacob
+ remove the attribs.

On Nvidia in the indirect case (remote PC) the glxtest.cpp aborts
with No FBConfigs found. With this patch it works.
Comment 43 martin.vogt 2012-08-17 02:46:49 PDT
Created attachment 652711 [details] [diff] [review]
improvement for ff14 V2, which works on nvidia in the remote case too.

Changes as suggested by Benoit Jacob
+ remove the attribs.

On Nvidia in the indirect case (remote PC) the glxtest.cpp aborts
with No FBConfigs found. With this patch it works.
Comment 44 Benoit Jacob [:bjacob] (mostly away) 2012-08-22 09:10:10 PDT
Comment on attachment 652711 [details] [diff] [review]
improvement for ff14 V2, which works on nvidia in the remote case too.

Thanks! Again: without the 'review' flag (under 'details') I too easily forget about your patch. And we will only want to take this patch on mozilla-central, perhaps mozilla-aurora -- not beta/release/esr.
Comment 45 Benoit Jacob [:bjacob] (mostly away) 2012-08-22 09:12:45 PDT
Comment on attachment 652711 [details] [diff] [review]
improvement for ff14 V2, which works on nvidia in the remote case too.

Review of attachment 652711 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, thanks!
Comment 46 Benoit Jacob [:bjacob] (mostly away) 2012-08-22 20:21:52 PDT
https://tbpl.mozilla.org/?tree=Try&rev=b96864829813
Comment 47 Benoit Jacob [:bjacob] (mostly away) 2012-08-23 11:54:42 PDT
That's weird, TBPL reports a memory leak that reproduced with this patch alone.

Here's a try explicitly destroying the Colormap:
https://tbpl.mozilla.org/?tree=Try&rev=a38843ce365c
Comment 48 Benoit Jacob [:bjacob] (mostly away) 2012-08-24 11:38:28 PDT
Still that weird leak, which I can only interprete as a crash, maybe due to antique drivers on the test slave. new try with debug output:

https://tbpl.mozilla.org/?tree=Try&rev=a324307b7f42
Comment 49 Benoit Jacob [:bjacob] (mostly away) 2012-08-24 15:04:50 PDT
glxtest g
X connection to :2.0 broken (explicit kill or server shutdown).

Ouch. This means that GL context creation makes the X server crash, on our test machines with NVIDIA 190.42 driver.
Comment 50 Benoit Jacob [:bjacob] (mostly away) 2012-08-24 17:47:56 PDT
I modified the code around here to be closer to what glxinfo does... hopefully it won't crash the X server anymore...https://tbpl.mozilla.org/?tree=Try&rev=f7b3ae88c99f
Comment 51 martin.vogt 2012-08-27 00:30:07 PDT
When I did the patch, I tought about:

glXCreateContext(Display*  dpy,XVisualInfo*  vis,GLXContext  shareList,Bool  direct);

and from the manpage:
>http://www.opengl.org/sdk/docs/man/xhtml/glXCreateContext.xml
>Notes:It may not be possible to render to a GLX pixmap with a direct rendering 
>      context.

OpenGL supports the call:glXIsDirect()

But I havent found it in the exported symbols in libGL.
So if this call can be loaded with dlsym, it should be possible to work
around the note from glxCreateContext.
Btw: I tested with Nvidia 295.71 and fglrx 12.4..
Comment 52 Benoit Jacob [:bjacob] (mostly away) 2012-08-27 06:41:48 PDT
New try (previous one failed to compile):
https://tbpl.mozilla.org/?tree=Try&rev=feccc1c0eb5f

This one is as close as possible to what the traditional |glxinfo| program does:
http://cvsweb.xfree86.org/cvsweb/xc/programs/glxinfo/glxinfo.c?rev=HEAD&content-type=text/vnd.viewcvs-markup

In particular it uses glXCreateContext.

These functions are not usual symbols in the sense of dlsym, that's why we have to use glXGetProcAddress.

Also, I figured what's happening here, making this fail only on 'B' (build phase) on our try servers: the B tests run on the build machines, not on the test machines. So the X crash here is specific to whatever driver is on the build machines. The NVIDIA driver I was referring to above was on the test machines.
Comment 53 Benoit Jacob [:bjacob] (mostly away) 2012-08-27 08:04:30 PDT
Green!
Comment 54 Benoit Jacob [:bjacob] (mostly away) 2012-08-27 08:17:34 PDT
Created attachment 655594 [details] [diff] [review]
imitate what glxinfo does to avoid crashing the X server on the build slaves

See above comments. While Martin's patch was fine, it crashes the X server on the build slaves (not on the test slaves). To end these issues, the simplest seemed to be to imitate glxinfo as much as possible; that works.
Comment 55 Benoit Jacob [:bjacob] (mostly away) 2012-08-27 08:18:08 PDT
Note that this patch applies on top of Martin's, whence the new code in the context lines.
Comment 56 Karl Tomlinson (:karlt) 2012-08-27 18:49:59 PDT
(In reply to Benoit Jacob [:bjacob] from comment #52)
> In particular it uses glXCreateContext.

http://www.opengl.org/sdk/docs/man/xhtml/glXCreateNewContext.xml says
"This context can be used to render into GLX windows, pixmaps, or pixel buffers."
while http://www.opengl.org/sdk/docs/man/xhtml/glXCreateContext.xml says
"This context can be used to render into both windows and GLX pixmaps."

Maybe the driver was expecting a GLXWindow instead of a Window, or maybe I'm reading too much into that difference as perhaps there was no such thing as a GLX window when glxCreateContext documentation was written.
Comment 57 Karl Tomlinson (:karlt) 2012-08-27 18:59:43 PDT
Comment on attachment 655594 [details] [diff] [review]
imitate what glxinfo does to avoid crashing the X server on the build slaves

It's a shame that glxtest is behaving less like the core Gecko code, and so it is not so much testing what we want to test.

However, there may be no other options, given we want to avoid crashing servers.
Bug 772446 should mean we soon no longer need to care about CentOS 5, but I guess there may be other systems out there.
Comment 58 Benoit Jacob [:bjacob] (mostly away) 2012-08-28 11:17:57 PDT
(In reply to Karl Tomlinson (:karlt) from comment #57)
> Comment on attachment 655594 [details] [diff] [review]
> imitate what glxinfo does to avoid crashing the X server on the build slaves
> 
> It's a shame that glxtest is behaving less like the core Gecko code, and so
> it is not so much testing what we want to test.

I had thought and worried about that in the past, and was tempted to make glxtest actually test whatever we end up doing in libxul to detect any issues, but I backed out from that approach as it would have only been scalable if glxtest itself could call into libxul GLContext stuff, but that would have pulled a lot of dependencies that would have meant that glxtest had to run much later during startup, risking delaying startup.

So the approach that we had already been following here was to keep glxtest minimal and just query GL strings. Nothing new here.
Comment 59 Benoit Jacob [:bjacob] (mostly away) 2012-08-28 11:19:32 PDT
Oh yes, and running glxtest later during startup would also complicate things: we'd have to manually turn off the crash reporter, etc.
Comment 61 Benoit Jacob [:bjacob] (mostly away) 2012-08-28 12:46:39 PDT
Comment on attachment 652711 [details] [diff] [review]
improvement for ff14 V2, which works on nvidia in the remote case too.


[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 639842 (Firefox 6)
User impact if declined: a small percentage of linux users can't use Firefox at all, as it crashes their X server immediately on startup
Testing completed (on m-c, etc.): m-i
Risk to taking this patch (and alternatives if risky): non risky. Of course, as we  noted here, any change here can always run into a different driver crash, but at least, the new code is very close to the traditional glxinfo program.
String or UUID changes made by this patch: none
Comment 62 Benoit Jacob [:bjacob] (mostly away) 2012-08-28 12:47:06 PDT
Comment on attachment 655594 [details] [diff] [review]
imitate what glxinfo does to avoid crashing the X server on the build slaves

[Approval Request Comment]
See previous comment.
Comment 64 Lukas Blakk [:lsblakk] use ?needinfo 2012-08-29 15:15:24 PDT
Comment on attachment 655594 [details] [diff] [review]
imitate what glxinfo does to avoid crashing the X server on the build slaves

Since it's very early in the cycle, and the fix is low risk, we can take this for uplift.
Comment 66 Virgil Dicu [:virgil] [QA] 2012-11-09 06:25:04 PST
Is there something I could do here to verify this is fixed? Ubuntu and Fedora systems available. 

Or any issues I should look for on Linux?
Comment 67 Karl Tomlinson (:karlt) 2012-11-12 18:05:41 PST
(In reply to Virgil Dicu [:virgil] [QA] from comment #66)
> Is there something I could do here to verify this is fixed? Ubuntu and
> Fedora systems available. 
> 
> Or any issues I should look for on Linux?

I suspect this may be difficult to verify as it requires specific hardware (ATI) and driver (Catalyst) on the server machine, and a remote connection (perhaps ssh -Y from the same machine).

Check that this doesn't cause bug 799544 on an older system with Mesa (open source, any hardware) drivers and LIBGL_ALWAYS_SOFTWARE=1 in the environment.
Comment 68 Virgil Dicu [:virgil] [QA] 2012-11-14 06:23:55 PST
>(In reply to Karl Tomlinson (:karlt) from comment #67) 
> Check that this doesn't cause bug 799544 on an older system with Mesa (open
> source, any hardware) drivers and LIBGL_ALWAYS_SOFTWARE=1 in the environment.

Ok, verified this on the systems I currently have access to with the following drivers on Firefox 17 beta5:

nouveau -- Gallium 0.4 on NV98 -- 2.1 Mesa 8.0.2 (Ubuntu 12.04)
X.org--Gallium 0.4 on AMD RS780 -- 2.1 Mesa 8.0.2 (Fedora 17)

No crashes when loading about:support.

I think this is all I can do here with my current hardware. If there is anything left to do, re-set the flag, please.
Comment 69 Virgil Dicu [:virgil] [QA] 2012-11-28 07:33:51 PST
Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/18.0 Firefox/18.0

Same result as in comment 68 on Ubuntu and Fedora. Firefox 18 beta 1.
Comment 70 Tracy Walker [:tracy] 2014-01-10 10:41:30 PST
mass remove verifyme requests greater than 4 months old

Note You need to log in before you can comment on or make changes to this bug.