Bug 13952

I can reproduce this with the default X server on Ubuntu 8.10,
but only on Intel graphics, not on nvidia.  Probably need
to change category to Drivers/Intel?

Xorg.log says:

X.Org X Server 1.5.2
Release Date: 10 October 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-19-server i686 Ubuntu
Current Operating System: Linux slave1 2.6.27-7-generic #1 SMP Thu Oct 30 04:18:38 UTC 2008 i686
Build Date: 24 October 2008  08:00:16AM
xorg-server 2:1.5.2-2ubuntu3 (buildd@rothera.buildd)
...
(--) PCI:*(0@0:2:0) Intel Corporation 82G33/G31 Express Integrated Graphics Controller rev 16, Mem @ 0xe1200000/0, 0xd0000000/0, 0xe1000000/0, I/O @ 0x0000e000/0
...
(II) intel(0): DDCModeFromDetailedTiming: 1024x768 Warning: We only handle seperate sync.

Backtrace:
0: /usr/X11R6/bin/X(xf86SigHandler+0x79) [0x80c3009]
1: [0xb7fea400]
2: /usr/X11R6/bin/X(VidModeGetNumOfModes+0x40) [0x80c8270]
3: /usr/lib/xorg/modules/extensions//libextmod.so [0xb7b340d0]
4: /usr/X11R6/bin/X(Dispatch+0x34f) [0x808c89f]
5: /usr/X11R6/bin/X(main+0x47d) [0x8071d1d]
6: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7bf1685]
7: /usr/X11R6/bin/X [0x8071101]
Saw signal 11.  Server aborting.

Sadly, even with every xorg*-dbg package installed, I see no
line numbers in the stack dump.

Annoyingly, because only two copies of Xorg.log are kept in /var/log,
one has to tail -f it or use startx or the like to capture
the error.

Here's how to reproduce:
run any Wine conformance test that creates a window
while the monitor is unplugged.  For instance,
 $ cd dlls/user32/tests
 $ rm static.ok
 $ make static.ok
will run fine with the cable plugged in, and crash with it unplugged.

Wine's log file, generated with WINEDEBUG=+all,+synchronous make test,
seems to indicate the crash is generated very quickly after
wine starts using X, probably while it is getting a list of
video modes:

0018:trace:module:load_dll Found L"C:\\windows\\system32\\winex11.drv" for L"winex11.drv" at 0x60a70000, count=2
...
0018:trace:x11settings:X11DRV_Settings_SetHandlers Resolution settings now handled by: NoRes
0018:trace:x11settings:X11DRV_Settings_SetHandlers Initialized new display modes array
0018:trace:x11settings:X11DRV_Settings_AddOneMode initialized mode 0: 1400x1050x32 @60 Hz (NoRes)
make: *** wait: No child processes.  Schluss.
make: *** Warte auf noch nicht beendete Prozesse...
make: *** wait: No child processes.  Schluss.
0009: *killed* exit_code=0
0008: *process killed*
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"^M
      after 86 requests (85 known processed) with 0 events remaining.^M

(A related annoyance is that running any such Wine test
wine the monitor is plugged in generates about fifty
lines in the Xorg log file, like this:

(II) intel(0): DDCModeFromDetailedTiming: 1024x768 Warning: We only handle seperate sync.
(II) intel(0): Using hsync ranges from config file
(II) intel(0): Using vrefresh ranges from config file
(II) intel(0): Printing DDC gathered Modelines:
(II) intel(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz)
(II) intel(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136 1312  768 769 772 800 -hsync -vsync (60.0 kHz)
...

This leads to logfiles hundreds of megabytes long.  The log
needs to be less verbose.)

I'm happy to test... I'll also report this to the ubuntu-x list,
and if anything comes of it, I'll link to it here.

Bryce pointed me to https://wiki.ubuntu.com/X/Backtracing
so now I have a good backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7af56b0 (LWP 6959)]
VidModeGetFirstModeline (scrnIndex=0, mode=0xbf9935a8, dotClock=0xbf9935a4)
    at ../../../../hw/xfree86/common/xf86VidMode.c:229
229     ../../../../hw/xfree86/common/xf86VidMode.c: No such file or directory.
        in ../../../../hw/xfree86/common/xf86VidMode.c
(gdb) bt
#0  VidModeGetFirstModeline (scrnIndex=0, mode=0xbf9935a8, dotClock=0xbf9935a4)
    at ../../../../hw/xfree86/common/xf86VidMode.c:229
#1  0x080c8270 in VidModeGetNumOfModes (scrnIndex=0)
    at ../../../../hw/xfree86/common/xf86VidMode.c:451
#2  0xb7adc0d0 in ProcXF86VidModeGetAllModeLines (client=0x8410da8)
    at ../../../../../hw/xfree86/dixmods/extmod/xf86vmode.c:534
#3  0x0808c89f in Dispatch () at ../../dix/dispatch.c:454
#4  0x08071d1d in main (argc=10, argv=0xbf9937b4, envp=0x0)
    at ../../dix/main.c:441

The crash seems to be because xf86Screens[scrnIndex]->modes is NULL,
and VidModeGetFirstModeline simply falls over dereferencing it:

218  VidModeGetFirstModeline(int scrnIndex, pointer *mode, int *dotClock)
219  {
220	ScrnInfoPtr pScrn;
221	VidModePtr pVidMode;
222	
223	if (!VidModeAvailable(scrnIndex))
224	  return FALSE;
225	
226	pScrn = xf86Screens[scrnIndex];
227	pVidMode = VMPTR(pScrn->pScreen);
228	pVidMode->First = pScrn->modes;
229	pVidMode->Next = pVidMode->First->next;

Hmm, VidModeAvailable does
135	pVidMode = VMPTR(pScrn->pScreen);
136	if (pVidMode)
137	  return TRUE;
Should it also check pVidMode->First ?

A search for this in bugzilla finds bug 17431, perhaps these are the same bug.

*** This bug has been marked as a duplicate of bug 17431 ***