XOrg::XNextEvent() crashed with SIGSEGV

[ebnf]

Binary package hint: xbindkeys

Description: Ubuntu intrepid (development branch)
Release: 8.10

xbindkeys:
  Installed: 1.8.2-1
  Candidate: 1.8.2-1
  Version table:
 *** 1.8.2-1 0
        500 http://archive.ubuntu.com intrepid/universe Packages
        100 /var/lib/dpkg/status

Opened up keyboard settings to reset my keyboard/layout because xbindkeys keeps crashing and resetting the keyboard/layout.

I have an Mac keyboard managed by evdev if that helps.

ProblemType: Crash
Architecture: amd64
DistroRelease: Ubuntu 8.10
ExecutablePath: /usr/bin/xbindkeys
Package: xbindkeys 1.8.2-1
ProcAttrCurrent: unconfined
ProcCmdline: /usr/bin/xbindkeys
ProcEnviron:
 PATH=/home/username/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
Signal: 11
SourcePackage: xbindkeys
StacktraceTop:
 XNextEvent () from /usr/lib/libX11.so.6
 ?? ()
 scm_boot_guile () from /usr/lib/libguile.so.12
 ?? ()
 __libc_start_main () from /lib/libc.so.6
Title: xbindkeys crashed with SIGSEGV in XNextEvent()
Uname: Linux 2.6.26-5-generic x86_64
UserGroups: adm admin audio cdrom dialout dip floppy fuse lpadmin plugdev sambashare video

[Apport retracing service (apport)]

StacktraceTop:XNextEvent (dpy=0x1480da0, event=0x7fffe15c8dd0) at ../../src/NextEvent.c:52
inner_main (argc=1, argv=0x4810ffe2) at xbindkeys.c:252
scm_boot_guile () from /usr/lib/libguile.so.12
main (argc=<value optimized out>, argv=<value optimized out>) at xbindkeys.c:152

[Fumihito-yoshida (fumihito-yoshida)]

XNextEvent() segfault when XlibDisplayIOError is true
It cause by xcb_io.c::_XReadEvents() and xcb_io.c::_XSend()'s some code.
This problem affected to libX11 1.1.2 -1.1.5 and git (Release: R7.2 - R7.4) .

When dpy->head is null, the XNextEvent() called _XReadEvents(),
but xcb_io.c::_XReadEvents() and xcb_io.c::_XSend() has dpy->flags check,
when XlibDiskpayIOError bit is set, their procedure return without any work.

       if(dpy->flags & XlibDisplayIOError)
               return;

So, XNextEvent()'s dpy is still null, and crash.

This problem will crash IIIMF, Compiz and so on.

in Classical X event loop:
 // It will cause segfault in some conditions....

Display *pdisplay;
XEvent event;
pdisplay = XOpenDisplay(NULL);

for (; ;){
       XNextEvent(pdisplay, &event);
       /* X Event Handler */
}

This code causes segfault at XNextEvent(). If you trace it, you will find below crash point.

--- XNextEvent() ----------------------------------
int
XNextEvent (
       register Display *dpy,
       register XEvent *event)
{
       register _XQEvent *qelt;

       LockDisplay(dpy);

       if (dpy->head == NULL)
           _XReadEvents(dpy); // <- it hope _XReadEvents return valid
                                      // handler, it believev
dpy->head != null...
       qelt = dpy->head;
       *event = qelt->event; // <- but, dpy->head->event is null, CRASH.
                                     // Because dpy->head is null!
       _XDeq(dpy, NULL, qelt);
       UnlockDisplay(dpy);
       return 0;
}
--------------------------------------------------

If you replace "if(dpy->head == null)" to "while(dpy->head == null)",
the problem solved.
// Notice: if => while replacement cause busy loop and possible infinite loop.

This segfaults conditions are:
 a) X Event queue is empty.
 b) XDisplayIOError is true.
You call XNextEvent() when (a && b), your program will segfault.

Case2: Modern X event loop style is below:
 // It wont cause segfault, and lockless.

Display *pdisplay;
XEvent event;
pdisplay = XOpenDisplay(NULL);

for (; ;){
       if (XPending()){
               XNextEvent(pdisplay, &event);
               /* X Event Handler */
       }
       /* other event looping and some usleeps. */
}

Because this implement want evading XNextEvent()'s blocking.
XNextEvent() always return least one events, but when X event
queue is empty, cause blocking-wait for next new events.

But, man XNextEvent(3) says:
| The XNextEvent function copies the first event from the event queue
| into the specified XEvent structure and then removes it from the queue.
| If the event queue is empty, XNextEvent flushes the output buffer and
| blocks until an event is received.

Current implement is not "blocks", "sometimes blocks, sometimes crash".

And we have big issue, the classical X event loop(Case1) are not failure
in old-days, their coding were(are?) right. (But, their old style coding are not
efficient, we need modern style.).

We can find their classical event loop in many code asset, they will crash
by this problem.....

I suggest dirty hack.
 XlibDisplayIOError flag can be cleard with some wait times.

--- NextEvent.c.orig
+++ NextEvent.c
@@ -45,9 +45,14 @@...

[Fumihito YOSHIDA (hito)]

Hi,

