Created attachment 85838 [details]
program provoking server segfault

With recent debian i386 xvfb test server 1.12.4, in the SYNC extension 3.1 a CreateFence on screen number 1 causes the server to segfault.

For example the program foo.c below

  cc foo.c -lXext -lX11 -o foo

run as

  xvfb-run --auto-servernum --server-args="-screen 0 640x480x24 -screen 1 640x480x24" -e /dev/stdout ./foo

prints

Backtrace:
0: Xvfb (xorg_backtrace+0x49) [0xb7696779]
1: Xvfb (0xb753a000+0x1603c4) [0xb769a3c4]
2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0) [0xb7518410]

Segmentation fault at address (nil)

Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting


gdb sbows

#0  0x00000000 in ?? ()
#1  0xb769e049 in miSyncInitFence ()
#2  0xb7636192 in ?? ()
#3  0xb76fca25 in ?? ()
#4  0xb76133ea in ?? ()
#5  0xb7248585 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
#6  0xb7613749 in _start ()

I don't have a good debug setup but it appears to be the indirect call in miSyncInitFence() having NULL as destination

    pScreenPriv->funcs.CreateFence(pScreen, pFence, initially_triggered);


Nosing around miext/sync/misync.c, I wonder if the bit of miSyncSetup(),

    if (dixPrivateKeyRegistered(syncScreenPrivateKey))
	return TRUE;

causes it to return immediately for the init of the second and subsequent screens and therefore not set pScreenPriv->funcs on screen 1.  Is it supposed to be a "register if not already registered" of the key but setup pScreenPriv for each screen?

If that's so then I would expect this segfault running foo.c on screen 1 and higher of any server, not just xvfb.