Description of problem: The RGB_DEFAULT_MAP property on the root window specifies the default RGB colourmap for applications. One of the pieces of information stored in this property is the XID of a Colormap object. When you create a GdkGLConfig object, it queries this property and creates a GdkColormap object for the defautl RGB colourmap specified in this property. The problem is that GdkColourmap doesn't know this colourmap is shared systemwide. So when you call g_object_unref() on the GdkGLConfig object, it unrefs the colourmap, and thus calls XFreeColourmap, destroying the systemwide colourmap. All future GtkGLExt applications now cause an X error. Version-Release number of selected component (if applicable): gtkglext-libs-1.2.0-6.fc9.x86_64 How reproducible: Always Steps to Reproduce: 1. Create a file 'cmap.c' containing: #include <gtk/gtk.h> #include <gtk/gtkgl.h> int main(int argc, char **argv) { static const int attrib[] = { GDK_GL_RGBA, GDK_GL_RED_SIZE, 1, GDK_GL_GREEN_SIZE, 1, GDK_GL_BLUE_SIZE, 1, GDK_GL_ATTRIB_LIST_NONE }; GdkGLConfig *gl_config; gtk_init(&argc, &argv); gl_config = gdk_gl_config_new(attrib); g_object_unref(gl_config); } 2. Compile with gcc -g -o cmap `pkg-config --cflags --libs gtk+-2.0 gtkglext-1.0` cmap.c 3. Run it with --sync, eg ./cmap --sync 4. Run it a second time ./cmap --sync Actual results: The program 'cmap' received an X Window System error. This probably reflects a bug in the program. The error was 'BadColor (invalid Colormap parameter)'. (Details: serial 150 error_code 12 request_code 79 minor_code 0) (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: It runs successfully every time Additional info: GDB shows the call chain leading up to the colourmap being free'd (gdb) bt #0 XFreeColormap (dpy=0x23b9f20, cmap=188743682) at FreeCmap.c:40 #1 0x00000034aa440aab in gdk_colormap_finalize (object=Could not find the frame base for "gdk_colormap_finalize". ) at gdkcolor-x11.c:111 #2 0x0000000000afe6a8 in IA__g_object_unref (_object=<value optimized out>) at gobject.c:1793 #3 0x00000034a9c46306 in gdk_gl_config_impl_x11_finalize (object=<value optimized out>) at gdkglconfig-x11.c:99 #4 0x0000000000afe6a8 in IA__g_object_unref (_object=<value optimized out>) at gobject.c:1793 #5 0x0000000000400975 in main (argc=1, argv=0x7fff5ed85408) at cmap.c:56
After further debugging, this looks like a GTK bug to me If you run the demo program under GDB, and put a break point on 'gdk_x11_colormap_foreign_new' and 'XFreeColormap' you can see both getting called. The API contract for gdk_x11_colormap_foreign_new() is quite explicit that XFreeColurmap will *not* be called for GdkColormap objects created via this API. http://library.gnome.org/devel/gdk/stable/gdk-X-Window-System-Interaction.html#gdk-x11-colormap-foreign-new The stack traces confirm GTK is violating the API contract Breakpoint 3, 0x0624a457 in IA__gdk_x11_colormap_foreign_new (visual=0x83a01a0, xcolormap=92274689) at gdkcolor-x11.c:1269 1269 { (gdb) bt #0 0x0624a457 in IA__gdk_x11_colormap_foreign_new (visual=0x83a01a0, xcolormap=92274689) at gdkcolor-x11.c:1269 #1 0x0044872d in gdk_gl_config_setup_colormap (screen=0x839f0d0, xvinfo=0x83a6e18, is_rgba=<value optimized out>, is_mesa_glx=0) at gdkglconfig-x11.c:227 #2 0x00448f4d in gdk_gl_config_new_common (screen=0x839f0d0, attrib_list=<value optimized out>) at gdkglconfig-x11.c:554 #3 0x08048740 in main (argc=Cannot access memory at address 0xe0002 ) at cm.c:16 (gdb) cont Continuing. Breakpoint 4, XFreeColormap (dpy=0x8393900, cmap=92274689) at FreeCmap.c:43 43 LockDisplay(dpy); (gdb) bt #0 XFreeColormap (dpy=0x8393900, cmap=92274689) at FreeCmap.c:43 #1 0x062475e9 in gdk_colormap_finalize (object=0x83a0c58) at gdkcolor-x11.c:111 #2 0x008ab2ec in g_object_unref () from /lib/libgobject-2.0.so.0 #3 0x004490f0 in gdk_gl_config_impl_x11_finalize (object=0x83a9218) at gdkglconfig-x11.c:99 #4 0x008ab2ec in g_object_unref () from /lib/libgobject-2.0.so.0 #5 0x0804874e in main (argc=Cannot access memory at address 0xe0002 ) at cm.c:17 The doesn't appear to be any special handling of GdkColourmaps created via gtk_x11_colourmap_foreign_new() at all - the finalizer unconditionally calls XFreeColormap. Funnily enough struct _GdkColormapPrivateX11 does have a bitfield 'guint foreign : 1' for tracking this, but it is never initialized, nor checked in any of the code AFAICT.
Created attachment 300158 [details] Prevent X colormap being free'd when created via gdk_x11_colormap_foreign_new
Changing subject to better reflect the underlying problem. With this patch applied I no longer encounter the X BadColor errors.
The patch looks correct to me. Nice find, this bug has existed since 2002.
*** Bug 431239 has been marked as a duplicate of this bug. ***
gtk2-2.12.8-2.fc8 has been submitted as an update for Fedora 8
Hi. Have this patch reached gtk+ upstream?
Ah, sorry, I just saw it in gtk+ Changelog.
I already added some comments to https://admin.fedoraproject.org/updates/F8/FEDORA-2008-2893 Basically, what I'm seeing after some time of running gtk2-2.12.8-2.fc8 is that there's not enough video memory available anymore to allocate some offscreen area. Instead it draws directly to the visible area sometimes. I'm seeing this especially while running some GL apps in fullscreen or maximized window mode. When this happens I get the following log message in Xorg.0.log: (EE) RADEON(0): Unable to reserve offscreen area for depth buffer and textures, you might experience screen corruption On a second thought I came to the conclusion that it might be possible that this change causes some leaking of colormaps.
Can you use xrestop to get an idea what is leaked ?
Colormaps will be counted in the "Other" column in xrestop.
(In reply to comment #10) > Can you use xrestop to get an idea what is leaked ? Doesn't look like it's leaking. Most of the resources are used by Firefox. I'm a bit lost in what's happening here. The card should be sufficient enough to handle the resources listed there (RV280, 256MB VRAM). I'll attach a capture of xrestop and a screenshot showing the corruptions. Any suggestion what to do next, perhaps filing a bug against xorg-x11-drv-ati?
Created attachment 304569 [details] xrestop capture while running glxgears
Created attachment 304570 [details] screenshot showing the corruptions
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Some news on this one: The background corruptions are not caused by the patch that fixes this issue. Instead some change between 2.12.5 and 2.12.8 is causing them. I downgraded to 2.12.5-2 and let it run with more or less heavy usage (lots of Firefox tabs, different GL apps) without any glitches for 13 days. Today I upgraded to a local rebuild of 2.12.8-1 and the corruptions just came back again.
gtk2-2.12.8-2.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.