This is XNextEvent()(_XReadEvents() and _XSend() ) bug, it affect 7.10/8.04/8.10,
Debian Lenny and some other distro(using XOrg 7.2 - ).

I have dirty patch and reported to upsteream in another time(but XOrg does not respond).

 - http://lists.freedesktop.org/archives/xorg/2008-September/039042.html
 - https://bugs.freedesktop.org/show_bug.cgi?id=17923

 - This XNextEvent() bug breaks backward-compatilibility,
    Old style X apps will be eliminate by this bug. (e.g. IIIMF).

Adove patch were tested by us(Ubuntu Japanese LoCo) and some Japanese users,
it works fine.

[Fumihito YOSHIDA (hito)]

And, we have patched binary and sources (It is fully compatible for original Hardy/Interpid).

- Intrepid
http://archive.ubuntulinux.jp/ubuntu-ja/intrepid/libx11-6_1.1.5-2ubuntu1ja1_i386.deb

- Hardy
http://archive.ubuntulinux.jp/ubuntu-ja/hardy-experimental/libx11-6_1.1.3-1ubuntu2ja3_i386.deb

[Bryce Harrington (bryce)]

Hi eric-zeitler,

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with the latest development release of Ubuntu? (ISOs are available from cdimage.ubuntu.com)

If it remains an issue, could you also attach a new /var/log/Xorg.0.log?
Thanks in advance.

The output of lspci -vvnn would also be worth having.

[Bryce Harrington (bryce)]

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.

[Fumihito YOSHIDA (hito)]

This problem still exist in 8.10(and upstream's CURRENT(git)).

[ebnf (eric-zeitler)]

I am currently using the "fireglx" driver rather than "radeon" and all the latest intrepid updates so my configuration isn't quite the same. I haven't seen this crash in a while, but it may just be due to the different driver.

$ apt-cache policy xorg
xorg:
  Installed: 1:7.4~5ubuntu3
  Candidate: 1:7.4~5ubuntu3
  Version table:
 *** 1:7.4~5ubuntu3 0
        500 http://us.archive.ubuntu.com intrepid/main Packages
        100 /var/lib/dpkg/status

$ apt-cache policy xbindkeys
xbindkeys:
  Installed: 1.8.2-1
  Candidate: 1.8.2-1
  Version table:
 *** 1.8.2-1 0
        500 http://us.archive.ubuntu.com intrepid/universe Packages
        100 /var/lib/dpkg/status

$ apt-cache policy xorg-driver-fglrx
xorg-driver-fglrx:
  Installed: 2:8.543-0ubuntu4
  Candidate: 2:8.543-0ubuntu4
  Version table:
 *** 2:8.543-0ubuntu4 0
        500 http://us.archive.ubuntu.com intrepid/restricted Packages
        100 /var/lib/dpkg/status

[Tom Jaeger (thjaeger)]

Does your application use XTest? If so, can you check if this patch fixes the issue?

http://cgit.freedesktop.org/xorg/xserver/commit/?id=b2756a71a432f7cf7c870a48676c98625512558d

[Tom Jaeger (thjaeger)]

I think this patch should fix the problem :

http://cgit.freedesktop.org/xorg/xserver/commit/?id=b2756a71a432f7cf7c870a48676c98625512558d

Instructions for building and installing an updated X server package:

sudo apt-get build-dep xorg-server
apt-get source xorg-server
cd xorg-server<TAB>
wget -O - http://cgit.freedesktop.org/xorg/xserver/patch/?id=b2756a71a432f7cf7c870a48676c98625512558d | patch -p1
dch -l -fix
#save the file
dpkg-buildpackage -b -uc -us
sudo dpkg -i ../xserver-xorg-core_<TAB>

[Fumihito YOSHIDA (hito)]

Thanks Tom,

But, I test with my Jaunty(last update at Jan 15,2009) testbed *without* b2756a71a432f7cf7c870a48676c98625512558d pach( = using jaunty originals), I cant reproduce this behavior.....

Maybe we have 2 pattern.
 a) that fixed in upstream other patchs.
 b) that depends some another factors.
 (e.g.: GPU driver. in my Jauntys Dell M1330 use vesa driver, because nv does not works now.)

I'll test with another environments, please wait.

[Bryce Harrington (bryce)]

hito's patch

[Fumihito YOSHIDA (hito)]

Sorry for my lazy report.

I report 2 facts.

1)
  I test with Jaunty (in latest update, 9 Apr) , with 3 drivers; intel and nv, proprietary nvidia.
  They are work fine with no patch. Jaunty solve this issue.

2)
  I test with Hardy and Intrepid, with 4 drivers; intel and nv, proprietary nvidia, proprietary fgl.
  They needs their dirty hack patch. and some nvidia env(hardy + latest updates) cause bad
  respond/fps. if you exec glxgear, you will find like freeze(a few fps). It cause badly side-effects
  in some driver issue.

[Bryce Harrington (bryce)]

Thanks for letting us know it is solved in jaunty. Leaving tasks for hardy and intrepid.

[Alex Valavanis (valavanisalex)]

Intrepid Ibex reached end-of-life on 30 April 2010 so I am closing the
report. The bug has been fixed in newer releases of Ubuntu.

[Rolf Leggewie (r0lf)]

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".