Bug 41149

I think this is caused by a keyboard device sending pointer events (shouldn't happen in the WarpPointer path, but...). See Bug 38313.

http://lists.freedesktop.org/archives/xorg-devel/2011-September/024946.html, still waiting for reviews.

Still happens with the two-screen-coordinates branch so I guess it's not that.

(In reply to comment #2)
> Still happens with the two-screen-coordinates branch so I guess it's not that.

can you get me a stacktrace with debug symbols? I also need to see pDev->name when this happens, xinput list --long and your xorg.conf (if you have any).

Created attachment 52040 [details]
stack trace with device name

Created attachment 52041 [details]
device list

Is this new to 1.11?

I think the first crash was with 10.4 but I am not sure.

I did not try old X servers.

With 1.10.4 this issue is present. It's as old as I can get on this hardware, older X servers would not run on the graphics card.

With X server 1.11.99.902 (1.12.0 RC 2)

I get this log:

==26003== Invalid read of size 4
==26003==    at 0x170265: GetPointerEvents (getevents.c:1494)
==26003==    by 0x17076C: QueuePointerEvents (getevents.c:1203)
==26003==    by 0x1A6F5C: xf86PostButtonEvent (xf86Xinput.c:1174)
==26003==    by 0xD1D1E67: EvdevReadInput (evdev.c:945)
==26003==    by 0x196886: xf86SigioReadInput (xf86Events.c:298)
==26003==    by 0x1BC1BD: xf86SIGIO (sigio.c:109)
==26003==    by 0x56D502F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.13.so)
==26003==    by 0x69223E0: __select_nocancel (syscall-template.S:82)
==26003==    by 0x28D7AA: WaitForSomething (WaitFor.c:232)
==26003==    by 0x15A791: Dispatch (dispatch.c:366)
==26003==    by 0x1499E9: main (main.c:287)
==26003==  Address 0x60 is not stack'd, malloc'd or (recently) free'd

poking around a bit it seems that pressing the "Desktop Lock" button on my keyboard causes mouse button press on a keyboard device.

In GetPointerEvents valuator is dereferenced which is NULL on a keyboard leading to this crash.

So either valuators should be defined on a keyboard (and generally keyboards and mice should be interchangeable even if there are separate functions for them) or there needs to be a guard against queuing button events on a keyboard.

Note that xinput lists the keyboard twice, once with buttons and once without, both attached as keyboard. I suspect this is the root cause of the issue. It looks like at some point something tried to create a mouse device for the multimedia buttons of the keyboard but created another keyboard instead.

Tried to swap the order in which device types are assigned in evdev.

I get 
(**) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Device: "/dev/input/event1"
(--) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Vendor 0x4b3 Product 0x301b
(--) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Found 12 mouse buttons
(--) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Found keys
(II) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Configuring as keyboard
(II) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Configuring as mouse

That is, the device is first assigned the keyboard type and it is then overwritten with the mouse type, not the other way around.

However, even then X happily connects it to core keyboard and crashes whenever the lock desktop key is pressed.

Created attachment 57593 [details]
X log (note two keyboards, one is physically attached)

Created attachment 57712 [details]
evdev patch to configure keyboard with mouse buttons as mouse

There is something seriously flawed.

Applying this evdev patch the part of the keyboard with buttons is configured as mouse, it no longer shows the xkb options in the log.

However, xinput still lists both attached as slave keyboards.

did you try the fix for #38313?
http://patchwork.freedesktop.org/patch/9199/

the stacktrace from comment 4 suggests it's the same issue.

Created attachment 57777 [details] [review]
patch for 1.11.3.901

This similar patch avoids the crash on 1.11.3.901 which builds for me.

Note that on 1.11.3.901 before the input changes it is required to lock the screen with xscreensaver (grab pointer/keyboard ?) to get the crash. On 1.12 it crashes always.

Comment on attachment 57777 [details] [review]
patch for 1.11.3.901

Review of attachment 57777 [details] [review]:
-----------------------------------------------------------------

looks ok in principle but needs better integration. e.g. in the first hunk that whole function can skip altogether if !dev->valuator.
also, git-formatted patches please.

Created attachment 57809 [details] [review]
patch for 1.11.4

Thanks for your review.

I am not sure what exactly the function is doing, just added some guard against dereferencing nonexistent values.

Indeed, the X server reports that the event was ignored with the patch applied so I guess it is OK  to do nothing at all.

Attaching a git format patch.

Created attachment 57810 [details] [review]
updated patch for 1.11.4

Looking at the patch again it seems the axis number checks should be different.

They are not used in my case because the valuator is missing completely so don't have testing for those.

Please send your patch to xorg-devel for discussion.

fixed in 472c2d1af75d8e321728589e377f73116adb29fa and 88c767edb01ed7efb19ffe3a453e16107b27130b