Re: xfig crashes XFree86 server (4.3.0) with trident driver
On Sun, 23 Mar 2003, Gary E. RAFE, Ph.D. wrote: ! Assuming you actually have core dumps enabled, the server !will often not dump core unless you turn off its signal !trapping facility in the XF86Config file. ! !Section ServerFlags ! Option NoTrapSignals !EndSection I find that xfig still core dumps when the X server crashes, as before, but XFree86 does not, although the console becomes corrupted with the NoTrapSignals option, and the system must be restarted. So, I'm at a loss now as to how to get the X server to core dump; I would expect it to just happen. I could be some permissions thing. The server runs with root privledges so you have to be careful where you dump stuff. Can you login remotely and run the server under the debugger, or attach the debugger to the running server? gdb /usr/X11R6/bin/XFree86 serverpid will attach to a running server. Then you do the module /usr/X11R6/lib/modules from the gdb prompt to load the modules, then continue. Any exceptions will show up in GDB. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfig crashes XFree86 server (4.3.0) with trident driver
! If it's reproducible and you can get a gdb backtrace, that would !be useful. Baring that, seeing it if goes away with Option NoAccel !would at least narrow things down. I gave this another go with a newly-built debug server, XAA and trident driver modules, and got the following backtrace information: (gdb) bt #0 0x28389b78 in kill () from /usr/lib/libc.so.4 #1 0x283ca742 in abort () from /usr/lib/libc.so.4 #2 0x80bc73a in goodbye (abortflag=1) at w_cmdpanel.c:538 #3 0x809c275 in emergency_quit (abortflag=1) at u_error.c:98 #4 0x809c0a8 in error_handler (err_sig=1) at u_error.c:52 #5 0xbfbfffac in ?? () #6 0x282b1d49 in XrmGetFileDatabase () from /usr/X11R6/lib/libX11.so.6 #7 0x28294053 in XGetErrorDatabaseText () from /usr/X11R6/lib/libX11.so.6 #8 0x809c149 in X_error_handler (d=0x81d5800, err_ev=0xbfbff27c) at u_error.c:70 #9 0x282af8a0 in _XIOError () from /usr/X11R6/lib/libX11.so.6 #10 0x282ad2fa in _XRead () from /usr/X11R6/lib/libX11.so.6 #11 0x282add30 in _XReply () from /usr/X11R6/lib/libX11.so.6 #12 0x282a99dc in XSync () from /usr/X11R6/lib/libX11.so.6 #13 0x810b07a in app_flush () at w_util.c:170 #14 0x810e405 in process_pending () at w_util.c:1122 #15 0x808a802 in main (argc=1, argv=0xbfbff8e0) at main.c:1256 #16 0x804d859 in _start () No mention of trident_drv.o or libxaa.a here. Do I need more of the XFree86-4.3.0 source tree built (all?) as debug ? -- Gary E. RAFE, Ph.D. [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfig crashes XFree86 server (4.3.0) with trident driver
Sorry, I meant a backtrace of XFree86, not of xfig. Mark. On Fri, 21 Mar 2003, Gary E. RAFE, Ph.D. wrote: ! If it's reproducible and you can get a gdb backtrace, that would !be useful. Baring that, seeing it if goes away with Option NoAccel !would at least narrow things down. I gave this another go with a newly-built debug server, XAA and trident driver modules, and got the following backtrace information: (gdb) bt #0 0x28389b78 in kill () from /usr/lib/libc.so.4 #1 0x283ca742 in abort () from /usr/lib/libc.so.4 #2 0x80bc73a in goodbye (abortflag=1) at w_cmdpanel.c:538 #3 0x809c275 in emergency_quit (abortflag=1) at u_error.c:98 #4 0x809c0a8 in error_handler (err_sig=1) at u_error.c:52 #5 0xbfbfffac in ?? () #6 0x282b1d49 in XrmGetFileDatabase () from /usr/X11R6/lib/libX11.so.6 #7 0x28294053 in XGetErrorDatabaseText () from /usr/X11R6/lib/libX11.so.6 #8 0x809c149 in X_error_handler (d=0x81d5800, err_ev=0xbfbff27c) at u_error.c:70 #9 0x282af8a0 in _XIOError () from /usr/X11R6/lib/libX11.so.6 #10 0x282ad2fa in _XRead () from /usr/X11R6/lib/libX11.so.6 #11 0x282add30 in _XReply () from /usr/X11R6/lib/libX11.so.6 #12 0x282a99dc in XSync () from /usr/X11R6/lib/libX11.so.6 #13 0x810b07a in app_flush () at w_util.c:170 #14 0x810e405 in process_pending () at w_util.c:1122 #15 0x808a802 in main (argc=1, argv=0xbfbff8e0) at main.c:1256 #16 0x804d859 in _start () No mention of trident_drv.o or libxaa.a here. Do I need more of the XFree86-4.3.0 source tree built (all?) as debug ? -- Gary E. RAFE, Ph.D. [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfig crashes XFree86 server (4.3.0) with trident driver
On Mon, 17 Mar 2003, G.E. Rafe wrote: ! If it's reproducible and you can get a gdb backtrace, that would !be useful. Baring that, seeing it if goes away with Option NoAccel !would at least narrow things down. I've given gdb a spin, but don't get much satisfaction from its output (perhaps due to my vast inexperience with it!) Adding 'Option NoAccel' does, in fact, make the server crash go away when xfig(1) starts, but at a cost (of course). To where next ? -- Gary It's probably either in XAA or it's in the driver. Somebody with a trident card will have to debug this. Namely build a debug server (or at least debug XAA and trident driver) and get a backtrace from the crash. Perhaps if you could just run the module-aware gdb (/put/xpert/gdb on ftp.xfree86.org) on a non-debug server or core dump there could be enough of a backtrace to narrow it down further. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
xfig crashes XFree86 server (4.3.0) with trident driver
I'm finding that xfig crashes my XFree86 server (4.3.0) when running the trident driver on my Toshiba Satellite Pro 4600 / FreeBSD 4.7-R system. The last messages I get before the server goes away: xfig3.2.4: SIGHUP signal trapped xfig3.2.4: X error trapped - error message follows: 32 Request code: Unknown Not much else reported in /var/log/XFree86.0.log Note that xfig doesn't crash the server when we use the VESA driver. Any pointers to what might be causing this ? -- Gary E. RAFE, Ph.D. [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfig crashes XFree86 server (4.3.0) with trident driver
! If it's reproducible and you can get a gdb backtrace, that would !be useful. Baring that, seeing it if goes away with Option NoAccel !would at least narrow things down. I've given gdb a spin, but don't get much satisfaction from its output (perhaps due to my vast inexperience with it!) Adding 'Option NoAccel' does, in fact, make the server crash go away when xfig(1) starts, but at a cost (of course). To where next ? -- Gary ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
