GNOME Bugzilla – Bug 640680
crash on startup (due to missing glx?)
Last modified: 2011-03-01 16:58:14 UTC
Hi in my jhbuild environment, if I run a gnome-session with gnome-shell as WM in a Xephyr window (that, I presume, has no glx stuff) I get Failed to start shell Traceback (most recent call last):
+ Trace 225711
normal_exit = run_shell()
shell = start_shell(perf_output=perf_output)
(server_glx_extensions, client_glx_extensions, glx_extensions) = _get_glx_extensions()
server_glx_extensions = set(re.split("\s*,\s*", glxinfo_map['server glx extensions'].strip()))
This is from git master as of today. I suggest to catch the error and to display an error message instead
Just got a bug about this in openSUSE. Apparently, glxinfo can fail in an interesting way, which explains this error: name of display: :0 X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 138 (NV-GLX) Minor opcode of failed request: 4 () Resource id in failed request: 0x4a00002 Serial number of failed request: 30 Current serial number in output stream: 30 So we should probably be a bit more robust there. I'm not sure what's best: should we just silently ignore this case, or should we just consider this as a sign that gnome-shell won't run?
We're discussing in bug 642084 dropping the glxinfo check - it's really there to support DRI1, which is very marginally useful. If we weren't dropping it, then the fix is pretty clear - we need to check the return value of glxinfo. Presumably in the gnome-session case, gnome-session-is-accelerated dies with the same error message?
(In reply to comment #2) > We're discussing in bug 642084 dropping the glxinfo check - it's really there > to support DRI1, which is very marginally useful. If we weren't dropping it, > then the fix is pretty clear - we need to check the return value of glxinfo. Dropping it makes sense, I guess. > Presumably in the gnome-session case, gnome-session-is-accelerated dies with > the same error message? I don't have the hardware, but I guess it dies in a similar way. Christian, can you test this? It's installed in $libexecdir.
Created attachment 181185 [details] [review] Check return value of glxinfo It's probably not going to be used, since the code will most likely be removed, but that's the trivial patch that can be used if the code stays.
Hi what I actually get is a segmentation fault for a Xephyr window gnome@rivendell:~$ LANG=C glxinfo name of display: :1.0 Speicherzugriffsfehler I have a broken GNOME test environment at the moment, hence I am afraid I cannot test the patch at this time.
We ended up removing the code that execs glxinfo.