If I can at least believe that call stack #0 is correct (which I may not be able to believe), then I think I have a GLX synchronization problem. The two windows I'm manipulating both contain GLX widgets. It "appears" that when I close the window that is "behind" (lower in the stack) without raising the window first, I may have an inconsistent state in GLX (the context still exists, but its gl_buffer is NULL?).
Anyway, my unsatisfactory workaround is that when a window is being closed from a titlebar close button or menu option, I do a XRaiseWindow, add a minimal timeout procedure and perform the program's exit() from the timeout. By forcing the underlying window to display itself before exiting, things seem to work. I haven't had a failure since.
I still don't know why the call stack of X is so trashed when this all happens...
Jim
On Monday, August 26, 2002, at 03:15 PM, Mark Vojkovich wrote:
�� It appears that XFree86's built-in GLX (using Mesa) provides- Jim Newberry
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
- Applied Precision, LLC http://www.api.com
- Issaquah WA, USA
