Bug 479140 - Bluecurve gtk-2 engine causes a BadMatch when rendering radio/check buttons in multiscreen
Bluecurve gtk-2 engine causes a BadMatch when rendering radio/check buttons i...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: redhat-artwork (Show other bugs)
4.6
All Linux
low Severity medium
: rc
: ---
Assigned To: Behdad Esfahbod
desktop-bugs@redhat.com
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-07 09:55 EST by Olivier Fourdan
Modified: 2013-03-03 21:47 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
* when gdk_draw_pixmap() styled radio buttons, it called gdk_pixbuf_render_pixmap_and_mask(), which is not multihead aware. Consequently, rendering radio buttons on multiple independent screens (that is, screens not using xinerama) would cause a BadMatch error and crash the X server. Gdk_draw_pixmap() now calls gdk_pixbuf_render_pixmap_and_mask_for_colormap() instead, taking the colormap from the style. This produces a bitmap for the correct screen and avoids the BadMatch error and X server crash.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-18 16:33:11 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)
Reproducer program (1.41 KB, application/x-bzip)
2009-01-07 09:55 EST, Olivier Fourdan
no flags Details
Proposed patch (1.12 KB, patch)
2009-01-07 10:18 EST, Olivier Fourdan
no flags Details | Diff

  None (edit)
Description Olivier Fourdan 2009-01-07 09:55:52 EST
Created attachment 328391 [details]
Reproducer program

Description of problem:

Bluecurve gtk-2 engine causes a badmatch when an application uses radio/check buttons on multiple independent (ie non xinerama) screens.

Version-Release number of selected component (if applicable):

redhat-artwork-0.120.1-2.1E

How reproducible:

100% reproducible

Steps to Reproduce:
1. Build reproducer program attached
2. Set-up a multiscreen display using Xnest
   Xnest -scrns 2 -query hostname :2
3. Log in GNOME, make sure Bluecurve engine is used and run the reproducer
  
Actual results:

This display has 2 screen(s).
Creating window for screen 0
Creating window for screen 1
The program 'radiobuttons_multiscreen' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 393 error_code 8 request_code 56 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:

This display has 2 screen(s).
Creating window for screen 0
Creating window for screen 1

Additional info:

This is _not_ a dup of bug #109172 as this happens both in EL4 (with version 0.120) and in EL5 which both contain the fix from #109172.

The problem comes fro mthe fact that the engine is using pixmaps internally to render the radio and the check buttons, pixmaps are per screen but the engine cache the pixmaps globally.

So with multi-screen, when a single application uses radio or check buttons on more than one screen, the radio/check pixmaps are rendered for one screen and reused for all screens, which fails with a BadMatch on the other screens.

The solution is to use a list of dynamically allocated pixmaps, for each screen.

Proposed patch following.
Comment 1 RHEL Product and Program Management 2009-01-07 09:57:55 EST
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 2 Olivier Fourdan 2009-01-07 10:18:48 EST
Created attachment 328393 [details]
Proposed patch

Ok, my previous explanation was wrong, sorry. Actually, there is no need to use a list of pixmaps, as the style is already per screen.

In fact the problem simply comes from the use of gdk_pixbuf_render_pixmap_and_mask() that is not multihead aware, so that crashes the Bluecurve gtk2 engine when rendering radio buttons with multihead.
 
The following patch uses gdk_pixbuf_render_pixmap_and_mask_for_colormap() instead with the colormap from the style, that will produce a bitmap for the correct screen so that gdk_draw_pixmap() does not cause a BadMatch anymore.

That makes the patch very simple.
Comment 7 Matthias Clasen 2009-01-22 10:36:54 EST
Patch looks fine to me.
Comment 10 Ruediger Landmann 2009-02-02 23:38:51 EST
Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
* when gdk_draw_pixmap() styled radio buttons, it called gdk_pixbuf_render_pixmap_and_mask(), which is not multihead aware. Consequently, rendering radio buttons on multiple independent screens (that is, screens not using xinerama) would cause a BadMatch error and crash the X server. Gdk_draw_pixmap() now calls gdk_pixbuf_render_pixmap_and_mask_for_colormap() instead, taking the colormap from the style. This produces a bitmap for the correct screen and avoids the BadMatch error and X server crash.
Comment 13 errata-xmlrpc 2009-05-18 16:33:11 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1014.html

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