Bug 52496

Summary: segfault in XIChangeDeviceProperty upon suspend
Product: xorg Reporter: Yaroslav Halchenko <debian>
Component: Server/Input/CoreAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: high CC: debian, marcus, peter.hutterer, thaytan, torvalds, typrase
Version: 7.7 (2012.06)   
Hardware: All   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Yaroslav Halchenko 2012-07-25 17:35:27 UTC
Reported originally: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681796
Happens with xserver-xorg-core 1.12.1.902-1

top backtrace from gdb:

Program received signal SIGSEGV, Segmentation fault.
XIChangeDeviceProperty (dev=dev@entry=0x7f4bac237fa0, property=<optimized out>, type=type@entry=19, format=format@entry=8, mode=<optimized out>, mode@entry=0, len=len@entry=1, 
    value=value@entry=0x7fff092e860f, sendevent=sendevent@entry=1) at ../../Xi/xiproperty.c:772
772     ../../Xi/xiproperty.c: No such file or directory.
#0  XIChangeDeviceProperty (dev=dev@entry=0x7f4bac237fa0, property=<optimized out>, type=type@entry=19, format=format@entry=8, mode=<optimized out>, mode@entry=0, 
    len=len@entry=1, value=value@entry=0x7fff092e860f, sendevent=sendevent@entry=1) at ../../Xi/xiproperty.c:772
#1  0x00007f4ba813c20f in DisableDevice (dev=0x7f4bac237fa0, sendevent=sendevent@entry=1 '\001') at ../../dix/devices.c:481
#2  0x00007f4ba817e344 in xf86VTSwitch () at ../../../../hw/xfree86/common/xf86Events.c:454
#3  xf86Wakeup (blockData=<optimized out>, err=<optimized out>, pReadmask=<optimized out>) at ../../../../hw/xfree86/common/xf86Events.c:285
#4  0x00007f4ba8146d9b in WakeupHandler (result=result@entry=-1, pReadmask=pReadmask@entry=0x7f4


here is an excerpt from xiproperty.c for that location:

   766              /* run through all handlers with checkonly TRUE, then again with
   767               * checkonly FALSE. Handlers MUST return error codes on the
   768               * checkonly run, errors on the second run are ignored */
   769              do {
   770                  handler = dev->properties.handlers;
   771                  while (handler) {
   772                      if (handler->SetProperty) {
   773                          rc = handler->SetProperty(dev, prop->propertyName,
   774                                                    &new_value, checkonly);
   775                          if (checkonly && rc != Success) {
   776                              free(new_value.data);
   777                              return rc;
   778                          }
   779                      }
   780                      handler = handler->next;
   781                  }
   782                  checkonly = !checkonly;
   783              } while (!checkonly);
Comment 1 Kevin Goodsell 2012-07-29 22:52:41 UTC
I believe I've been encountering the same crash, though I usually get it a few minutes after resuming from suspend. This is on an ASUS EeePC 1005HA running Debian Wheezy The Debian package is xserver-xorg-core 2:1.12.1.902-1. The log shows this:

[ 12941.730] (--) synaptics: SynPS/2 Synaptics TouchPad: touchpad found
[ 13139.273] 
[ 13139.273] Backtrace:
[ 13139.347] 0: /usr/bin/Xorg (xorg_backtrace+0x49) [0xb7772099]
[ 13139.347] 1: /usr/bin/Xorg (0xb75f5000+0x180a86) [0xb7775a86]
[ 13139.347] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xb75d640c]
[ 13139.347] 3: /usr/bin/Xorg (XIChangeDeviceProperty+0x198) [0xb770d188]
[ 13139.348] 4: /usr/bin/Xorg (0xb75f5000+0x118829) [0xb770d829]
[ 13139.348] 5: /usr/bin/Xorg (0xb75f5000+0x10f7d4) [0xb77047d4]
[ 13139.348] 6: /usr/bin/Xorg (0xb75f5000+0x3c365) [0xb7631365]
[ 13139.348] 7: /usr/bin/Xorg (0xb75f5000+0x29e95) [0xb761ee95]
[ 13139.348] 8: /lib/i386-linux-gnu/i686/cmov/libc.so.6 (__libc_start_main+0xe6) [0xb7293e46]
[ 13139.348] 9: /usr/bin/Xorg (0xb75f5000+0x2a1e9) [0xb761f1e9]
[ 13139.348] 
[ 13139.349] Segmentation fault at address 0x9
[ 13139.349] 
Fatal server error:
[ 13139.349] Caught signal 11 (Segmentation fault). Server aborting

I got a core file as well:

