Bug 5970

Created attachment 4682 [details] [review]
The fix

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!? 
 

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.

Changed the summary to get the attention of people who care about setxkbmap
(which is probably more than those who care about Matrox cards).

(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)

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. 

committed to HEAD, 1.0.2 rolled

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 @@
 Bool
 getServerValues(void)
 {
-XkbRF_VarDefsRec 	vd;
+XkbRF_VarDefsRec 	vd = {0};
 char *			tmp= NULL;
 
     if (!XkbRF_GetNamesProp(dpy,&tmp,&vd) || !tmp) {

er, fwiw, I also initialised .variant to 0 explicitly.

per c#9