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.
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
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.