On Fri, 5 Jul 2002, Jens Owen wrote:
> Leif Delgass wrote:
>
> > On Fri, 5 Jul 2002, Jens Owen wrote:
> >
> > [snip]
> >
> >
> >>However, I think you may be tickling a latent bug in the DRI. It's
> >>possible that all the other drives have just avoided this bug so far.
> >>
> >>I looked at DRICloseScreen and I don't see that the DRIClipNotify
> >>wrapper is being removed. There are other unwraps missing as well.
> >>
> >>Can you send me a back trace from a static debuggable server? Let me
> >>know if you need help building this.
> >>
> >
> > Could you tell me how to build a static server or point me to a HOWTO?
>
>
> The xc/config/cf/host.def in the DRI tree is setup to easily modified to
> build a debuggable server. Attached is a copy of a modified host.def
> file I used for debugging an i810 problem. You'll probably need to add
> the mach64 driver to these options.
OK, I'll try this. I think you're right that we need to add the
GlxBuiltIn.. option for mach64.
> > Meanwhile, here's a backtrace from the X server built from the branch. It
> > looks like the ClipNotify wrapper is being called when pDRIPriv is null,
> > though I'm not sure why I wouldn't have run into this before...
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
> > 1732 if(pDRIPriv->wrap.ClipNotify) {
> > (gdb) bt
> > #0 DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
> > #1 0x080c9009 in MapWindow (pWin=0x85d3a60, client=0x81d56a8) at window.c:2864
> > #2 0x080c5ee8 in InitRootWindow (pWin=0x85d3a60) at window.c:522
> > #3 0x080bf39c in main (argc=4, argv=0xbffff9d4, envp=0xbffff9e8) at main.c:439
> > #4 0x40072647 in __libc_start_main (main=0x80bee9c <main>, argc=4,
> > ubp_av=0xbffff9d4, init=0x806cc08 <_init>, fini=0x8174c80 <_fini>,
> > rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffff9cc)
> > at ../sysdeps/generic/libc-start.c:129
> > (gdb) info locals
> > pWin = 0x85d3a60
> > pScreen = 0x85d3748
> > pDRIPriv = 0x0
> > pDRIDrawablePriv = 0x0
>
>
> Yes, it looks like the DRI initialization process was started, causing
> the DRI wrappers to be put in place; then, something caused DRI
> initialization to fail, but the failure handling code does not remove
> the wrappers.
>
> I believe I need to unwrap the DRI routines in DRICloseScreen. I'd like
> to fix this case and ask you to test with what you've got since it's
> hard to test these unusual failure cases when everythings working properly.
>
> It's still curious no other drivers have had this problem. Either
> nobody else has gone done these failure cases, or I'm barking up the
> wrong tree.
It's pretty easy to test if you just change the return value of the
driver's drm init function to return non-zero. For example, I tried this
in the r128 driver in r128_do_init_cce (changed the last line to return
-1), and it suffers the same problem (the backtrace was the same).
> Can you verify that we are indeed calling DRICloseScreen by putting a
> breakpoint at that routine and sending me a backtrace at that point?
I know it's called because I see the messages in the X log about removing
the signal handler, kernel context, SAREA, etc. It's called as part of
the DRI driver specific CloseScreen (ATIDRICloseScreen) when the kernel
init fails (which is after DRIFinishScreenInit is called). In fact, the
entire X init seems to work without a hitch (I see all the normal messages
in the X log after "Direct rendering disabled" up to XINPUT) until the
root window is initialized.
--
Leif Delgass
http://www.retinalburn.net
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
