Bug 440340 - X colourmap is mistakenly free for shared foreign GdkColormap objects
X colourmap is mistakenly free for shared foreign GdkColormap objects
Product: Fedora
Classification: Fedora
Component: gtk2 (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
: Reopened
: 431239 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2008-04-02 17:52 EDT by Daniel Berrange
Modified: 2008-05-28 22:47 EDT (History)
5 users (show)

See Also:
Fixed In Version: 2.12.8-2.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-28 22:47:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Prevent X colormap being free'd when created via gdk_x11_colormap_foreign_new (1.00 KB, patch)
2008-04-02 22:28 EDT, Daniel Berrange
no flags Details | Diff
xrestop capture while running glxgears (2.89 KB, text/plain)
2008-05-05 18:15 EDT, Frank Arnold
no flags Details
screenshot showing the corruptions (167.00 KB, image/png)
2008-05-05 18:16 EDT, Frank Arnold
no flags Details

  None (edit)
Description Daniel Berrange 2008-04-02 17:52:32 EDT
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):

How reproducible:

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,

  GdkGLConfig *gl_config;

  gtk_init(&argc, &argv);

  gl_config = gdk_gl_config_new(attrib);

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
#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
#5  0x0000000000400975 in main (argc=1, argv=0x7fff5ed85408) at cmap.c:56
Comment 1 Daniel Berrange 2008-04-02 19:39:34 EDT
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.


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
#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

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
#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

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.
Comment 2 Daniel Berrange 2008-04-02 22:28:05 EDT
Created attachment 300158 [details]
Prevent X colormap being free'd when created via gdk_x11_colormap_foreign_new
Comment 3 Daniel Berrange 2008-04-02 22:30:12 EDT
Changing subject to better reflect the underlying problem. With this patch
applied I no longer encounter the X BadColor errors.
Comment 4 Matthias Clasen 2008-04-02 22:54:47 EDT
The patch looks correct to me. Nice find, this bug has existed since 2002.
Comment 5 Bastien Nocera 2008-04-07 07:17:38 EDT
*** Bug 431239 has been marked as a duplicate of this bug. ***
Comment 6 Fedora Update System 2008-04-07 07:58:23 EDT
gtk2-2.12.8-2.fc8 has been submitted as an update for Fedora 8
Comment 7 Jonh Wendell 2008-04-10 08:41:16 EDT

Have this patch reached gtk+ upstream?
Comment 8 Jonh Wendell 2008-04-10 08:43:05 EDT
Ah, sorry, I just saw it in gtk+ Changelog.
Comment 9 Frank Arnold 2008-05-05 04:49:15 EDT
I already added some comments to

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.
Comment 10 Matthias Clasen 2008-05-05 09:43:22 EDT
Can you use xrestop to get an idea what is leaked ?
Comment 11 Matthias Clasen 2008-05-05 10:24:41 EDT
Colormaps will be counted in the "Other" column in xrestop. 
Comment 12 Frank Arnold 2008-05-05 18:13:36 EDT
(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?
Comment 13 Frank Arnold 2008-05-05 18:15:06 EDT
Created attachment 304569 [details]
xrestop capture while running glxgears
Comment 14 Frank Arnold 2008-05-05 18:16:06 EDT
Created attachment 304570 [details]
screenshot showing the corruptions
Comment 15 Bug Zapper 2008-05-14 04:36:18 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 16 Frank Arnold 2008-05-19 18:09:53 EDT
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.
Comment 17 Fedora Update System 2008-05-28 22:47:44 EDT
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.

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