On further investigation, the reason for the closure c being corrupt seems to be related to the changes added in commit 3ab6cd31 to fix bug #3040.
In doListFontsAndAliases(), if we get a Suspended result when the client is already sleeping with the same closure (I don't really understand enough what the code is doing to know if that's expected or not), then the xinerama_sleep code frees() the closure c, so when it next wakes, the closure c is being used after being freed.
Being a use after free bug possibly explains why the original reporter is able to avoid the crash by changing the sequence of actions slightly.
The crash is not observed after reverting the noted commit, or with xserver 1.8.2
Doing some investigation of this reported crash whilst using xserver 1.9.2 with xfs: http:// cygwin. com/ml/ cygwin- xfree/2010- 11/msg00008. html, I'm able to reproduce this crash with the following sequence of actions:
X & r:7100
xterm &
xset fp+ tcp/myfontserve
xlsfonts
Program received signal SIGSEGV, Segmentation fault. liases (client=0x125fdc0, c=0x120fce8) at dixfonts.c:611 list[c- >current. current_ fpe]; 000\000ed- medium- r-normal- -24-230- 75-75-c- 240-jisx0208. 1983-0\ va▒\207\ va\000\ 000\000\ 000▒▒ \0019\017\ 000\000\ b\000\000\ 000\000\ 000\000\ 000|▒%a\ 000\000\ 000\000\ 001\000\ 000\000\ 001\000\ 000\000▒ \207\va\ 220▒\va@ ▒\va\000\ 000\000\ 000\030▒ \001\t\ 017\000\ 000\t\000\ 000\000\ 024\004\ 000\000▒ ▒%a\000\ 000\000\ 000\000\ 000\000\ 000\001\ 000\000\ 000\020\ 231\va▒ \227\va▒ \207\va\ 000\000\ 000\000H▒ \001▒\016\ 000\000\ v\000\000\ 000\024\ 004\000\ 000▒▒%a\ 000\000\ 000\000\ 000\000\ 000\000\ 001\000\ 000\000" ..., patlen = 62, current_fpe = 5, max_names = 3, list_started = 0, private = 0x12df550}, 000\000\ 001\000\ 000\000\ 020\231\ va▒\227\ va▒\207\ va\000\ 000\000\ 000▒&\001i\ 017\000\ 000\005\ 000\000\ 000\024\ 004\000\ 000|▒#a\ 000\000\ 000\000\ 000\000\ 000\000\ 001\000\ 000\000\ 020\231\ va▒\227\ va▒\207\ va\000\ 000\000\ 000▒▒ \0019\017\ 000\000\ b\000\000\ 000\000\ 000\000\ 000|▒%a\ 000\000\ 000\000\ 001\000\ 000\000\ 001\000\ 000\000▒ \207\va\ 220▒\va@ ▒\va\000\ 000\000\ 000\030▒ \001\t\ 017\000\ 000\t\000\ 000\000\ 024\004\ 000\000▒ ▒%a\000\ 000\000\ 000\000\ 000\000\ 000\001\ 000\000\ 000\020\ 231\va▒ \227\va▒ \207\va\ 000\000\ 000\000H▒ \001▒\016\ 000\000\ v\000\000\ 000\024\ 004\000\ 000▒▒%a\ 000\000\ 000\000\ 000\000\ 000\000\ 001\000\ 000\000" ..., patlen = 1, current_fpe = 0, max_names = 65535, list_started = 1, private = 0x125fb10}, medium- r-normal- -24-230- 75-75-c- 240-jisx0208. 1983-0" ,
[Switching to thread 4712.0x1220]
0x005b2e29 in doListFontsAndA
611 fpe = c->fpe_
(gdb) p c
$1 = (LFclosurePtr) 0x120fce8
(gdb) p *c
$2 = {client = 0x120fce0, num_fpes = 18939104, fpe_list = 0x0, names = 0x0, current = {
pattern = "▒W a\002\000\
saved = {
pattern = "*\000\
haveSaved = 1, savedName = 0x12df338 "-jis-fixed-
savedNameLen = 64}
(gdb)
On further investigation, the reason for the closure c being corrupt seems to be related to the changes added in commit 3ab6cd31 to fix bug #3040.
In doListFontsAndA liases( ), if we get a Suspended result when the client is already sleeping with the same closure (I don't really understand enough what the code is doing to know if that's expected or not), then the xinerama_sleep code frees() the closure c, so when it next wakes, the closure c is being used after being freed.
Being a use after free bug possibly explains why the original reporter is able to avoid the crash by changing the sequence of actions slightly.
The crash is not observed after reverting the noted commit, or with xserver 1.8.2