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.

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

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?

correction, I tried reproducing with 1.12.1.902, i.e. the same version as listed in the original comment.

(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

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.

(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 ;)

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

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?

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

*** Bug 53686 has been marked as a duplicate of this bug. ***

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

Thanks! that really helped finding the issue

http://patchwork.freedesktop.org/patch/11873/

thanks for the patch, fixed it for me!

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)

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]

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.

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

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.

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

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.

*** Bug 55821 has been marked as a duplicate of this bug. ***

There are suggestions that http://lists.x.org/archives/xorg-devel/2012-October/034149.html helps with this issue, but unconfirmed so far.

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

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

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.

Have not yet seen this bug in xserver-xorg-input-synaptics 1.6.2-1ubuntu6 (Raring).

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

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]

Is this bug tracker actually used?

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

*** Bug 54283 has been marked as a duplicate of this bug. ***