Bug 190245 - OpenGL apps report GLXBadContext X error on x86_64
OpenGL apps report GLXBadContext X error on x86_64
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: mesa (Show other bugs)
5
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Adam Jackson
X/OpenGL Maintenance List
:
: 181456 185727 185929 187603 189730 (view as bug list)
Depends On:
Blocks: FC5Update
  Show dependency treegraph
 
Reported: 2006-04-29 03:06 EDT by Jens Petersen
Modified: 2008-08-02 19:40 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-03 11:59:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fix 64-bit issue for GLX (523 bytes, patch)
2006-06-17 06:04 EDT, Peter Wainwright
no flags Details | Diff
Pass correct visual pointer to XMesaCreateVisual (495 bytes, patch)
2006-06-17 06:10 EDT, Peter Wainwright
no flags Details | Diff
Fix GLXBadContext error on x86_64 (439 bytes, patch)
2006-06-17 08:43 EDT, Peter Wainwright
no flags Details | Diff

  None (edit)
Description Jens Petersen 2006-04-29 03:06:15 EDT
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
Comment 1 Jens Petersen 2006-05-17 08:32:06 EDT
Funnily enough even gnash.i386 crashes on x86_64 with GLXBadContext.
Comment 2 Ralf Corsepius 2006-05-18 00:20:09 EDT
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? 
Comment 3 Jens Petersen 2006-05-18 01:52:15 EDT
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.
Comment 4 Ralf Corsepius 2006-05-18 02:27:30 EDT
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.

Comment 5 Ralf Corsepius 2006-05-18 02:34:33 EDT
(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.
Comment 6 Jens Petersen 2006-05-18 03:53:52 EDT
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...
Comment 7 Ralf Corsepius 2006-05-18 04:17:30 EDT
(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.

Comment 8 Peter Wainwright 2006-05-20 14:43:48 EDT
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 
Comment 9 Jens Petersen 2006-06-01 01:51:49 EDT
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.
Comment 10 Jens Petersen 2006-06-01 22:51:48 EDT
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.
Comment 11 Mike A. Harris 2006-06-14 11:16:25 EDT
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.

Comment 12 Mike A. Harris 2006-06-14 11:17:02 EDT
------- Additional Comments From redhat@muzik.ca  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@sunspirestudios.com>
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
Comment 13 Mike A. Harris 2006-06-14 11:17:32 EDT
------- Additional Comments From petersen@redhat.com  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?
Comment 14 Peter Wainwright 2006-06-17 06:02:56 EDT
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).

Comment 15 Peter Wainwright 2006-06-17 06:04:25 EDT
Created attachment 131092 [details]
Fix 64-bit issue for GLX
Comment 16 Peter Wainwright 2006-06-17 06:10:26 EDT
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?
Comment 17 Peter Wainwright 2006-06-17 08:43:10 EDT
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?)
Comment 18 Mike A. Harris 2006-06-26 07:50:25 EDT
*** Bug 185929 has been marked as a duplicate of this bug. ***
Comment 19 Mike A. Harris 2006-06-26 07:51:14 EDT
*** Bug 187603 has been marked as a duplicate of this bug. ***
Comment 20 Mike A. Harris 2006-06-26 07:52:36 EDT
*** Bug 185727 has been marked as a duplicate of this bug. ***
Comment 21 Mike A. Harris 2006-06-26 07:55:35 EDT
*** Bug 189730 has been marked as a duplicate of this bug. ***
Comment 22 Fedora Update System 2006-06-26 19:03:58 EDT
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.
Comment 23 Mike A. Harris 2006-06-27 08:32:06 EDT
*** Bug 185929 has been marked as a duplicate of this bug. ***
Comment 24 Mike A. Harris 2006-06-27 08:54:12 EDT
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...
Comment 25 Mike A. Harris 2006-06-27 13:48:04 EDT
*** Bug 181456 has been marked as a duplicate of this bug. ***
Comment 26 Mike A. Harris 2006-06-28 09:45:20 EDT
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
Comment 27 Fedora Update System 2006-06-28 09:48:13 EDT
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.
Comment 28 Fedora Update System 2006-06-28 09:50:54 EDT
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.
Comment 29 Fedora Update System 2006-06-30 16:07:18 EDT
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.
Comment 30 Matěj Cepl 2007-07-03 09:50:29 EDT
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.
Comment 31 Peter Wainwright 2007-07-03 10:56:02 EDT
The Mesa and Xorg update discussed above fixed it for me.
I'd mark it CLOSED unless anyone else still has problems.
Comment 32 Matěj Cepl 2007-07-03 11:59:20 EDT
Thanks a lot. Closing per reporter's request.

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