Bug 5970 - setxkbmap causes segmentation fault
Summary: setxkbmap causes segmentation fault
Alias: None
Product: xorg
Classification: Unclassified
Component: App/other (show other bugs)
Version: 6.9.0
Hardware: x86 (IA32) Linux (All)
: high critical
Assignee: Xorg Project Team
QA Contact:
URL: http://qa.mandriva.com/show_bug.cgi?i...
Keywords: patch
Depends on:
Blocks: 5799
  Show dependency treegraph
Reported: 2006-02-20 19:19 UTC by Jaroslav Tulach
Modified: 2006-04-22 08:11 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

The fix (384 bytes, patch)
2006-02-20 19:20 UTC, Jaroslav Tulach
no flags Details | Splinter Review

Description Jaroslav Tulach 2006-02-20 19:19:48 UTC
There is a bug in setxkbmap which can cause segmentation fault. The problem is 
described at http://qa.mandriva.com/show_bug.cgi?id=20999 
and I am going to attach a fix for it.
Comment 1 Jaroslav Tulach 2006-02-20 19:20:48 UTC
Created attachment 4682 [details] [review]
The fix
Comment 2 Jaroslav Tulach 2006-03-09 19:01:06 UTC
I've raised a severity a bit as this bug prevents me from using binaries distributed as 
RPMs - I always need to compile my own. 
Given the fact that the fix is known some of the owners might try to look at this issue 
and apply the patch!? 
Comment 3 Mike A. Harris 2006-03-09 19:32:16 UTC
X.Org developers are volunteers by nature, they're not paid to do this.

There is _nobody_ who sits all day scouring through bugzilla hunting for
new bugs to volunteer to spend time on all day every day.  Bugs get looked
at generally whenever someone has spare time and feels like looking at new
bugs and taking a shot at fixing them.

Being demanding and rude to volunteers isn't going to win you a solution
any sooner.  You get much further with honey than with guns.

Aside from that, the monolithic X.Org is no longer actively maintained,
as the switch has now been made to modular X11R7.  Granted the bug probably
exists in both, since they're the same source, but 6.9.0 as the version in
the bug report is less likely to get reviewed IMHO.

Comment 4 Alan Coopersmith 2006-03-10 02:53:37 UTC
Changed the summary to get the attention of people who care about setxkbmap
(which is probably more than those who care about Matrox cards).
Comment 5 Mike A. Harris 2006-03-10 03:59:44 UTC
(In reply to comment #4)
> Changed the summary to get the attention of people who care about setxkbmap
> (which is probably more than those who care about Matrox cards).

Hehe, yeah the rather useless summary line of the original report could have
a negative affect on how long before someone examined it. ;o)
Comment 6 Jaroslav Tulach 2006-03-10 16:28:14 UTC
Thank you for your reactions and changes to the bug description. Yes, segfault 
is better summary. 
I am sorry I have not provided that myself, or did other things in wrong way, I 
am just an outsider, and I do not know habits of your project. I just want my 
fix to get in. 
Comment 7 Daniel Stone 2006-03-10 20:08:35 UTC
committed to HEAD, 1.0.2 rolled
Comment 8 sqweek 2006-03-26 16:07:02 UTC
This fix probably eliminates the chance of segfaulting, but the code is still dodgy.

The reason for the segfault is attempted modification of the uninitialised
vd.options field of the XkbRF_VarDefsRec structure. Forcing vd.options to NULL
works as that is the only part of the struct actually modified, but I still see
a problem wrt accessing the uninitialised vd.variant.

It looks as though there's an assumption in the code that the struct is
initialised via a call to XkbRF_GetNamesProp - HOWEVER, there are circumstances
which cause XkbRF_GetNamesProp to abort before clearing the XkbRF_VarsDefsRec
struct (for example, if it can't get the default XKB keymap from the X server?).

I'm not familiar enough with X libraries to know the canonical solution here -
it might be to ensure XkbRF_GetNamesProp (from libxkbfile/maprules.c) ALWAYS
clears the return structure - but the simplest fix is to just initialise the
struct to zero:

--- setxkbmap.c.orig	2004-04-24 03:54:37.000000000 +0800
+++ setxkbmap.c	2006-03-25 21:41:39.000000000 +0800
@@ -460,7 +460,7 @@
-XkbRF_VarDefsRec 	vd;
+XkbRF_VarDefsRec 	vd = {0};
 char *			tmp= NULL;
     if (!XkbRF_GetNamesProp(dpy,&tmp,&vd) || !tmp) {
Comment 9 Daniel Stone 2006-03-26 16:50:51 UTC
er, fwiw, I also initialised .variant to 0 explicitly.
Comment 10 Daniel Stone 2006-04-23 01:11:55 UTC
per c#9

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.