Comment 16 for bug 246585

I'm able to reproduce the crash in gnome-panel. In panel_multiscreen_init(), it calls:

        screens = gdk_display_get_n_screens (display);

which appears to work correctly:

(gdb) print screens
$33 = 1
(gdb) print display
$34 = (GdkDisplay *) 0xa2b000

but then the gdk_screen_get_n_monitors() call seems to be returning a 0:

                monitors [i] = gdk_screen_get_n_monitors (screen);

this then causes a NULL pointer to be set here:

                geometries [i] = g_new0 (GdkRectangle, monitors [i]);

which then propagates down to this point:

int
panel_multiscreen_width (GdkScreen *screen,
                         int monitor)
{
  int n_screen;

        n_screen = gdk_screen_get_number (screen);

        g_return_val_if_fail (n_screen >= 0 && n_screen < screens, 0);
  g_return_val_if_fail (monitor >= 0 || monitor < monitors [n_screen], 0);

 return geometries [n_screen][monitor].width;
}

Breakpoint 1, panel_multiscreen_width (screen=<value optimized out>, monitor=0) at panel-multiscreen.c:180
180 in panel-multiscreen.c

(gdb) print n_screen
$9 = 0
(gdb) print monitor
$10 = 0
(gdb) print geometries[0][0]
Cannot access memory at address 0x0

And in referencing this NULL pointer, we get our crash.

So gnome-panel is making the assumption that gdk_display_get_screen () does not return 0 ever, which it appears in fact to be doing now when using -vesa. I imagine other gtk apps have similar logic in them, that doesn't check this return code and are also crashing on null pointers.

The attached patch peppers in some null pointer checks that probably should be there if 0 is a valid gdk_display_get_screen() return value. It won't fix the problem but will make it crash earlier on, where the bug actually occurs. I'll look at gdk_display_get_screen() next...