Bug 19222 - Null-pointer dereference in mieqProcessInputEvents
Summary: Null-pointer dereference in mieqProcessInputEvents
Status: RESOLVED DUPLICATE of bug 19048
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Input/Core (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Keith Packard
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: xserver-1.6
  Show dependency treegraph
 
Reported: 2008-12-21 13:13 UTC by Tom Jaeger
Modified: 2009-01-12 00:36 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
patch (735 bytes, patch)
2009-01-01 09:24 UTC, Tom Jaeger
no flags Details | Splinter Review
A more integrated patch (1.29 KB, patch)
2009-01-04 10:23 UTC, Colin Guthrie
no flags Details | Splinter Review
0001-mi-Fix-segv-on-CopyKeyClass-19222.patch (1.42 KB, patch)
2009-01-11 22:59 UTC, Peter Hutterer
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Jaeger 2008-12-21 13:13:03 UTC
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'}
Comment 1 Peter Hutterer 2008-12-21 22:46:19 UTC
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).
Comment 2 Tom Jaeger 2008-12-22 10:01:26 UTC
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...
Comment 3 Colin Guthrie 2009-01-01 08:53:53 UTC
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).
Comment 4 Tom Jaeger 2009-01-01 09:24:49 UTC
Created attachment 21617 [details] [review]
patch

This is what I've been using so far.
Comment 5 Colin Guthrie 2009-01-04 10:23:07 UTC
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.
Comment 6 Peter Hutterer 2009-01-04 19:39:46 UTC
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.
Comment 7 Colin Guthrie 2009-01-05 01:24:16 UTC
(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 :)
Comment 8 Peter Hutterer 2009-01-11 22:59:00 UTC
Created attachment 21891 [details] [review]
0001-mi-Fix-segv-on-CopyKeyClass-19222.patch

updated patch with reference to bug report.
Comment 9 Peter Hutterer 2009-01-12 00:36:07 UTC
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.