On Don, 2002-10-24 at 14:25, David Dawes wrote: > On Thu, Oct 24, 2002 at 02:00:48PM +0200, Michel Dänzer wrote: > >On Don, 2002-10-24 at 13:52, Alan Hourihane wrote: > >> On Thu, Oct 24, 2002 at 01:47:01PM +0200, Michel Dänzer wrote: > >> > > That certainly shouldn't be needed for shared entities. Where exactly > >> > > was it crashing ? > >> > > >> > XAA dereferences pScrn->pScreen to track the state of shared entities. > >> > RADEONScreenInit() calls other radeon driver functions which call > >> > info->accel->Sync(), but the driver independent code only sets pScrn->pScreen > >> > after ScreenInit(). Boom. > >> > >> A backtrace would be useful. > > The backtrace would be useful for showing the exact call sequence leading > to the SEGV, and may help in determining if the problem should be fixed > in a different way.
Kevin Puetz sent me this one: 0x081952ca in XAAStateWrapSync (pScrn=0x8870a80) at xaaStateChange.c:313 313 GET_STATEPRIV_PSCRN(pScrn); (gdb) bt #0 0x081952ca in XAAStateWrapSync (pScrn=0x8870a80) at xaaStateChange.c:313 #1 0x080fdae5 in RADEONLoadPalette (pScrn=0x8870a80, numColors=256, indices=0x88bc9e8, colors=0x88bcdf0, pVisual=0x8886d88) at radeon_driver.c:2429 #2 0x0829dabb in CMapRefreshColors (pmap=0x88b6b80, defs=256, indices=0x88bc9e8) at xf86cmap.c:619 #3 0x0829d1c7 in CMapReinstallMap (pmap=0x88b6b80) at xf86cmap.c:493 #4 0x0829d127 in CMapSetDGAMode (index=0, num=0, dev=0x0) at xf86cmap.c:470 #5 0x08287082 in DGAShutdown () at xf86DGA.c:475 #6 0x0826ee91 in ddxGiveUp () at xf86Init.c:1082 #7 0x0826efaf in AbortDDX () at xf86Init.c:1145 #8 0x0830a9a8 in AbortServer () at utils.c:436 #9 0x0830c65f in FatalError (f=0x8795d40 "Caught signal %d. Server aborting\n") at utils.c:1402 #10 0x08289c81 in xf86SigHandler (signo=11) at xf86Events.c:1085 #11 0x40079518 in sigaction () from /lib/libc.so.6 #12 0x080fdae5 in RADEONLoadPalette (pScrn=0x8870a80, numColors=256, indices=0x88bc9e8, colors=0x88bcdf0, pVisual=0x8886d88) at radeon_driver.c:2429 #13 0x0829dabb in CMapRefreshColors (pmap=0x88b6b80, defs=256, indices=0x88bc9e8) at xf86cmap.c:619 #14 0x0829d1c7 in CMapReinstallMap (pmap=0x88b6b80) at xf86cmap.c:493 #15 0x0829cf0c in CMapInstallColormap (pmap=0x88b6b80) at xf86cmap.c:418 #16 0x0829c726 in xf86HandleColormaps (pScreen=0x8886008, maxColors=256, sigRGBbits=8, loadPalette=0x80fda88 <RADEONLoadPalette>, setOverscan=0, flags=3) at xf86cmap.c:196 #17 0x080ff0c9 in RADEONScreenInit (scrnIndex=0, pScreen=0x8886008, argc=1, argv=0xbffffd14) at radeon_driver.c:2966 #18 0x082ec94a in AddScreen (pfnInit=0x80fe0ac <RADEONScreenInit>, argc=1, argv=0xbffffd14) at main.c:768 #19 0x0826e893 in InitOutput (pScreenInfo=0x885a4a0, argc=1, argv=0xbffffd14) at xf86Init.c:819 #20 0x082ebbc7 in main (argc=1, argv=0xbffffd14, envp=0xbffffd1c) at main.c:380 > >What's the problem with setting this pointer, anyway? > > If pScrn->pScreen must be dereferenced before the end of ScreenInit, then > you need to set it. The driver independent code can't set it before > it already does (it isn't allocated yet), But ScreenInit() seems to have both pScreen and pScrn from the beginning? > so if the driver needs it, it has to do it itself. I think the problem > isn't setting this pointer, but making sure that setting it isn't just > covering up some other problem. Curious if you see something. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ------------------------------------------------------- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
