Bug 474588 - gdmgreeter crashes if input device (ex wacom) is defined but not plugged
gdmgreeter crashes if input device (ex wacom) is defined but not plugged
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gdm (Show other bugs)
5.2
All Linux
medium Severity medium
: rc
: ---
Assigned To: Ray Strode [halfline]
desktop-bugs@redhat.com
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-04 10:55 EST by Olivier Fourdan
Modified: 2013-03-03 21:47 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 07:28:42 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)
Patch for current gdm-2.16 package in EL5 (2.09 KB, patch)
2008-12-04 10:55 EST, Olivier Fourdan
no flags Details | Diff
Same patch if the one from bz#473262 is applied (1.20 KB, patch)
2008-12-04 10:59 EST, Olivier Fourdan
no flags Details | Diff

  None (edit)
Description Olivier Fourdan 2008-12-04 10:55:34 EST
Created attachment 325697 [details]
Patch for current gdm-2.16 package in EL5

Description of problem:

The gdmgreeter will fail to start if a xinput device is defined in the xorg.conf but is not actually plugged in.

This happens for example when a Wacom tablet was added in xorg.conf but the device is not plugged in when gdm starts.


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

    gdm-2.16.0-46

How reproducible:

    100% reproducible

Steps to Reproduce:
1. Add devices to teh xorg.conf

        InputDevice    "stylus" "SendCoreEvents"
        InputDevice    "eraser" "SendCoreEvents"
        InputDevice    "cursor" "SendCoreEvents"

        Section "InputDevice"
                Identifier  "stylus"
                Driver      "wacom"
        ...
        EndSection
        
        Section "InputDevice"
                Identifier  "eraser"
                Driver      "wacom"
        ...
        EndSection
        
        Section "InputDevice"
                Identifier  "cursor"
                Driver      "wacom"
        ...
        EndSection

2. Do _not_ plug any additional device
3. Restart gdm
  
Actual results:

    “The greeter application appears to be crashing.
     Attempting to use a different one.”

Expected results:

The greeter is displayed correctly.

Additional info:

The problem comes from the additional modules dwellmouselistener and keymouselistener which try to open the extended devices reported by XInput without checking for errors.

In gui/modules/keymouselistener.c and gui/modules/dwellmouselistener.c, the same code is duplicated and does:


   static void
   init_xinput (GdkDisplay *display, GdkWindow *root)
   {
   ...
       devices = XListInputDevices (GDK_DISPLAY_XDISPLAY (display),
           &num_devices);

   ...

       for (i=0; i < num_devices; i++) {
           if (devices[i].use == IsXExtensionDevice) {
               device = XOpenDevice (GDK_DISPLAY_XDISPLAY (display),
                   devices[i].id);
               for (j=0; j < device->num_classes && number < 39; j++) {
                   switch (device->classes[j].input_class)
                   {

   ...

That code works in most cases, except when the device is defined but not actually there, in which case the call to XOpenDevice() will cause an X error. Since there is no mechanism in place to trap that error, the gdmgreeter will fail and cause the error reported.

The proper way (IMHO) to handle this is to protect the call to XOpenDevice() by wrapping it in an X error handler, ie change the code to:

   static void
   init_xinput (GdkDisplay *display, GdkWindow *root)
   {
   ...
       devices = XListInputDevices (GDK_DISPLAY_XDISPLAY (display),
           &num_devices);

   ...

       for (i=0; i < num_devices; i++) {
           if (devices[i].use == IsXExtensionDevice) {
               gdk_error_trap_push ();
               device = XOpenDevice (GDK_DISPLAY_XDISPLAY (display),
                   devices[i].id);
               if (gdk_error_trap_pop())
               {
                   if (debug_gestures)
                       syslog (LOG_WARNING, "Failed to open input devices %i (%s)",
                           devices[i].id, devices[i].name);
                   continue;
               }
               for (j=0; j < device->num_classes && number < 39; j++) {
                   switch (device->classes[j].input_class)
                   {
   ...


The bug is still upstream (at least in gdm that comes with gnome-2.20, the last one before gdm was changed).
Comment 1 Olivier Fourdan 2008-12-04 10:59:20 EST
Created attachment 325700 [details]
Same patch if the one from bz#473262 is applied

Now, this patch modifies a part of the code that is modified by another patch for BZ#473262 (“Mouse cursor not movable when using tablet instead of mouse”)

The patch for BZ#473262 removes the XInput code from “dwellmouselistener.c” so if that other patch for BZ#473262 is applied, then better use this one patch that fixes only the portion remaining in “keymouselistener.c”
Comment 3 Ray Strode [halfline] 2009-01-05 12:48:08 EST
devack+
Comment 4 Ray Strode [halfline] 2009-05-12 10:40:40 EDT
building as gdm-2.16.0-49.el5 now.  Marking MODIFIED for QA.
Comment 6 Chris Ward 2009-07-03 14:15:07 EDT
~~ Attention - RHEL 5.4 Beta Released! ~~

RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner!

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value.

Questions can be posted to this bug or your customer or partner representative.
Comment 9 errata-xmlrpc 2009-09-02 07:28:42 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/RHSA-2009-1364.html

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