These have happened to me a lot recently when testing easystroke, but they either occur early in the session or not at all. Not sure where the event comes from, this happens at a time when XAllowEvents(dpy, AsyncPointer) is called on a GrabModeSync core grab and there's also a GrabModeAsync XInput grab being released. For now, I've added a check for master before calling CopyKeyClass. ---- Program received signal SIGSEGV, Segmentation fault. CopyKeyClass (device=0x9833000, master=0x0) at ../../Xi/exevents.c:201 201 mk = master->key; (gdb) bt #0 CopyKeyClass (device=0x9833000, master=0x0) at ../../Xi/exevents.c:201 #1 0x08112137 in mieqProcessInputEvents () at ../../mi/mieq.c:361 #2 0x080c0e27 in ProcessInputEvents () at ../../../../hw/xfree86/common/xf86Events.c:174 #3 0x0808ce36 in Dispatch () at ../../dix/dispatch.c:399 #4 0x08071b6d in main (argc=10, argv=0xbf97cf14, envp=Cannot access memory at address 0x8 ) at ../../dix/main.c:383 (gdb) print master $1 = (DeviceIntPtr) 0x0 (gdb) up #1 0x08112137 in mieqProcessInputEvents () at ../../mi/mieq.c:361 361 CopyKeyClass(dev, master); (gdb) print dev->isMaster $2 = 1 (gdb) print event->u.u.type == DeviceKeyPress $5 = 1 (gdb) print event->u.keyButtonPointer $6 = {pad00 = 9550, time = 2072921, root = 0, event = 0, child = 0, rootX = 655, rootY = 366, eventX = 0, eventY = 0, state = 0, sameScreen = 0 '\0', pad1 = 1 '\001'}
hmm. looks like the path you're triggering is feeding events into mieqProcessInput events that are directly by the master device. I think XTest does that in some cases, can you check dix/events.c ProcAllowEvents if there is a similar case (events generated directly on the master device).
Oh my god, I'm retarded. This has (in my case) nothing to do with pointers at all. What happens is that the application calls XTestFakeKeyEvent after a successful gesture, and if no physical key has been pressed yet during that session, then the master device is the only availabe keyboard, which XTest will use. Now I had to set a breakpoint in mieqEnqueueEvent to figure that out...
This seems to be hitting my packages too. Any patch to fix yet (nothing it attached here but I get the feeling it's been worked around already).
Created attachment 21617 [details] [review] patch This is what I've been using so far.
Created attachment 21653 [details] [review] A more integrated patch Thanks for pointing the way :) I've attached a slightly more integrated patch that groups things up a bit more nicely. It's functionally the same.
I noticed that it depends on commit 0b4fef6337d88ae8ef05b8b73941350a9007565c Author: Peter Hutterer <peter.hutterer@who-t.net> AuthorDate: Wed Dec 10 11:35:09 2008 +1000 dix: move MAX_VALUATOR_EVENTS into include/input.h Other than that, I think the patch is fine. The MD should have everything set up as it is, so missing the CopyKeyClass shouldn't do anything afoul. For the future, please include a reference to the bug number in your commit message (I'd appreciate it if you could upload an updated patch for this) Keith, reassigning to you for pushing onto 1.6.
(In reply to comment #6) > I noticed that it depends on > > commit 0b4fef6337d88ae8ef05b8b73941350a9007565c > Author: Peter Hutterer <peter.hutterer@who-t.net> > AuthorDate: Wed Dec 10 11:35:09 2008 +1000 > > dix: move MAX_VALUATOR_EVENTS into include/input.h Ahh yes, sorry I should have noted that here too. I already edited the 1.6 merge wiki page to reflect this :)
Created attachment 21891 [details] [review] 0001-mi-Fix-segv-on-CopyKeyClass-19222.patch updated patch with reference to bug report.
As mentioned in Bug 19048 it doesn't really make sense to have a bugreport on top of an uncommited patch in another bugreport. I'm closing this one as a dupe and I merged Colin's patch into the fix for 19048. Thanks for the patch, Colin. *** This bug has been marked as a duplicate of bug 19048 ***
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.