Attached patch fixes the problem for me. The problem seems to be that
FFBSaveScreen uses GET_FFB_FROM_SCREEN, which is #defined as
((FFBPtr)(s)->devPrivates[CreatorScreenPrivateIndex].ptr)
but CreatorScreenPrivateIndex and devPrivates seem to be only set in
ffb_accel, not by ffb_driver. When initializing the server that due to
some strange reason causes no problem[1], but when the last client exists
and the server is doing a reset, CreatorScreenPrivateIndex is 5 here
and points to strange values (0 or 0x10000 and stuff like that) thus
causing an segfault.
Hochachtungsvoll,
Bernhard R. Link
[1] On some other cards there might be no accelerator without additional
stuff, thus already segfaulting when starting the X server here. That
might exlain why it sometimes may already segfault when starting the
server and why that segfault at the start no longer happens with some
firmware package.
diff -u xserver-xorg-video-sunffb/src/ffb_driver.c xserver-xorg-video-sunffb-1.1.0/src/ffb_driver.c
--- xserver-xorg-video-sunffb/src/ffb_driver.c 2008-03-16 17:00:18.000000000 +0100
+++ xserver-xorg-video-sunffb-1.1.0/src/ffb_driver.c 2008-03-16 17:30:40.000000000 +0100
@@ -1010,7 +1010,12 @@
done in "ffb_dac.c" `for aesthetic reasons.'
*/
{
- return FFBDacSaveScreen(GET_FFB_FROM_SCREEN(pScreen), mode);
+ ScrnInfoPtr pScrn;
+ FFBPtr pFfb;
+
+ pScrn = xf86Screens[pScreen->myNum];
+
+ return FFBDacSaveScreen(GET_FFB_FROM_SCRN(pScrn), mode);
}
static void
