It appears that XFree86's built-in GLX (using Mesa) provides
that hook. Except for the __glXInitPix part, the trace looks
reasonable as GLX's PositionWindow does call __glXResizeDrawableBuffers.
This is out of my jurisdiction however, and I don't know anything
about XFree86's mesa-based GLX. But, I'd be interested if you found a
problem with NVIDIA's GLX used by the "nvidia" binary driver.
Mark.
On Mon, 26 Aug 2002, Jim Newberry wrote:
> Mark,
>
> I built the binary with -g and -O0, so maybe something else is trashing
> the stack. I found xfree-gdb and it gives me a more complete (yet maybe
> still trashed) stack of:
>
> #0 0x08512144 in XMesaForceCurrent (c=0x80) at xmesa1.c:2160
> #1 0x0850a1fc in __MESA_resizeBuffers (buffer=0x89bd660, x=381, y=443,
> width=518,
> height=514, glPriv=0x89bd644, bufferMask=1) at xf86glx.c:641
> #2 0x08390b20 in __glXResizeBuffers () at get.c:3276
> #3 0x0846dc28 in __glXResizeDrawableBuffers ()
> at ../../../../../extras/Mesa/src/shade_tmp.h:378
> #4 0x083fd4ff in __glXInitPix () at image.c:974
> #5 0x080f7ba3 in ResizeChildrenWinSize (pWin=0x8b41a70, dx=1, dy=-1,
> dw=0, dh=0)
> at window.c:1831
> #6 0x081c7302 in miMoveWindow (pWin=0x8b41a70, x=326, y=385,
> pNextSib=0x8887df0,
> kind=VTMove) at miwindow.c:524
> #7 0x080f8fc1 in ConfigureWindow (pWin=0x8b41a70, mask=3,
> vlist=0x89ee954,
> client=0x86dbc38) at window.c:2504
> #8 0x080cff0a in ProcConfigureWindow (client=0x86dbc38) at
> dispatch.c:766
>
> XMesaForceCurrent calls gl_make_current with a bogus gl_buffer argument.
> Since my applications use glX widgets, I could at least see the
> possibility that there is a connection there, but having the symbol
> PositionWindow mapped to __glXInitPix looks a little crazy.
>
> Jim
>
> On Monday, August 26, 2002, at 12:43 PM, Mark Vojkovich wrote:
>
>
>
>
> > I think your trace is bad. I don't think PositionWindow
> > actually does anything. As far as I can tell fb is the only
> > thing hooked up to it and it just returns true. If your
> > binary has been stripped, your trace may very well be junk.
> >
> >
> > Mark.
> >
> > On Mon, 26 Aug 2002, Jim Newberry wrote:
> >
> > > Hi,
> > > I'm looking for some help in finding the source of a repeatable,
> > > driver-independent (I think) crash I'm causing in PositionWindow .
> > I'm
> > > using the source RPM from RedHat (4.1.0-3) and the Savage driver on
> > a
> > > ThinkPad. I can also cause the crash using the nv driver.
> > >
> > > Scenario:
> > >
> > > Multi-executable suite of cooperating programs. Close a window. Go
> > to
> > > another window's title bar and try to move the window. X server
> > crashes
> > > (in both gnome and kde). I can construct a use path where I can
> > repeat it
> > > about 70% of the time.
> > >
> > > The program that I'm using uses a GlxMDraw widget.
> > >
> > > I'm sure I have a program bug, although why in the world it would
> > cause an
> > > X Server crash, I don't know...
> > >
> > > Anyway, I'd like to trace it down and I don't know how to get to the
> >
> > > PositionWindow symbol to expand my stack trace down to where the seg
> > fault
> > > happens.
> > >
> > >
> > >
> > > Running XFree86 in gdb, I can get to the following stack trace:
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x084ce604 in ?? () at eval.c:41
> > > 41 eval.c: No such file or directory.
> > > in eval.c
> > > (gdb) where
> > > #0 0x084ce604 in ?? () at eval.c:41
> > > #1 0x08472686 in ?? () at eval.c:41
> > > #2 0x082f006b in ?? () at eval.c:41
> > > #3 0x082effc7 in ?? () at eval.c:41
> > > #4 0x08511fd1 in ?? () at eval.c:41
> > > #5 0x0850a07c in ?? () at eval.c:41
> > > #6 0x08390910 in ?? () at eval.c:41
> > > #7 0x0846db30 in ?? () at eval.c:41
> > > #8 0x083fd4bf in ?? () at eval.c:41
> > > #9 0x080f7ba3 in ResizeChildrenWinSize (pWin=0x89d34e8, dx=5,
> > dy=-17, dw=
> > > 0, dh=0)
> > > at window.c:1831
> > > #10 0x081c7302 in miMoveWindow (pWin=0x89d34e8, x=330, y=369,
> > > pNextSib=0x88a5300,
> > > kind=VTMove) at miwindow.c:524
> > > #11 0x080f8fc1 in ConfigureWindow (pWin=0x89d34e8, mask=15,
> > > vlist=0x8784bfc,
> > > client=0x8728d48) at window.c:2504
> > > #12 0x080cff0a in ProcConfigureWindow (client=0x8728d48) at
> > dispatch.c:766
> > > #13 0x080cf5e0 in Dispatch () at dispatch.c:456
> > > #14 0x080e6b95 in main (argc=4, argv=0xbffff914, envp=0xbffff928) at
> > main.
> > > c:449
> > > #15 0x40089507 in __libc_start_main (main=0x80e6550 <main>, argc=4,
> > ubp_av=
> > > 0xbffff914,
> > > init=0x806c3a0 <_init>, fini=0x81f2e20 <_fini>,
> > rtld_fini=0x4000dc14
> > > <_dl_fini>,
> > > stack_end=0xbffff90c) at ../sysdeps/generic/libc-start.c:129
> > >
> > > The function called at #9 is:
> > >
> > > 1831 (*pScreen->PositionWindow)(pChild,
> > > 1832 pChild->drawable.x,
> > > pChild->drawable.y);
> > >
> > >
> > > Any ideas?
> > >
> > > Thanks,
> > > Jim
> > >
> > > _______________________________________________
> > > Xpert mailing list
> > > [EMAIL PROTECTED]
> > > http://XFree86.Org/mailman/listinfo/xpert
> > >
> > _______________________________________________
> > Xpert mailing list
> > [EMAIL PROTECTED]
> > http://XFree86.Org/mailman/listinfo/xpert
> >
> >
> >
> - Jim Newberry
> - Applied Precision, LLC http://www.api.com
> - Issaquah WA, USA
>
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
