syndaemon consumes 100% CPU

I have the exact same problem but only as soon as I plug a USB Mouse...

My laptop boots fine or runs fine, as well as my ClickPad (I have a HP Envy with this new type of touchpad) as long as I have my usb mouse unplugged.

If I have my USB Mouse plugged in at boot or plug it afterwards, syndaemon goes 100% CPU.

Hope this information helps!

Hy!

I have the same problem, but still can't find what triggers it :(

I just tryed to remove my usb mouse and reconnect it, but syndaemon now behaves normally...
I always notice that my system is slow and check that syndaemon is runing 100% after continous work without sleep and mouse plug/unplug..

The same issue. 100% cpu usage. Haven't seen it before.

Testing Natty by booting from a USB stick. I have syndeamon running at close to 100% (noticed because the fan got loud).

Happens right after boot every time. Have to end the process. No USB mouse connected. Happens on a Dell XPS Studio 16 Laptop.

It uses 100% cpu on my laptop either after logging in or after resume, and I don't think it's related to whether I have a USB mouse plugged in (syndaemon is supposed to monitor the keyboard and disable the touchpad when you're typing).

I've (hopefully) turned it off now via the setting "control centre / mouse / touchpad / disable touchpad while typing".

I think the priority of this bug should be raised as it could cause notebooks to overheat if the syndaemon process is not killed manually by the user (some users won't know how to do this).

Thanks Jonathan. After killing the process (syndaemo) the CPU usage goes back to normal, and I don't notice any functional difference. My usb mouse and touchpad both function normally.

Same problem on my HP EliteBook 6930p, and it's really annoying.
Anyone found a solution to fix this?
Ubuntu Natty 11.04 b1

The workaround for the moment is to remove the option to stop the touchpad whole typing (somewhere in the mouse options... sorry I'm not in front of my pc at the moment).

The other workaround is to kill the daemon as soon as it goes crazy :)

But these are no solutions, just workaround...

Also experiencing this on a Toshiba L655 with the daily build of 11.04.

Same problem here.
My laptop was really shouting before I suspect that syndaemon eats my CPU.

The same issue. 100% cpu usage.

strace shows:
select(5, [4], NULL, NULL, NULL) = 1 (in [4])
select(5, [4], NULL, NULL, NULL) = 1 (in [4])
select(5, [4], NULL, NULL, NULL) = 1 (in [4])
select(5, [4], NULL, NULL, NULL) = 1 (in [4])
select(5, [4], NULL, NULL, NULL) = 1 (in [4])
select(5, [4], NULL, NULL, NULL) = 1 (in [4])
[...]

sometimes it starts when I am on battery.

It would be helpful if someone could get a backtrace of syndaemon while it's stuck. First, install xserver-xorg-input-synaptics-dbgsym. To install it, do one of the following:

* Enable the ddebs repository:
  $ sudo add-apt-repository deb http://ddebs.ubuntu.com/ natty main
  $ sudo apt-get update
  Install the package:
  $ sudo apt-get install xserver-xorg-input-synaptics-dbgsym
Or
* Install the package manually from http://ddebs.ubuntu.com/pool/main/x/xserver-xorg-input-synaptics/

Now, when syndaemon gets stuck, do the following:

Determine the PID of syndaemon (there's probably a better way, but this works):
$ ps x | grep syndaemon | grep -v grep | cut -f 1 -d ' '
Use gdb on the process
$ gdb /usr/bin/syndaemon <PID>
Inside gdb, run the command "backtrace". Copy the output and paste it here.

Thanks!

Hi Chase,

Here's the trace from my machine:

0x00007fc4f72dc123 in select () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) backtrace
#0 0x00007fc4f72dc123 in select () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x0000000000401c3d in record_main_loop (display=<value optimized out>, idle_time=0.5)
    at ../../tools/syndaemon.c:408
#2 0x00000000004021fd in main (argc=<value optimized out>, argv=<value optimized out>)
    at ../../tools/syndaemon.c:601
(gdb)

Oh and the versions are:

xserver-xorg-input-synaptics 1.3.99+git20110116.0e27ce3a-0ubuntu11
xserver-xorg-input-synaptics-dbgsym 1.3.99+git20110116.0e27ce3a-0ubuntu11

I get a very similar traceback. It's not very illuminating!

I've uploaded an amd64 test package to http://people.canonical.com/~cndougla/test/. I would like to have someone install it and then run syndaemon manually:

$ killall syndaemon
$ syndaemon -i 0.5 -k -R

When the bug is triggered, it should hopefully print out some debug messages. Please let me know what you see.

Thanks!

Tried this. The bug is triggered but the output is completely silent…

Tried also with "-v". Before going to sleep:

$ syndaemon -i 0.5 -k -R -v
X RECORD extension version 1.13
Disable
Enable
enable touchpad
                                                                    ← sleep and resume
^C

There were no messages after resume, the daemon didn't react on key presses.

This bug annoys me greatly.

Tried your package as well. It remains silent. No debug output at all.

I don't know which changes you tried, but I've tried putting some printf() hooks within xrecord_callback(), e.g.:

    cbres = (struct xrecord_callback_results *)closure;

    int check = recorded_data->category != XRecordFromServer;

    static int i=0;
    printf("event %d [%d]!\n", i++, check);

    if (recorded_data->category != XRecordFromServer) {

This code path, under normal operation, is supposed to be called. When the process is spinning, it seems to not enter xrecord_callback() at all. The events received are not key events, as is visible from this gdb extract (I compiled the package with -g):

(gdb) fin
Run till exit from #0 0x00007f187e3ab123 in __select_nocancel ()
    at ../sysdeps/unix/syscall-template.S:82
0x0000000000401fb2 in record_main_loop (display=0x140b010, idle_time=0.5)
    at ../../tools/syndaemon.c:413
413 ret = select(fd+1 /* =(max descriptor in read_fds) + 1 */,
(gdb) n
417 if (FD_ISSET(fd, &read_fds)) {
(gdb)
419 cbres.key_event = 0;
(gdb)
420 cbres.non_modifier_event = 0;
(gdb)
422 XRecordProcessReplies(dpy_data);
(gdb)
424 if (!ignore_modifier_keys && cbres.key_event) {
(gdb) p cbres
$1 = {modifiers = 0x1418ae0, key_event = 0, non_modifier_event = 0,
  pressed_modifiers = '\000' <repeats 15 times>}
(gdb) n
428 if (cbres.non_modifier_event &&
(gdb)
434 if (disable_event) {
(gdb) p disable_event
$2 = 0
(gdb) p pad_disabled
$3 = 0

I'll keep hunting a bit.

E.

Is this related?

https://bugzilla.redhat.com/show_bug.cgi?id=670039

No it's not, unfortunately. The current xcb_io.c matches the one in the git repository, which has the relevant patch applied.

There still seems to be something quite fishy going on with XRecord and async events. I don't know much of it underneath, so my understanding might be quite bad. Here are some random thoughts.

The problem is that there is an event queue which fills up and is never drained by the application. Here, the culprit event has code 34, which is X_UngrabKey. Despite the hint, this is not related to the screen saver, since ``echo mem > /sys/power/state'' reaches the same situation.

Once this event is on top of the queue, it is _never_ processed by the application. Probably because the XRecord context doesn't want it (there's an event range passed to the async context constructor).

I don't know why this event shows up here. Here's a dump of the event which reaches the end of handle_response in xcb_io.c (libX11), just before _XEnq:

0000: 22 20 0b 00 01 08 f8 00 90 94 c6 a9 ff 7f 00 00
0010: f3 00 00 00 00 00 00 00 4d 44 50 00 00 00 00 00

This is never eaten by the application.

The xcb_io.c source file is in sync with the git HEAD.

Emmanuel,

The XRecord library is in libXtst. In its async handler (record_async_handler), there's no checking of the X reply type other than to check whether it's an error or not. If it gets a non error reply, then it assumes it's a record reply without actually checking. This will cause undefined execution once we get to parse_reply_call_callback.

The next step would be to add a check in record_async_handler to determine if the reply is really an xrecord reply. If not, just toss it and move on. I'll make a test package for this in a bit, but it's end of day for me so someone may beat me to the punch :).

Also, this means there's a second bug that likely resides in the server. An X record client shouldn't be receiving any replies other than XRecord replies.

So what I wrote before isn't quite correct. I believe libXtst is working alright, but an event gets stuck in the queue, as Emmanuel noted. I have added a bit of code to syndaemon to check for any left over events after all replies have been handled. Any events found are discarded.

Please test the new synaptics package available at http://people.canonical.com/~cndougla/test/.

Thanks!

This indeed fixed the problem! After resume syndaemon doesn't saturate the CPU and blocks touchpad when typing as expected.

Thanks!

Ivan,

I'm glad this fixes the hung process issue for you. However, it shows there is also a bug somewhere else in the stack. Please kill the running syndaemon process and run it manually:

$ killall syndaemon
$ syndaemon -v -i 0.5 -k -R

When you hit the bug, it should print out a message about a bad event. Please paste the output here.

Thanks!

Sorry, I didn't keep a close eye on your discussion with Emmanuel and thought that ignoring unneeded events was the correct fix. Anyway here's the output:

$ syndaemon -v -i 0.5 -k -R
X RECORD extension version 1.13
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
bad event received, major opcode 34
Disable
Enable
enable touchpad

All those "bad event" appearing after resume.

Ok, this confirms what Emmanuel was seeing. At this point, I don't think I can easily debug the issue remotely, and I can't seem to trigger it on my systems. I'll push the workaround patch to Ubuntu, but I'm hoping someone else will be able to come along and debug it some more.

If some X.org hacker lives near Seattle I could bring my laptop for a debugging/coffee drinking session :-)

I have similar problem on my vaio z11vrn

This bug was fixed in the package xserver-xorg-input-synaptics - 1.3.99+git20110116.0e27ce3a-0ubuntu12

---------------
xserver-xorg-input-synaptics (1.3.99+git20110116.0e27ce3a-0ubuntu12) natty; urgency=low

  * syndaemon: Drain spurious events from XRecord connection as a work around
    for a buggy X server. This keeps syndaemon from busy looping
    (LP: #754470)
 -- Chase Douglas <email address hidden> Thu, 14 Apr 2011 14:15:33 -0400

Should this be marked as fixed, since this solution is only a work around?

Same issue on my laptop. And it's of the kind which does harm to one's hardware.
It may overheat the laptop if one doesn't notice or know how to stop the crazy
syndaemon. Also, I don't quite understand what this daemon does in my system.
My touchpad is always recognized as a wheel mouse with the scrollbar not working,
so that It still works even ifI disable the "touchpad" in the mouse configuration GUI.

You should try: killall syndaemon in terminal.

I just installed the new package. No spinning syndaemon in sight, syndaemon is working perfectly.

xserver-xorg-input-synaptics:
  Installed: 1.3.99+git20110116.0e27ce3a-0ubuntu12
  Candidate: 1.3.99+git20110116.0e27ce3a-0ubuntu12
  Version table:
 *** 1.3.99+git20110116.0e27ce3a-0ubuntu12 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty/main amd64 Packages
        100 /var/lib/dpkg/status

I have a notebook Fujitsu-Siemens AMILO Pro V3205 and I observe that 100% of CPU (one full processor core) is consumed by process called syndaemon. Electric power consumption is pretty big.

OS: Ubuntu 11.04 beta 2 32-bit
The machine has an Intel 945 GM chipset.
I am logged into Ubuntu "no effects" (classic GNOME) desktop environment.

It's not really a fix. Merely a paper wrap.

The bug seems to reside elsewhere, and might possibly affect other apps. IMO it's important to do more work. I will not personally have time to devote to this, however (despite the fact that I can reproduce the bug).

It seems daemons are invading launchpad... syndaemons ?

I do not think that it was mentionned earlier: I also get 100% after switching to console (with -R)

I also get 100% cpu when I start syndaemon from ~/.xprofile or from the gnome startup applications.