Bug 85230 - Program messes with XF86Config resulting in invalid configuration file
Program messes with XF86Config resulting in invalid configuration file
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: pyxf86config (Show other bugs)
9
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Alexander Larsson
:
: 90272 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-26 15:34 EST by Peter van Egdom
Modified: 2007-04-18 12:51 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-28 11:11:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter van Egdom 2003-02-26 15:34:33 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030206

Description of problem:

Okay, this one is really hard to reproduce. Nevertheless, I encountered it twice
on Phoebe 8.0.94. The first time I thought I made some mistake somewhere in
testing the redhat-config-* tools and fixed my screen configuration (with the
--reconfig option of "redhat-config-xfree86") so everything was all right again.

2 days later I was using "redhat-config-keyboard" to test some differences with
different keyboard setups for my system and triggered the bug and captured it.

It all comes down to this, start "redhat-config-keyboard" and try out different
settings for the keyboard. It can take a while before the bug is triggered, though.

After the bug is triggered, "redhat-config-keyboard" barfs out some text to the
xterm (see additional information) and corrupts "/etc/X11/XF86Config".

Here is the diff with a valid XFConfig file and the corrupted one by
"redhat-config-keyboard" :

[root@powermate X11]# diff XF86Config.bak XF86Config.crap
0a1
>
10a12
>
14d15
<
18d18
<
33a34
>
36d36
<
39d38
<
64c63
<       Option      "XkbLayout" "us"
---
>       Option      "XkbLayout" "us_intl"
76a76
>
92,93c92,109
<       HorizSync    31.0 - 96.0
<       VertRefresh  55.0 - 160.0
---
>       HorizSync    31.0 - 31.0
>       HorizSync    0.0 - 31.0
>       HorizSync    0.0 - 0.0
>       HorizSync    0.0 - 0.0
>       HorizSync    0.0 - 96.0
>       HorizSync    0.0 - 0.0
>       HorizSync    0.0 - 0.0
>       HorizSync    0.0 - 0.0
>       HorizSync    55.0 - 0.0
>       VertRefresh  55.0 - 55.0
>       VertRefresh  0.0 - 55.0
>       VertRefresh  0.0 - 0.0
>       VertRefresh  0.0 - 0.0
>       VertRefresh  0.0 - 160.0
>       VertRefresh  0.0 - 0.0
>       VertRefresh  0.0 - 0.0
>       VertRefresh  0.0 - 0.0
>       VertRefresh  0.0 - 0.0


Version-Release number of selected component (if applicable):


How reproducible:
Sometimes

Steps to Reproduce:
1. start "redhat-config-keyboard"
2. select different keyboard setups, switch from one to another, e.g.
  "United States" -> "United States International" -> "United States".
3. exit "redhat-config-keyboard.
4. repeat until bug is triggered.
    

Actual Results:
 "redhat-config-keyboard" corrupts "/etc/X11/XFConfig"

Expected Results:
 Hmm... this should not happen.

Additional info:

(This problem has been found on Phoebe 8.0.94 with package
"redhat-config-keyboard-1.0.3-4").

Here everything is all right (normal output from redhat-config-keyboard):

[root@powermate root]# redhat-config-keyboard
Loading //lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz
* running ['/usr/X11R6/bin/setxkbmap', '-layout', 'us_intl', '-model', 'pc105',
'-option', '']

And here is the bug output (about 2 seconds after the above output, with no
modifications on my machine other than messing around with
"redhat-config-keyboard") which corrupts "/etc/X11/XF86Config" :

[root@powermate root]# redhat-config-keyboard
Loading //lib/kbd/keymaps/i386/qwerty/us.map.gz
* running ['/usr/X11R6/bin/setxkbmap', '-layout', 'us', '-model', 'pc105',
'-option', '']
Parse error on line 100 of section Monitor in file /etc/X11/XF86Config
        The HorizSync keyword must be followed by a list of numbers or ranges.
Traceback (most recent call last):
  File "/usr/lib/python2.2/site-packages/rhpl/firstboot_gui_window.py", line 83,
in okClicked
    if self.apply():
  File "/usr/share/redhat-config-keyboard/keyboard_gui.py", line 188, in apply
    keyboardBackend.modifyXconfig(fullname, layout, model, variant, options)
  File "/usr/share/redhat-config-keyboard/keyboard_backend.py", line 35, in
