Bug 952221

Thanks for opening a new bug. This seem to be a different problem than 908604.

I was not able to reproduce it with a hid recording of the magic trackpad on a fedora i386.PAE, so I will need more information from you.

Can you post the dmesg output after the kde crash, the Xorg.0.log.old and also an evemu trace of your 2 finger tap which kills kde:
http://www.freedesktop.org/wiki/Evemu

I am trying to generate the requested evemu trace, but I get this error:
error: this device is grabbed and I cannot record events

There is some mention of this on the freedesktop Evemu wiki page, but I'm not sure what exactly I should add where to prevent the device from being grabbed.

Can you give me some more details on how I can proceed ? Thank you.

> Can you give me some more details on how I can proceed ? Thank you.
>

You just need to write a file named 99-synaptics-dontgrab.conf in
/etc/X11/xorg.conf.d/ which contains:
Section "InputClass"
        Identifier "Don't grab synaptics"
        MatchDriver "synaptics"
        Option "GrabEventDevice" "off"
EndSection

then restart X, and the complain about the grab should disappear.

Created attachment 736041 [details]
Output of evemu-describe

Created attachment 736042 [details]
Output of evemu-record

Created attachment 736043 [details]
dmesg output right after kde session abort

Created attachment 736045 [details]
Xorg.0.log.old right after kde session abort

While I had a 100% abort rate when using kde normally, I had some more difficulties deliberately triggering the abort. That is, during normal usage I was avoiding the two-finger click because I knew it would abort my session. Each time I accidentally did use it anyway, my session aborted.

However that was not the case while I was trying to record the events during an abort. Simply two-finger clicking on the desktop nicely popped up the desktop's context menu.

After a little fiddling, I (almost) consistently could trigger the abort in two steps:
- two-finger click anywhere on the desktop background
- single finger click to discard the context menu
- right after that, two-finger click in the display folder plasmoid that is on the desktop
=> abort

The evemu-record session records exactly that. Hopefully that is sufficient for you to find the cause of these aborts.

can you check your xorg.logs for any backtrace please? the one you attached looks like one from a running session.

In addition to Peter's request:

I can not reproduce it on x86_64, so it's a i686 issue only.

The bug can be easily reproduced in a i686 F18 (PAE or not, even in a VM) with the two given files evemu-device.txt and evemu-record.txt: just run evemu-play and it crashes the session without backtraces nor kernel oops.

Created attachment 736427 [details]
Screenshot of system crash

I didn't find any backtrace in my log files.

However, today I got into this situation that allowed me to take a picture of a system crash that may be related.

While working on my PC normally, I accidentally brushed the touchpad with a second finger while clicking it. The touchpad immediately stopped responding, but the screen didn't. I could still use the spare mouse I had attached as well.

In an attempt to wake up the touchpad I clicked it (perhaps a couple of times). The next thing I got was the system crash attached here.

I don't have any evemu recordings of this unfortunately.

Note that the mouse pointer was still responding to the spare mounse (I could move it around), but that is all. I could not do a soft reboot via the keyboard. I had to use the reset button on my PC.

Hopefully this gives another hint.

The screenshot you gave show a bug in the hidp module, the module which drives hid devices over bluetooth. So even if it's still a kernel oops, it's not related to your primary problem. In addition, David Herrmann did a rework on the hidp module recently[1] and I hope this will fix this oops.

To go back to our bug:
- the bug is not related to kde, gnome is also crashing in the same way
- the component which is crashing is X, but it crashes silently: no backtraces and freeze of the system if startx is run from a tty.

I'd like to see the differences from the 3.6 and the 3.7 when you manage to trigger the bug.
For that, I'll need you to use hid-replay[2] to record the raw events sent by the device. However, instead of using the packages on [2], please use this scratch-build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5259242
The package on [2] will not record anything from the magic trackpad.

So basically, run your current kernel (3.8.7 or 3.8.6). Record the magictrackpad HID events. Trigger the crash. If the trace is correctly recorded, I'll be able to compare the output of both 3.6 and 3.7 kernels.
If there is a doubt that some events are missing in the end, please run hid-recorder from a tty, go back to X and trigger the bug.


[1] http://article.gmane.org/gmane.linux.bluez.kernel/35137
[2] http://bentiss.github.io/hid-replay-docs/

Created attachment 737695 [details]
Crash while two-finger clicking recorder with hid-recorder

I have downloaded and installed the hid-recorder tool from the scratch build, installed it and started in on a separate VT.

Next I switched back to X, and made it to crash. Attached is what hid-recorder recorded. My kernel is currently 3.8.7-201.fc18.i686.PAE.

Note that I had a few clicks before it actually crashed:
I started with a two-finger click in a konsole window. This just showed me the context menu. So I single clicked to close the context menu and then had some more single clicks to hide two open windows.
The next two-finger click was on the desktop, working fine. Then I followed with a single click to hide the context menu again.
The last two-finger click was in the show folder plasma widget again, which successfully crashed the X server.

Thanks for the logs.

There is no difference, between 3.6 and 3.8 outputs. This comes definitively from X.

I suspect a rebuild of the package is enough to solve the problem (at least, on my virtual i386). When running under gdb, I got a stack smash in xf86-input-synaptics...

Can you give a test to the following scratch build?
http://koji.fedoraproject.org/koji/taskinfo?taskID=5286588

Installed xorg-x11-drv-synaptics-1.6.3-2.fc18.i686 and rebooted the system (perhaps logging out would have been sufficient).

Unfortunately, the crash still happens.

ok. Well, I can also reproduce it, and still did not found the cause of it.

Changing the component to xorg-x11-drv-synatics because the bugs comes from there.

Created attachment 739981 [details]
Evemu reproducer for the bug

Ok, I managed to get the most simple reproducer.

Actually, the problem is indeed a stack smash.
I built a new package here (you may need to use yum reinstall as I kept the same build number than the previous scratch-build):
http://koji.fedoraproject.org/koji/taskinfo?taskID=5302191

Can you please test it?

I have installed your most recent build.

Two finger clicking seems to work properly now. I haven't been able to make it crash again.

Good job ! Thank you.

xorg-x11-drv-synaptics-1.6.3-3.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/xorg-x11-drv-synaptics-1.6.3-3.fc18

xorg-x11-drv-synaptics-1.7.0-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/xorg-x11-drv-synaptics-1.7.0-2.fc19

Package xorg-x11-drv-synaptics-1.7.0-2.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xorg-x11-drv-synaptics-1.7.0-2.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-6689/xorg-x11-drv-synaptics-1.7.0-2.fc19
then log in and leave karma (feedback).

xorg-x11-drv-synaptics-1.7.0-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

xorg-x11-drv-synaptics-1.6.3-3.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.