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] Potential fix.
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 branch 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.
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.