modifyXconfig
    keyboard = xf86config.getCoreKeyboard(xconfig)
  File "/usr/lib/python2.2/site-packages/xf86config.py", line 155, in
getCoreKeyboard
    for i in xconfig.layout[0].inputs:
AttributeError: 'NoneType' object has no attribute 'layout'
Comment 1 Miloslav Trmac 2003-02-27 12:50:11 EST
I've seen the corrupted XF86Config too. I din't examine it enough
to point at specific package, but I'll check.
Comment 2 Peter van Egdom 2003-02-27 15:06:51 EST
Although not with "redhat-config-keyboard", I can also 100% reproduce this bug
(or a very similar one) with starting the program "setup" as root, and choosing
the text-version of "redhat-config-mouse" (Mouse configuration as presented by
the menu by "setup").

After starting "setup" as root and choosing 'Mouse configuration' - and not
selecting anything to change, just [tab] -> [tab] -> [tab] -> [cancel], makes
XF86Config invalid.

Doing a diff between a backup of of XF86Config and the new XF86Config
(apparently generated by redhat-config-mouse) results in this :

root@powermate X11]# diff XF86Config.bak XF86Config
69c69
<       Option      "Protocol" "GlidePointPS/2"
---
>       Option      "Protocol" "IMPS/2"
92,93c92,93
<       HorizSync    31.0 - 96.0
<       VertRefresh  55.0 - 160.0
---
>       HorizSync    31,0 - 96,0
>       VertRefresh  55,0 - 160,0

(notice the "," instead of the "." characters).

Running the tool ("# setup" and again doing a Mouse configuration, followed by
<tab>, <tab>, <tab>, [cancel]) again makes a mess out of the XF86Config file,
this time worse :

root@powermate X11]# diff XF86Config.bak XF86Config
69c69
<       Option      "Protocol" "GlidePointPS/2"
---
>       Option      "Protocol" "IMPS/2"
92,93c92,97
<       HorizSync    31.0 - 96.0
<       VertRefresh  55.0 - 160.0
---
>       HorizSync    31,0 - 31,0
>       HorizSync    0,0 - 96,0
>       HorizSync    0,0 - 0,0
>       VertRefresh  55,0 - 55,0
>       VertRefresh  0,0 - 160,0
>       VertRefresh  0,0 - 0,0

Okay, corrupting XF86Config is very easy to trigger with Mouse configuration run
from "setup". 

I haven't succeeded in reproducing the problem with redhat-config-keyboard.

The origin of the bug is probably very much the same as with Mouse configuration
running from "setup". 

I'll change component to "redhat-config-mouse" instead because it's easier to
track and reproduce.

Comment 3 Peter van Egdom 2003-03-15 05:31:47 EST
Described problem still occurs running "redhat-config-mouse" in text mode with
"redhat-config-mouse-1.0.5-1" on Phoebe 8.0.94.
Comment 4 Brent Fox 2003-03-21 15:46:08 EST
I think that this is really a bug with pyxf86config running in non-us locales.

Nothing in redhat-config-mouse or redhat-config-keyboard tries to modify that
particular section of XF86Config, yet something in pyxf86config is converting
the decimals into commas.  Alex, can you take a look at this?  
Comment 5 Peter van Egdom 2003-03-22 11:45:14 EST
Here are the contents of the file "/etc/sysconfig/i18n" on my Phoebe 8.0.94 setup:

LANG="nl_NL.UTF-8"
SUPPORTED="nl_NL.UTF-8:nl_NL:nl:en_US.UTF-8:en_US:en"
SYSFONT="latarcyrheb-sun16"
Comment 6 Alexander Larsson 2003-03-24 09:20:20 EST
libxf86config seems to be using fprintf("%f") to generate the config file. This
will use ',' instead of '.' in some locales.

I don't think this will hit the x-based configuration tools though. Since python
doesn't support locales that behave like this pygtk sets LC_NUMERIC to "C"
automatically on initialization. Maybe the redhat-config-* tools should do that too?
Comment 7 Alexander Larsson 2003-05-28 11:11:02 EDT
This is fixed in pyxf86config 0.3.9.
Comment 8 Brent Fox 2003-05-30 10:01:56 EDT
*** Bug 90272 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.