XOrg::XNextEvent() crashed with SIGSEGV

Bug #257659 reported by ebnf on 2008-08-13
Affects Status Importance Assigned to Milestone
X.Org X server
Won't Fix
libx11 (Debian)
xorg-server (Ubuntu)
Bryce Harrington

Bug Description

Binary package hint: xbindkeys

Description: Ubuntu intrepid (development branch)
Release: 8.10

  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
Signal: 11
SourcePackage: xbindkeys
 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

ebnf (eric-zeitler) wrote :

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

Changed in xbindkeys:
importance: Undecided → Medium
Download full text (3.4 KiB)

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)

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() ----------------------------------
XNextEvent (
       register Display *dpy,
       register XEvent *event)
       register _XQEvent *qelt;


       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);
       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 @@...



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) wrote :
Changed in xorg-server:
status: Unknown → Confirmed
Bryce Harrington (bryce) wrote :

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.

Changed in libx11:
status: New → Incomplete
Bryce Harrington (bryce) wrote :

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.

Changed in libx11:
status: Incomplete → Invalid
Fumihito YOSHIDA (hito) wrote :

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

Changed in libx11:
status: Invalid → Confirmed
ebnf (eric-zeitler) wrote :

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

ebnf (eric-zeitler) wrote :
Bryce Harrington (bryce) on 2008-11-06
Changed in libx11:
status: Confirmed → Triaged

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


Tom Jaeger (thjaeger) wrote :

I think this patch should fix the problem :


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) wrote :

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) on 2009-03-19
Changed in xorg-server (Ubuntu):
assignee: nobody → bryceharrington
Bryce Harrington (bryce) wrote :

hito's patch

Fumihito YOSHIDA (hito) wrote :

Sorry for my lazy report.

I report 2 facts.

  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.

  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) wrote :

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

Changed in xorg-server (Ubuntu Jaunty):
status: New → Fix Released
Bryce Harrington (bryce) on 2009-05-01
Changed in xorg-server (Ubuntu):
status: Triaged → Fix Released
Alex Valavanis (valavanisalex) wrote :

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.

Changed in xorg-server (Ubuntu Intrepid):
status: New → Invalid
Changed in xorg-server:
importance: Unknown → Medium
Changed in xorg-server:
importance: Medium → Unknown
Changed in xorg-server:
importance: Unknown → Medium
Changed in xorg-server:
importance: Medium → Critical
status: Confirmed → Won't Fix
Rolf Leggewie (r0lf) wrote :

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".

Changed in xorg-server (Ubuntu Hardy):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.