Core was generated by `/usr/bin/Xorg :0 -br -verbose -novtswitch -auth /var/run/gdm3/auth-for-Debian-g'.
Program terminated with signal 11, Segmentation fault.
#0  XIChangeDeviceProperty (dev=dev@entry=0xb7bcd898, property=135, type=type@entry=19, format=format@entry=8, mode=<optimized out>, mode@entry=0, len=len@entry=1, 
    value=value@entry=0xbfbfb16f, sendevent=sendevent@entry=1) at ../../Xi/xiproperty.c:772
772     ../../Xi/xiproperty.c: No such file or directory.
(gdb) bt
#0  XIChangeDeviceProperty (dev=dev@entry=0xb7bcd898, property=135, type=type@entry=19, format=format@entry=8, mode=<optimized out>, mode@entry=0, len=len@entry=1, 
    value=value@entry=0xbfbfb16f, sendevent=sendevent@entry=1) at ../../Xi/xiproperty.c:772
#1  0xb75c2aa3 in DisableDevice (dev=dev@entry=0xb7bcd898, sendevent=sendevent@entry=1 '\001') at ../../dix/devices.c:481
#2  0xb75c2ced in RemoveDevice (dev=dev@entry=0xb7bcd898, sendevent=sendevent@entry=1 '\001') at ../../dix/devices.c:1059
#3  0xb7618fac in DeleteInputDeviceRequest (pDev=0xb7bcd898) at ../../../../hw/xfree86/common/xf86Xinput.c:1013
#4  0xb75be4d0 in CloseDeviceList (listHead=listHead@entry=0xb7784444) at ../../dix/devices.c:964
#5  0xb75befa0 in CloseDownDevices () at ../../dix/devices.c:993
#6  0xb7716595 in AbortServer () at ../../os/log.c:475
#7  0xb77166c5 in FatalError (f=f@entry=0xb773b448 "Caught signal %d (%s). Server aborting\n") at ../../os/log.c:611
#8  0xb770eae8 in OsSigHandler (sip=0xbfbfb4ac, signo=11, unused=<optimized out>) at ../../os/osinit.c:146
#9  OsSigHandler (signo=11, sip=0xbfbfb4ac, unused=0xbfbfb52c) at ../../os/osinit.c:107
#10 <signal handler called>
#11 XIChangeDeviceProperty (dev=0xb7bcd898, property=property@entry=281, type=19, format=format@entry=8, mode=<optimized out>, len=1, value=value@entry=0xb7c52ddc, 
    sendevent=sendevent@entry=1) at ../../Xi/xiproperty.c:772
#12 0xb76a6829 in change_property (data=0xb7c52ddc, len=<optimized out>, mode=<optimized out>, format=8, type=<optimized out>, property=281, dev=<optimized out>, 
    client=<optimized out>) at ../../Xi/xiproperty.c:354
#13 ProcXChangeDeviceProperty (client=0xb7c3cf40) at ../../Xi/xiproperty.c:908
#14 0xb769d7d4 in ProcIDispatch (client=0xb7c3cf40) at ../../Xi/extinit.c:410
#15 0xb75ca365 in Dispatch () at ../../dix/dispatch.c:428
#16 0xb75b7e95 in main (argc=10, argv=0xbfbfba54, envp=0xbfbfba80) at ../../dix/main.c:288
(gdb) frame 11
#11 XIChangeDeviceProperty (dev=0xb7bcd898, property=property@entry=281, type=19, format=format@entry=8, mode=<optimized out>, len=1, value=value@entry=0xb7c52ddc, 
    sendevent=sendevent@entry=1) at ../../Xi/xiproperty.c:772
772                         if (handler->SetProperty) {
(gdb) list
767                  * checkonly FALSE. Handlers MUST return error codes on the
768                  * checkonly run, errors on the second run are ignored */
769                 do {
770                     handler = dev->properties.handlers;
771                     while (handler) {
772                         if (handler->SetProperty) {
773                             rc = handler->SetProperty(dev, prop->propertyName,
774                                                       &new_value, checkonly);
775                             if (checkonly && rc != Success) {
776                                 free(new_value.data);
(gdb) p handler
$1 = (XIPropertyHandlerPtr) 0x1
(gdb) p handler->SetProperty
Cannot access memory at address 0x9

Note that this gives the address as 0x9, same as the log file. I believe this has been the address listed in the log every time I've seen this crash.

(gdb) p *dev
$2 = {public = {devicePrivate = 0xb7bb95f0, processInputProc = 0xb76c81a0 <ProcessKeyboardEvent>, realInputProc = 0xb76c81a0 <ProcessKeyboardEvent>, 
    enqueueInputProc = 0xb75d2590 <EnqueueEvent>, on = 0}, next = 0x0, startup = 1, deviceProc = 0xb6710110, inited = 1, enabled = 0, coreEvents = 4, deviceGrab = {
    grabTime = {months = 0, milliseconds = 5068631}, fromPassiveGrab = 0, implicitGrab = 0, activeGrab = 0xb7bcdb48, grab = 0x0, activatingKey = 0 '\000', 
    ActivateGrab = 0xb75dafc0 <ActivateKeyboardGrab>, DeactivateGrab = 0xb75dade0 <DeactivateKeyboardGrab>, sync = {frozen = 0, state = 0, other = 0x0, 
      event = 0xb7bcde50}}, type = 3, xinput_type = 96, name = 0xb7bce088 "SynPS/2 Synaptics TouchPad", id = 13, key = 0x0, valuator = 0xb7bce6b8, touch = 0xb7bd02a8, 
  button = 0xb7bce160, focus = 0x0, proximity = 0x0, kbdfeed = 0x0, ptrfeed = 0xb7bd0148, intfeed = 0x0, stringfeed = 0x0, bell = 0x0, leds = 0x0, xkb_interest = 0x0, 
  config_info = 0xb7bce0a8 "udev:/sys/devices/platform/i8042/serio1/input/input8/event8", unused_classes = 0x0, saved_master_id = 0, devPrivates = 0xb7bcdb00, 
  unwrapProc = 0xb76c6560 <xkbUnwrapProc>, spriteInfo = 0xb7bcdae4, master = 0x0, lastSlave = 0x0, last = {valuators = {3322.2696093537093, 3055.4704689213017, 
      -13769.111570356075, 272483.30117348192, 0 <repeats 32 times>}, numValuators = 4, slave = 0x0, scroll = 0xb7bce7d0, num_touches = 2, touches = 0xb7bd07f0}, 
  properties = {properties = 0xb7bd2588, handlers = 0xb7bd25c0}, transform = {m = {{0, 0, 0}, {0, 0, 0}, {0, 0, 0}}}, xtest_master_id = 0}

Looks like it might be an issue in Synaptics.

(gdb) p dev->properties.handlers
$3 = (XIPropertyHandlerPtr) 0xb7bd25c0
(gdb) p dev->properties.handlers->next
$4 = (struct _XIPropertyHandler *) 0xb7bd0130
(gdb) p dev->properties.handlers->next->next
$5 = (struct _XIPropertyHandler *) 0xb7bd00a8
(gdb) p dev->properties.handlers->next->next->next
$6 = (struct _XIPropertyHandler *) 0xb7bd0020
(gdb) p dev->properties.handlers->next->next->next->next
$7 = (struct _XIPropertyHandler *) 0xb7bcff98
(gdb) p dev->properties.handlers->next->next->next->next->next
$8 = (struct _XIPropertyHandler *) 0x1
(gdb) p *dev->properties.handlers->next->next->next->next
$9 = {next = 0x1, id = 1, SetProperty = 0xb75e9e10 <AccelSetProfileProperty>, GetProperty = 0, DeleteProperty = 0}

The handler with the invalid "next" pointer has AccelSetProfileProperty for its SetProperty member. I hope that helps narrow it down.
Comment 2 paul.geisler 2012-08-06 21:53:29 UTC
I've raised the importance as this seems to be the equivalent of a large amount of bug reports on Ubuntu via launchpad. It affects PCs of several vendors, maybe restricted to newer Intel CPU/GPUs. Main launchpad report here: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/956071
Comment 3 Peter Hutterer 2012-08-07 01:14:27 UTC
Does debian carry any patches? if so, can you reproduce this with a vanilla X server? I just vt-switched about 50 times with 1.12.99.902 but it doesn't happen here.

What desktop environment is this? something is trying to change the property after the VT switch, so I'd need a similar setup here.

Finally, if you can reproduce it easily, can you try running X through valgrind to see if you get any invalid writes?
Comment 4 Peter Hutterer 2012-08-07 01:16:43 UTC
correction, I tried reproducing with 1.12.1.902, i.e. the same version as listed in the original comment.
Comment 5 Yaroslav Halchenko 2012-08-07 01:46:20 UTC
(In reply to comment #3)
> Does debian carry any patches?

yes.  See
http://patch-tracker.debian.org/package/xorg-server/2:1.12.3-1
for details

> if so, can you reproduce this with a vanilla X
> server? I just vt-switched about 50 times with 1.12.99.902 but it doesn't
> happen here.

Never happened for me while switching VT. although I do not do that regularly... ok -- switched to VT 1 and back (Ctrl-Alt-1 and then randomly Alt-left/right till reaching X) quite a few times (around 10) -- no problem.  With suspend I think I would have experienced it by then.  Also, may be of relevance:

if X crashes during suspend and I end up again at the kdm login prompt -- I would still have my 'half-moon' light blinking until I switch to e.g. VT 1 -- then it would finally suspend.

> What desktop environment is this? 

happened originally with KDE4 + awesome... now it is XFCE + awesome -- the same story

> something is trying to change the property
> after the VT switch, so I'd need a similar setup here.

my ~/.xsession has 

    awesome &
    sleep 3
    xfce4-session

> Finally, if you can reproduce it easily, can you try running X through valgrind
> to see if you get any invalid writes?

It is reproducible on around 5-10th occasion on random -- never yet tried to cause it on purpose -- I thought to give it excessive troubleshooting one day... if I get a moment I will run it through valgrind... although if it is some kind of a race condition between threads, it might not get triggered
Comment 6 Timo Aaltonen 2012-08-08 21:13:01 UTC
yaroslav: could you try reverting the synaptics driver to, say, 1.5.99.902 or .903 and test if you can reproduce the crash? A similar crash has been filed on ubuntu, and there it was discovered that reverting to that version stopped the crashes.
Comment 7 Yaroslav Halchenko 2012-08-08 21:30:22 UTC
(In reply to comment #6)
> yaroslav: could you try reverting the synaptics driver to, say, 1.5.99.902 or
> .903 and test if you can reproduce the crash? A similar crash has been filed on
> ubuntu, and there it was discovered that reverting to that version stopped the
> crashes.

yes -- I saw those and also thought to revert BUT IIRC those ubuntu reports were primarily about (similar) crash upon resume, while mine is consistently occurring upon suspend; so I was not sure if that would be it.  Today, while connected via usb-serial port thought to replicate to get better interactive gdb session so I could possibly figure out more but tried around 10 times to suspend/resume -- didn't happen :-/

heh-- but I guess it might be worth anyways -- if it crashes, I would get to the same point if I would be ready to debug ;) if not -- then you might not hear from me for a week or so since as I said it would be difficult to say for sure that it helped without waiting for so long ;)
Comment 8 Yaroslav Halchenko 2012-08-15 13:52:19 UTC
ok -- downgrade to xserver-xorg-input-synaptics 1.5.99.902-1 (debian package) built with -O0 -- no crashes within a week -- so I guess it is indeed synaptics to blame.  If I find a chance I will "upgrade" to 1.6.0 and see if crash comes back... I would hate to do such silly bisection but I guess it would be better than doing nothing and simply waiting  ;-)
Comment 9 Peter Hutterer 2012-08-17 03:01:53 UTC
sorry, still can't reproduce this and I can't see any change between 902 and 1.6.2 that could have introduced this bug. Are you still on server 1.12.1.902 or have you updated the server as well?
Comment 10 Yaroslav Halchenko 2012-08-17 14:28:59 UTC
I have upgraded xorg server quite a while ago and it had not resolved the issue at that time.  Just for the completness:

/var/log/dpkg.log.1:2012-07-03 09:53:04 status installed xserver-xorg:amd64 1:7.6+13
/var/log/dpkg.log.1:2012-07-03 09:53:04 status installed xorg:amd64 1:7.6+13
/var/log/dpkg.log.1:2012-07-11 14:56:36 status installed xserver-xorg-core:amd64 2:1.12.1.902-1
/var/log/dpkg.log.1:2012-07-11 16:22:02 status installed xserver-xorg-video-vesa:amd64 1:2.3.1-1+b1
/var/log/dpkg.log.1:2012-07-11 16:22:02 status installed xserver-xorg-video-intel:amd64 2:2.19.0-4
/var/log/dpkg.log.1:2012-07-11 16:22:02 status installed xserver-xorg-video-fbdev:amd64 1:0.4.2-4+b3
/var/log/dpkg.log.1:2012-07-11 16:22:02 status installed xserver-xorg-video-dummy:amd64 1:0.3.5-2+b1
/var/log/dpkg.log.1:2012-07-11 16:22:02 status installed xserver-xorg-video-apm:amd64 1:1.2.3-3
/var/log/dpkg.log.1:2012-07-11 16:22:02 status installed xserver-xorg-input-void:amd64 1:1.4.0-1+b1
/var/log/dpkg.log.1:2012-07-11 16:22:02 status installed xserver-xorg-input-synaptics:amd64 1.6.2-1
/var/log/dpkg.log.1:2012-07-11 16:22:02 status installed xserver-xorg-input-evdev:amd64 1:2.7.0-1+b1
/var/log/dpkg.log.1:2012-07-11 16:22:02 status installed xserver-xorg:amd64 1:7.7+1
/var/log/dpkg.log.1:2012-07-11 16:22:02 status installed xorg:amd64 1:7.7+1
/var/log/dpkg.log.1:2012-07-11 16:22:02 status installed xserver-xorg-dev:amd64 2:1.12.1.902-1
/var/log/dpkg.log.1:2012-07-11 16:22:02 status installed xorg-dev:all 1:7.7+1
/var/log/dpkg.log.1:2012-07-16 11:43:34 status installed xserver-xorg-core-dbg:amd64 2:1.12.1.902-1
/var/log/dpkg.log.1:2012-07-16 11:43:34 status installed xserver-xorg-video-intel-dbg:amd64 2:2.19.0-4
/var/log/dpkg.log.1:2012-07-21 15:35:55 status installed xserver-xorg-core:amd64 2:1.12.3-1
/var/log/dpkg.log.1:2012-07-21 15:35:55 status installed xserver-xorg-core-dbg:amd64 2:1.12.3-1
/var/log/dpkg.log.1:2012-07-21 15:35:55 status installed xserver-xorg-dev:amd64 2:1.12.3-1
/var/log/dpkg.log.1:2012-07-25 09:18:55 status installed xserver-xorg-dev:amd64 2:1.12.3-1
/var/log/dpkg.log.1:2012-07-25 09:18:55 status installed xserver-xorg-core:amd64 2:1.12.3-1
/var/log/dpkg.log.1:2012-07-25 09:18:57 status installed xserver-xorg-core-dbg:amd64 2:1.12.3-1
/var/log/dpkg.log.1:2012-07-25 09:19:58 status installed xserver-xorg-dev:amd64 2:1.12.3-1
/var/log/dpkg.log.1:2012-07-25 09:19:58 status installed xserver-xorg-core:amd64 2:1.12.3-1
/var/log/dpkg.log.1:2012-07-25 09:20:00 status installed xserver-xorg-core-dbg:amd64 2:1.12.3-1
/var/log/dpkg.log.1:2012-07-26 20:15:33 status installed xserver-xorg-core-dbg:amd64 2:1.12.3-1
/var/log/dpkg.log:2012-08-08 23:12:08 status installed xserver-xorg-input-synaptics:amd64 1.6.2-1
/var/log/dpkg.log:2012-08-09 11:00:56 status installed xserver-xorg-input-synaptics-dev:all 1.5.99.902-1
/var/log/dpkg.log:2012-08-09 11:00:56 status installed xserver-xorg-input-synaptics:amd64 1.5.99.902-1
/var/log/dpkg.log:2012-08-15 12:45:23 status installed xserver-xorg-input-synaptics-dev:all 1.6.2+git44-ge28575b-1~yarik0
/var/log/dpkg.log:2012-08-15 12:45:23 status installed xserver-xorg-input-synaptics:amd64 1.6.2+git44-ge28575b-1~yarik0


as you see I have built and installed current master of the synaptics but had no chance yet to restart X to see if crash comes back... I will report back whenever that happens
Comment 11 Peter Hutterer 2012-08-20 00:21:03 UTC
*** Bug 53686 has been marked as a duplicate of this bug. ***
Comment 12 Maarten Lankhorst 2012-08-24 10:08:48 UTC
After suspending/resuming I notice this error repeated a whole lot of times
on xorg 1.13rc4 + synaptics 1.6.2 (with finger on touchpad while suspending/resuming by closing lid and pressing power button to wake up):

==3097== Invalid write of size 4
==3097== at 0xAEBFE95: UpdateTouchState.isra.12 (synaptics.c:3132)
==3097== by 0xAEC1532: HandleState (synaptics.c:3224)
==3097== by 0xAEC3F73: ReadInput (synaptics.c:1725)
==3097== by 0x19B656: xf86SigioReadInput (xf86Events.c:298)
==3097== by 0x1C4C97: xf86SIGIO (sigio.c:110)
==3097== by 0x56D9CAF: ??? (in /lib/x86_64-linux-gnu/libpthread-2.15.so)
==3097== by 0x56D8D0D: __read_nocancel (syscall-template.S:82)
==3097== by 0x2B8525: _XSERVTransSocketRead (unistd.h:45)
==3097== by 0x2B2FC0: ReadRequestFromClient (io.c:332)
==3097== by 0x15D878: Dispatch (dispatch.c:399)
==3097== by 0x14C559: main (main.c:295)
==3097== Address 0xaae8da8 is 0 bytes after a block of size 8 alloc'd
==3097== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3097== by 0xAEC0F13: DeviceControl (synaptics.c:1277)
==3097== by 0x153082: ActivateDevice (devices.c:547)
==3097== by 0x1AA30D: xf86NewInputDevice (xf86Xinput.c:858)
==3097== by 0x1C0655: device_added (udev.c:231)
==3097== by 0x1C0CB2: config_udev_init (udev.c:386)
==3097== by 0x1BFC08: config_init (config.c:48)
==3097== by 0x19DB4D: InitInput (xf86Init.c:989)
==3097== by 0x14C518: main (main.c:265)

I guess if it happens multiple times it could get out of bounds enough to cause overflow..
Comment 13 Peter Hutterer 2012-08-30 06:58:35 UTC
Thanks! that really helped finding the issue

http://patchwork.freedesktop.org/patch/11873/
Comment 14 Timo Aaltonen 2012-08-30 17:52:48 UTC
thanks for the patch, fixed it for me!
Comment 15 Peter Hutterer 2012-08-30 21:42:14 UTC
commit a245d42f53096b1ae81e6702729f97ca508e5b5b
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Aug 30 16:38:38 2012 +1000

    Reset num_active_touches on DeviceOff (#52496)
Comment 16 rephorm 2012-10-18 17:52:56 UTC
Although this patch makes the situation much better, it looks like a similar bug is present elsewhere. Using git commit On git rev 3cb14dcccf5574366d90e24f351e3ad04b35e35f, I see an occasional crash after  several days of using a laptop with ~10 suspensions per day.

The following diagnostic messages and backtrace appears three times in the Xorg log before Xorg quits:

[121305.099] BUG: triggered 'if (priv->num_active_touches > priv->num_slots)'
[121305.099] BUG: synaptics.c:2615 in UpdateTouchState()
[121305.099] 
[121305.099] Backtrace:
[121305.384] 0: /usr/bin/X (xorg_backtrace+0x36) [0x560366]
[121305.384] 1: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7ff504292000+0x2c47) [0x7ff504294c47]
[121305.384] 2: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7ff504292000+0x4cdb) [0x7ff504296cdb]
[121305.384] 3: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7ff504292000+0x6744) [0x7ff504298744]
[121305.384] 4: /usr/bin/X (0x400000+0x6efd7) [0x46efd7]
[121305.384] 5: /usr/bin/X (0x400000+0x93370) [0x493370]
[121305.384] 6: /usr/lib/libpthread.so.0 (0x7ff508a94000+0xf170) [0x7ff508aa3170]
[121305.384] 7: /usr/bin/X (0x400000+0x164540) [0x564540]
[121305.384] 8: /usr/lib/libpthread.so.0 (0x7ff508a94000+0xf170) [0x7ff508aa3170]
[121305.384] 9: /usr/lib/libc.so.6 (0x7ff50791f000+0x7ba57) [0x7ff50799aa57]
[121305.384] 10: /usr/lib/libc.so.6 (__libc_malloc+0x70) [0x7ff50799be50]
[121305.389] 11: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff505a6b000+0x3fa6d) [0x7ff505aaaa6d]
[121305.389] 12: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff505a6b000+0x4b7b8) [0x7ff505ab67b8]
[121305.389] 13: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff505a6b000+0x4d09b) [0x7ff505ab809b]
[121305.389] 14: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff505a6b000+0x80d9b) [0x7ff505aebd9b]
[121305.389] 15: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff505a6b000+0x813b3) [0x7ff505aec3b3]
[121305.389] 16: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff505a6b000+0x88466) [0x7ff505af3466]
[121305.390] 17: /usr/bin/X (0x400000+0xebc5b) [0x4ebc5b]
[121305.390] 18: /usr/bin/X (0x400000+0x34531) [0x434531]
[121305.390] 19: /usr/bin/X (0x400000+0x23615) [0x423615]
[121305.390] 20: /usr/lib/libc.so.6 (__libc_start_main+0xf5) [0x7ff507940725]
[121305.390] 21: /usr/bin/X (0x400000+0x238ed) [0x4238ed]
Comment 17 Peter Hutterer 2012-10-19 03:55:11 UTC
Hard to read the backtrace without symbols, but please try to find a reproducible test-case. The number of fingers on the touchpad at suspend time vs at resume time is almost certainly the trigger for this, but I haven't found a reliable trigger yet.
Comment 18 Jesse Glick 2012-10-22 13:49:19 UTC
1.6.2-1ubuntu1~precise2 which I think has this patch, and also 1.5.99, continue to crash for me with this SEGV on occasion, shortly but not immediately after unlocking the screen (not necessarily after resume from suspend). No clear way to reproduce. Anything that can be done to help? (Any all-in-one instructions available for rebuilding X + drivers with symbols and running through Valgrind?)
Comment 19 Danny 2012-12-27 20:18:33 UTC
A couple of weeks ago I experienced a similar bug once or twice (at least a similar backtrace as in comment 16), but I also did not have symbols installed.

However, it may be noteworthy that I did not trigger it by a resume, but by putting very heavy load on the machine. I have not done so since, but I will try to get some better debug info when I have time to try and reproduce this.
Comment 20 Danny 2013-01-10 13:38:12 UTC
I am not sure if it is still the same issue, but the last comments in this bug are very similar to what is reported in bug 55821.

A reproducible test case I could not find. It just happens during normal use, though a heavy load (suspend/resume) may trigger it quicker. It is hard to be really sure of this however.

This is on a Lenovo T410 with fedora 18 (note: I think 17 did not have this problem).

EE) BUG: triggered 'if (priv->num_active_touches > priv->num_slots)'
(EE) BUG: synaptics.c:3122 in UpdateTouchState()
(EE)
(EE) Backtrace:
(EE) 0: /usr/bin/X (xorg_backtrace+0x36) [0x46c496]
(EE) 1: /usr/lib64/xorg/modules/input/synaptics_drv.so (0x7fda46838000+0x2e97) [0x7fda4683ae97]
(EE) 2: /usr/lib64/xorg/modules/input/synaptics_drv.so (0x7fda46838000+0x4593) [0x7fda4683c593]
(EE) 3: /usr/lib64/xorg/modules/input/synaptics_drv.so (0x7fda46838000+0x6fd2) [0x7fda4683efd2]
(EE) 4: /usr/bin/X (0x400000+0x89747) [0x489747]
(EE) 5: /usr/bin/X (0x400000+0xb2e88) [0x4b2e88]
(EE) 6: /lib64/libpthread.so.0 (0x35ea800000+0xf000) [0x35ea80f000]
(EE) 7: /lib64/libc.so.6 (__select+0x13) [0x35ea0eb773]
(EE) 8: /usr/bin/X (WaitForSomething+0x190) [0x469a10]
(EE) 9: /usr/bin/X (0x400000+0x39301) [0x439301]
(EE) 10: /usr/bin/X (0x400000+0x280ba) [0x4280ba]
(EE) 11: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x35ea021a05]
(EE) 12: /usr/bin/X (0x400000+0x283fd) [0x4283fd]
(EE)

(gdb) info symbol 0x2e97
UpdateTouchState.isra.12 + 167 in section .text of /usr/lib64/xorg/modules/input/synaptics_drv.so
(gdb) info symbol 0x4593
HandleState + 499 in section .text of /usr/lib64/xorg/modules/input/synaptics_drv.so
(gdb) info symbol 0x6fd2
ReadInput + 130 in section .text of /usr/lib64/xorg/modules/input/synaptics_drv.so

(gdb) info symbol 0x489747
xf86SigioReadInput + 39 in section .text of /usr/bin/X
(gdb) info symbol 0x4b2e88
xf86SIGIO + 440 in section .text of /usr/bin/X


Touchpad is locked into "scrolling". A possible solution is probably to not increase num_active_touches if priv->num_active_touches > priv->num_slots.
But this would obviously not fix the underlying cause (just fix the annoying loss of trackpad).
Comment 21 Jesse Glick 2013-01-10 16:56:26 UTC
FWIW this bug only happens to me when unlocking the screen saver, usually though not always after a resume from suspend. I think it happens when I start typing a password quickly and right away. (The crash does not happen immediately—a few seconds later.)

If I take care to wait a moment until the caret in the password text field is blinking steadily I seem to be able to avoid it. This hypothesis would explain why the crash seems to happen most often when the computer is under load (either from a resume, or because there is a substantial background process like a big compile)—in such cases the screen saver GUI is a little slower to react.

Alternatively it is possible the crash is related to my fingers accidentally brushing the touchpad while typing the password.
Comment 22 Jan Schmidt 2013-01-10 21:25:23 UTC
*** Bug 55821 has been marked as a duplicate of this bug. ***
Comment 23 Peter Hutterer 2013-01-31 06:16:33 UTC
There are suggestions that http://lists.x.org/archives/xorg-devel/2012-October/034149.html helps with this issue, but unconfirmed so far.
Comment 24 Danny 2013-02-02 23:29:07 UTC
My eeepc running mint has suddenly (after an update) also started to exhibit this bug. It is starting to get annoying! I will try the patch mentioned in the coming days (but confirmation can take some time, I only hit this once a week or less).
Comment 25 Danny 2013-02-03 12:50:12 UTC
Hmm, Peter, can you confirm that patch is already in Fedora 18. It seems to have been merged as part of:
* Tue Oct 30 2012 Peter Hutterer <peter.hutterer@redhat.com> 1.13.0-6
- Add touchscreen fixes (including pointer emulation) #871064

So unless it was reverted by a later patch (at 1.13.2-1 now), this is not it (unless these fixes are causing it instead of preventing it, but that is not what you meant is it?)
Comment 26 Peter Hutterer 2013-02-04 04:53:05 UTC
right, that was the one and it hasn't been reverted, it just got integrated into upstream 1.13.1 so we don't need the patch anymore. back to the drawing board.
Comment 27 Jesse Glick 2013-05-14 18:51:25 UTC
Have not yet seen this bug in xserver-xorg-input-synaptics 1.6.2-1ubuntu6 (Raring).
Comment 28 Charles Samuels 2013-05-21 17:04:18 UTC
I'm seeing this on an Lenovo T420. I frequently see it when coming out of hibernation (because my system is still swapping in).

I can "recover" by suspending to memory and then unresponding. At that point the touchpad works again just fine without restarting X.

Debian Wheezy:
xserver-xorg-input-synaptics 1.6.2-2 amd64
Comment 29 Charles Samuels 2014-11-08 06:33:59 UTC
I can still produce this bug on Debian stable. It requires me to run a process that does a lot of random io in a a large file, such that some swap is consumed.

I also had an instance of X crashing as a result:

[ 84441.029] BUG: triggered 'if (priv->num_active_touches > priv->num_slots)'
[ 84441.029] BUG: ../../src/synaptics.c:3122 in UpdateTouchState()
[ 84441.029]
[ 84441.029] Backtrace:
[ 84441.029] 0: /usr/bin/X (xorg_backtrace+0x36) [0x7f9db58fbd16]
[ 84441.029] 1: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7f9dafb48000+0x3067) [0x7f9dafb4b067]
[ 84441.029] 2: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7f9dafb48000+0x4733) [0x7f9dafb4c733]
[ 84441.029] 3: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7f9dafb48000+0x7164) [0x7f9dafb4f164]
[ 84441.029] 4: /usr/bin/X (0x7f9db577d000+0x8d947) [0x7f9db580a947]
[ 84441.029] 5: /usr/bin/X (0x7f9db577d000+0xb1c18) [0x7f9db582ec18]
[ 84441.029] 6: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f9db4aa5000+0xf0a0) [0x7f9db4ab40a0]
[ 84441.029] 7: /lib/x86_64-linux-gnu/libc.so.6 (__select+0x13) [0x7f9db3881293]
[ 84441.029] 8: /usr/bin/X (WaitForSomething+0x190) [0x7f9db58f9150]
[ 84441.029] 9: /usr/bin/X (0x7f9db577d000+0x52bb1) [0x7f9db57cfbb1]
[ 84441.029] 10: /usr/bin/X (0x7f9db577d000+0x41ec5) [0x7f9db57beec5]
[ 84441.029] 11: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xfd) [0x7f9db37c9ead]
[ 84441.029] 12: /usr/bin/X (0x7f9db577d000+0x4219d) [0x7f9db57bf19d]
[ 84441.029]
[ 84441.115] BUG: triggered 'if (priv->num_active_touches > priv->num_slots)'
[ 84441.115] BUG: ../../src/synaptics.c:3122 in UpdateTouchState()
[ 84441.115]
[ 84441.115] Backtrace:
[ 84441.115] 0: /usr/bin/X (xorg_backtrace+0x36) [0x7f9db58fbd16]
[ 84441.115] 1: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7f9dafb48000+0x3067) [0x7f9dafb4b067]
[ 84441.115] 2: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7f9dafb48000+0x4733) [0x7f9dafb4c733]
[ 84441.115] 3: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7f9dafb48000+0x7164) [0x7f9dafb4f164]
[ 84441.115] 4: /usr/bin/X (0x7f9db577d000+0x8d947) [0x7f9db580a947]
[ 84441.115] 5: /usr/bin/X (0x7f9db577d000+0xb1c18) [0x7f9db582ec18]
[ 84441.115] 6: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f9db4aa5000+0xf0a0) [0x7f9db4ab40a0]
[ 84441.115] 7: /lib/x86_64-linux-gnu/libc.so.6 (__select+0x13) [0x7f9db3881293]
[ 84441.115] 8: /usr/bin/X (WaitForSomething+0x190) [0x7f9db58f9150]
[ 84441.115] 9: /usr/bin/X (0x7f9db577d000+0x52bb1) [0x7f9db57cfbb1]
[ 84441.115] 10: /usr/bin/X (0x7f9db577d000+0x41ec5) [0x7f9db57beec5]
[ 84441.115] 11: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xfd) [0x7f9db37c9ead]
[ 84441.115] 12: /usr/bin/X (0x7f9db577d000+0x4219d) [0x7f9db57bf19d]
[ 84441.115]
[ 84442.200] BUG: triggered 'if (priv->num_active_touches > priv->num_slots)'
[ 84442.200] BUG: ../../src/synaptics.c:3122 in UpdateTouchState()
[ 84442.200]
[ 84442.200] Backtrace:
[ 84442.200] 0: /usr/bin/X (xorg_backtrace+0x36) [0x7f9db58fbd16]
[ 84442.200] 1: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7f9dafb48000+0x3067) [0x7f9dafb4b067]
[ 84442.200] 2: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7f9dafb48000+0x4733) [0x7f9dafb4c733]
[ 84442.200] 3: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7f9dafb48000+0x7164) [0x7f9dafb4f164]
[ 84442.200] 4: /usr/bin/X (0x7f9db577d000+0x8d947) [0x7f9db580a947]
[ 84442.200] 5: /usr/bin/X (0x7f9db577d000+0xb1c18) [0x7f9db582ec18]
[ 84442.200]
Comment 30 Charles Samuels 2014-11-08 06:34:55 UTC
Is this bug tracker actually used?
Comment 31 Peter Hutterer 2014-11-08 07:39:25 UTC
Fixes for that are in synaptics 1.8 and 1.7.6. It was caused by missing SYN_DROPPED handling.

You'll need libevdev 1.2 or later, iirc to get rid of the bug in synaptics 1.8.

Otherwise, the commit on the 1.7 branch was: 
http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?h=synaptics-1.7-branch&id=bbaf4d646ebf4393a1ee0eb9bcc569054ed878f9
Comment 32 Adam Jackson 2018-06-13 18:04:26 UTC
*** Bug 54283 has been marked as a duplicate of this bug. ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.