When reading the kernel keyboard mapping (readKernelMapping in
os-support/linux/lnx_KbdMap.c) we overrun the usefully-named global array 'map',
scribbling on other random static variables elsewhere.
The debugging patch attached to Red Hat bug #187083
(https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=127207) show this clearly...
readKernelMapping. map 0x10213488 is of size 0xf80 (i.e. ends 0x10214408)
NUM_CUSTOMKEYS 128, NUM_AT2LNX 248, NUM_KEYCODES 248, GLYPHS_PER_KEY 4
i is 0, j is 0, k is 0x10213498
i is 0, j is 1, k is 0x1021349c
i is 0, j is 2, k is 0x102134a0
i is 0, j is 3, k is 0x102134a4
i is 1, j is 0, k is 0x102134a8
i is 245, j is 3, k is 0x102143f4
i is 246, j is 0, k is 0x102143f8
i is 246, j is 1, k is 0x102143fc
i is 246, j is 2, k is 0x10214400
i is 246, j is 3, k is 0x10214404
i is 247, j is 0, k is 0x10214408
i is 247, j is 1, k is 0x1021440c
i is 247, j is 2, k is 0x10214410
i is 247, j is 3, k is 0x10214414
... with the last four writes scribbling on random variables elsewhere.
In the Fedora Core 5 build for PowerPC, those just happened to be the 'fd' in
linuxPciOpenFile(), so on VT switch away and back again, we closed and reopened
the wrong file descriptor... then started writing log text to the PCI config
space instead of the logfile, with predictably useful results.
Oh, the 'map' array isn't actually global -- it's just declared static in the
header file. That's, erm, interesting :)
Created attachment 5169 [details] [review]
kem claimed he had a better fix, iirc.
*** Bug 6533 has been marked as a duplicate of this bug. ***
Is kem going to share his fix with us?
I spent weeks on the track of this bug with gdb and several other things. (bug
6533) My symptons were a bit different: if Xorg was compiled with anything
above -O0 and gcc >=4.1.x, starting with the second VT switch, the screen
stayed black (or the system just hanged when switched back from the VT with the
native nvidia driver). After I finally narrowed it down to readKernelMapping,
this bug here popped up. :-)
To make a long story short: I consider this a major bug as memory is getting
corrupted which naturally causes undesired and unforeseeable effects. Having an
official fix for this would be rather important, so distributions could
incorporate it into their packages until a new release is out.
Just saw benh's question in irc -- didn't know that people were waiting on my fix.
My fix just rewrote a bit of the code to make it clearer what is going on here
and get rid of the map+GLYPHS_PER_KEY hack -- i.e., it's nothing special.
Unfortunately, it was lost when my laptop hard drive failed earlier this week.
It shouldn't be too hard to recreate, but I won't have time to do that until I
return from my trip next week.
For 7.1, I think David's fix is fine and should go in.
I commited the fix to HEAD. I'll let Ajax decide if it should also go to some branch
(In reply to comment #8)
> I commited the fix to HEAD. I'll let Ajax decide if it should also go to some
It does; applied to 1.1 branch. Probably should go in 1.0 branch too, if we
ever do another 1.0.x; moving to appropriate tracker.