Bug 45445 - Key press crashes the xserver when kdm is running
Summary: Key press crashes the xserver when kdm is running
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Input/Core (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: high critical
Assignee: Peter Hutterer
QA Contact: Xorg Project Team
Whiteboard: 2012BRB_Reviewed
Keywords: regression
Depends on:
Blocks: xserver-1.12
  Show dependency treegraph
Reported: 2012-01-31 06:21 UTC by mathieu.taillefumier
Modified: 2016-11-28 04:39 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Results of the incomplete bisection (8.53 KB, application/octet-stream)
2012-01-31 06:21 UTC, mathieu.taillefumier
no flags Details
git log (2.12 KB, text/plain)
2012-01-31 06:22 UTC, mathieu.taillefumier
no flags Details
gdb log (5.25 KB, text/plain)
2012-01-31 06:23 UTC, mathieu.taillefumier
no flags Details
result of the second bisection (1.67 KB, text/x-log)
2012-02-03 04:30 UTC, mathieu.taillefumier
no flags Details

Description mathieu.taillefumier 2012-01-31 06:21:45 UTC
Created attachment 56386 [details]
Results of the incomplete bisection

When kdm is running and at the login window, pressing any key on the keyboard crashes the server with a segmentation fault. This problem is 100% reproducible and does not appear when the X server is run from the console.

A debug session from a remote computer originated the crash from the function EventIsDeliverable and the cause of the crash is an invalid address (see gdb.txt for more informations). 

A bisection using git bisect showed that the bug was introduced between xorg-server- and xorg-server- I was unable to finish the bisection because of compilations issues three steps before the end of the bisection (the log is in bisection.results). 

218752bdc5d9323d1e6202e762573a925cf8a4eb is the first bad commit

commit 218752bdc5d9323d1e6202e762573a925cf8a4eb
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Dec 8 14:27:01 2011 +1000

    input: replace GRABTYPE_* with the InputLevel enums
    They achieve the same thing, re-use the more generic InputLevel so we can
    convert to/fro easier.
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Reviewed-by: Chase Douglas <chase.douglas@canonical.com>

:040000 040000 da796c2c9bd3069c1f18e3c48377165047cff9dc 2643d9e30b18576e2cb4de583414222929a3c89b M      Xi
:040000 040000 48dd6c197d484fb833108142a78bd3312563b706 c74546e6f4cff43cd2f3aa5feb90355f2f537a20 M      dix
:040000 040000 f5a5a63f4ac1e997c58b2012f8007cac17f5eb12 ec574d564571670a0167304cedbeee0c649c083d M      include
:040000 040000 de23b6d8bae38ba7944f75c1e0b13a7e0065e719 bd0b61a1ea13e5d8ceef5d18acbdd11b74867e59 M      test

The commits I was unable to test are all related to Xinput.
Comment 1 mathieu.taillefumier 2012-01-31 06:22:41 UTC
Created attachment 56387 [details]
git log
Comment 2 mathieu.taillefumier 2012-01-31 06:23:36 UTC
Created attachment 56388 [details]
gdb log
Comment 3 mathieu.taillefumier 2012-02-03 04:30:18 UTC
Created attachment 56572 [details]
result of the second bisection
Comment 4 Peter Hutterer 2012-06-13 22:29:58 UTC
is this still an issue with 1.12?
Comment 5 Jan de Groot 2012-07-10 09:00:03 UTC
I've seen crashes like these on systems where X is started during the init process on a free TTY that is taken by agetty later in the boot process. X puts the TTY in raw mode thanks to evdev, agetty does something else to the TTY and as soon as you press enter, X will crash. After that it works fine, as kdm/gdm will launch X on tty8 instead.
Comment 6 Peter Hutterer 2016-11-28 04:39:46 UTC
This is a mass change of bugs. Bugs assigned to me that haven't been updated in the last 3 years are closed as WONTFIX, because, well, let's at least be honest about it.

Please do not re-open unless you have a really good reason to do so (e.g. you're fixing it yourself). If it hasn't been fixed in the last 3 years, it probably won't be fixed anytime soon either. Sorry.

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.