Description of problem: If one tries to run any of the examples included with gtkglext or any another program linked to it on x86_64, the program crashes. Version-Release number of selected component (if applicable): gtkglext-1.2.0-2.fc5.x86_64 How reproducible: every time Steps to Reproduce: $ rpmbuild -bc gtkglext.spec $ cd gtkglext-1.2.0/examples $ make $ ./button --sync Actual results: The program 'lt-button' received an X Window System error. This probably reflects a bug in the program. The error was 'GLXBadContext'. (Details: serial 258 error_code 154 request_code 143 minor_code 5) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Expected results: No X error. Additional info: Here is a gdb backtrace from a more real-world application, gnash: #0 gdk_x_error (display=0x521fd0, error=0x7fffff962070) at gdkmain-x11.c:598 #1 0x00000038d77498e6 in _XError () from /usr/lib64/libX11.so.6 #2 0x00000038d774b539 in _XReply () from /usr/lib64/libX11.so.6 #3 0x00000038e0b2ed9b in __glXInitialize () from /usr/lib64/libGL.so.1 #4 0x00000038e0b2f0f0 in glXMakeCurrentReadSGI () from /usr/lib64/libGL.so.1 #5 0x00000038e0b2f392 in glXMakeCurrent () from /usr/lib64/libGL.so.1 #6 0x0000003981042fc5 in gdk_gl_window_impl_x11_make_context_current ( draw=0x50e880, read=Variable "read" is not available. ) at gdkglwindow-x11.c:250 #7 0x00002aaaaaadb90c in configure_event (widget=0x5504b0, event=0x550670, data=Variable "data" is not available. ) at gtksup.cpp:369 #8 0x0000003151e23c9d in _gtk_marshal_BOOLEAN__BOXED (closure=0x56d890, return_value=0x7fffff9624b0, n_param_values=Variable "n_param_values" is not available. ) at gtkmarshalers.c:83 #9 0x000000315130b21b in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #10 0x000000315131af38 in g_signal_override_class_closure () from /usr/lib64/libgobject-2.0.so.0 #11 0x000000315131c14d in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #12 0x000000315131c563 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #13 0x0000003151efdd3e in gtk_widget_event_internal (widget=0x5504b0, event=0x550670) at gtkwidget.c:3751 #14 0x0000003151db51b4 in gtk_drawing_area_send_configure (darea=0x5504b0) at gtkdrawingarea.c:170 #15 0x0000003151db535c in gtk_drawing_area_realize (widget=0x5504b0) at gtkdrawingarea.c:133 #16 0x000000315130b21b in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #17 0x000000315131b37d in g_signal_override_class_closure () from /usr/lib64/libgobject-2.0.so.0 #18 0x000000315131c383 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #19 0x000000315131c563 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #20 0x0000003151f0407f in IA__gtk_widget_realize (widget=0x5504b0) at gtkwidget.c:2339 #21 0x0000003151f045de in IA__gtk_widget_set_parent (widget=0x5504b0, parent=0x54c020) at gtkwidget.c:4532 #22 0x0000003151d6510d in gtk_bin_add (container=0x54c020, child=0x5504b0) at gtkbin.c:129 #23 0x000000315130b21b in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #24 0x000000315131b37d in g_signal_override_class_closure () from /usr/lib64/libgobject-2.0.so.0 #25 0x000000315131c383 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #26 0x000000315131c563 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #27 0x00000000004045fd in main (argc=2, argv=0x7fffff963818) at gnash.cpp:538
Funnily enough even gnash.i386 crashes on x86_64 with GLXBadContext.
Jens, I don't have access to x86_64-machines, nor can I reproduce your problem with FC4 nor FC5 on i386, nor does gnash look compelling to me. Are you able to deterministically produce a traceback with "button" or any other example from GtkGlExt/examples?
All the gtkglext demos including glxinfo crash immediately on startup for me. It is 100% reproducible. However the fact that 32bit apps crash too makes me wonder if it may be an X/hardware related issue.
Does(In reply to comment #3) > All the gtkglext demos including glxinfo crash immediately on startup for me. > It is 100% reproducible. However the fact that 32bit apps crash too > makes me wonder if it may be an X/hardware related issue. Not unlikely - A minimal check would be running glxgears. Does it run? Another rather frequent issue with GL apps is them being rather "sloppy" on detecting usable visuals. Some of the gtkglext examples are known to suffer from this issue (They typically fail if glx/gl doesn't provide a certain feature, e.g. 24bit visuals.) A more real world check would be running one of the apps from the Inventor rpm (e.g. SceneViewer). These are more elaborated (ancient code) than gtkglext and have been developed on 64bit platforms.
(In reply to comment #3) > All the gtkglext demos including glxinfo crash immediately on startup for me. Oops, I missed "glxinfo" ... then you definitely have a HW, GL/glx installation problem, or an X server config problem.
Is there a faq or wiki page say somewhere that describes how to track down the problem? I'm pretty sure it was working with FC4. (I'm using the xorg-x11 nvi driver fwiw.) Not sure whether to move this to kernel or xorg-x11...
(In reply to comment #6) > Is there a faq or wiki page say somewhere that describes how to > track down the problem? Hmm, I am sure there are many, but ... it's been a long time, since I had been facing low level GL/GLx issues, so I am not aware of any. Normally, the first step is to check if libGL* are correctly installed (Using the nvidia-installer breaks them terribly). Subsequent step would be to check /etc/X11/xorg.conf ('Load "glx"' in Modules, dri?). Afterwards, restart/start "X" and check "/var/log/X.*log". You should see a message referring to loading "glx". Next step would be to run glxinfo and xdpyinfo in a terminal and to check their results. If they appear to work, running glxgears would be an initial test to verify if gl is working. > I'm pretty sure it was working with FC4. > (I'm using the xorg-x11 nvi driver fwiw.) nvi? This doesn't tell me much. I know about the nv and nvidia drivers. (I am using livna's nvidia drivers ;) ) > Not sure whether to move > this to kernel or xorg-x11... Depends, if you're sure your issue is gtkglext related the gtkglext list would be appropriate. Otherwise, one of the fedora lists also might be useful.
I have the same error (GLXBadContext), with an HP laptop (AMD Turion 64, ATI Radeon XPRESS 200M as reported by lspci). I am using the same homebake kernel (2.6.16.16) which worked OK for me with FC4. I can get the "radeon" driver to work with FC5, which was not the case before (I used either plain old "vesa" or the ATI "fglrx"). However, the error messages from Xorg.log.0 show drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) ... (II) RADEON(0): [drm] drmOpen failed (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. and so on: In fact the /dev/dri directory is empty even though the radeon and drm kernel modules are loaded. Then I get [root@ceiriog Mesa-5.0.1]# LIBGL_DEBUG=1 glxgears libGL error: XF86DRIQueryDirectRenderingCapable returned false X Error of failed request: GLXBadContext So firstly, why does the radeon kernel driver not create the /dev/dri entries (even though I have not changed the kernel)? and secondly, why does not Xorg advertise the GLX extension (via xdpyinfo) when it is in fact unusable? when it is
Yep, I meant the nv driver, sorry. mesa-libGL seems to be installed fine. My xorg.conf has both glx and dri modules listed, and libglx.o loads ok in the log. Actually I get the error even for a freeglut program. So this is definitely not a gtkglext bug. Reassigning to xorg-x11.
After installing rawhide on my x86_64 testbox (ATI Radeon Xpress 200G) glxinfo and glxgears run just fine now. So this definitely seems FC5 specific.
Our bugzilla database had a catastrophic failure on June 13, 2006 which lost all bug changes from Thurs June 9th through 13th. I have bugzilla email records of the time period however, and will be restoring as many changes as I can manually.
------- Additional Comments From redhat 2006-06-13 00:56 EST ------- I have the same problem on my FC5 x86_64 box with anything that uses GL (Wine, Tuxracer, and some OpenGL programming I did for a class). Looking through the list of possible things to do: Yes my xorg.conf has glx and dri listed in the module section, and yes, they load correctly. My compiled code runs(ran) fine on FC4, but in the upgrade to FC5 it stopped working. My system information (let me know if you want full conf files or log files, but I dont see any point to contributing them as this seems to be exactly the same problem as everyone else) Video Card: nVidia Corporation NV17 [GeForce4 MX 440] Using drivers: nv (included with fc5) kernel version: 2.6.15-1.2054_FC5 (older version... upgrading versions is a hassle to re-compile some of my kernel modules..which I will do soon!) Exact error: (my simple 'hello world' type opengl application): freeglut (./a.out): Unable to create direct context rendering for window 'Checkers' This may hurt performance. X Error of failed request: GLXBadContext Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 29 Current serial number in output stream: 29 (Planet Penguin Racer): PPRacer 0.3.1 -- http://racer.planetpenguin.de (c) 2004-2005 The PPRacer team (c) 1999-2001 Jasmin F. Patry<jfpatry> PPRacer comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See http://www.gnu.org/copyleft/gpl.html for details. X Error of failed request: GLXBadContext Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 19 Current serial number in output stream: 19 (Wine): err:xrandr:X11DRV_XRandR_GetCurrentMode In unknown mode, returning default X Error of failed request: GLXBadContext Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 164 Current serial number in output stream: 164
------- Additional Comments From petersen 2006-06-13 02:43 EST ------- The most useful thing now would be to work out if this is a kernel or xorg-x11 issue? Just upgrading fc4 to modular X is hard, but maybe the fc5 kernel can be installed in fc4?
The problem is a misalignment of the entries in a struct _Visual between Xorg and Mesa due to a discrepancy in their idea of the size of a VisualID. You need to make sure _XSERVER64 is set before X.h is included, because unsigned long is 64, not 32 bits. This requires modification to the mesa_source code. It looks like this has already been done in the Rawhide version (6.5). But before looking at this, I had already fixed the problem with this patch. Actually, this should be applied to the the mesa_source package instead (since xm_api.c is actually just a symlink).
Created attachment 131092 [details] Fix 64-bit issue for GLX
Created attachment 131093 [details] Pass correct visual pointer to XMesaCreateVisual While tracking down this bug, I came across this. I think this is probably right?
Created attachment 131096 [details] Fix GLXBadContext error on x86_64 This patch includes "dix-config.h" in "glheader.h" (my previous effort put it in "glxheader.h", which worked too, but I notice the rawhide version puts it here instead). If you want to do this by hand and not wait for the official bug fix: It needs to be applied to the mesa-6.4.2-6.src.rpm and compiled. (i.e. add the appropriate PatchXXX and %patchXXX lines in the spec file). The resulting rpm mesa-source-6.4.2-6.x86_64.rpm needs to be installed. Then the xorg-x11-xserver .src.rpm needs to be recompiled and installed. Now glxgears runs... very slowly... Unfortunately I still don't get DRI enabled on my ATI radeon, but that must be a separate issue (kernel?)
*** Bug 185929 has been marked as a duplicate of this bug. ***
*** Bug 187603 has been marked as a duplicate of this bug. ***
*** Bug 185727 has been marked as a duplicate of this bug. ***
*** Bug 189730 has been marked as a duplicate of this bug. ***
mesa-6.4.2-6.FC5.3 has been pushed for fc5, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
Additional notes: - This really is a bug in mesa. - This bug really is fixed in the new mesa. - The mesa bug, causes there to be a bug also in the X server. - The X server needs to be recompiled against the new mesa to be properly fixed. The two were intended to go out in a tandem erratum to fix this, but mesa was being released for something else also, so went out early. The X server update has lagged a bit due to unforseen buildsystem troubles which are now being resolved. So this issue wont be fully resolved until the X server update is released, at which time it should be solved for everyone. So if you are observing this problem, and still seeing it now, please wait for the X server update to be released, which should be sometime this week. Apologies for any inconveniences...
*** Bug 181456 has been marked as a duplicate of this bug. ***
The other half of the fix for this (xorg-x11-server) should be released as an update sometime today or tomorrow. Setting state to MODIFIED
xorg-x11-xtrans-devel-1.0.0-3.2.FC5.0 libX11-1.0.0-3.FC5.0 xorg-x11-server-1.0.1-9.FC5.4 xorg-x11-xdm-1.0.1-2 xorg-x11-xfs-1.0.1-4.FC5.0 xorg-x11-xinit-1.0.1-2.FC5.0 xorg-x11-apps-7.0-1 has been pushed for fc5, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
Fedora Core 5 is no longer supported, please, could you reproduce this bug with the updated version of the currently supported distribution (Fedora Core 6, or Fedora 7, or Rawhide)? If this issue turns out to still be reproducible, please let us know in this bug report. If after a month's time we have not heard back from you, we will have to close this bug as CANTFIX/INSUFFICIENT_DATA. Setting status to NEEDINFO, and awaiting information from the reporter. Thanks in advance.
The Mesa and Xorg update discussed above fixed it for me. I'd mark it CLOSED unless anyone else still has problems.
Thanks a lot. Closing per reporter's request.