Perhaps the bug is equally represented in Xorg and Xephyr. In which case, you can probably run Xephyr from your desktopBacktrace: 0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x812d07b] 1: /usr/bin/Xorg(xf86SigHandler+0x9e) [0x80c061e] 2: [0xdf0400] Fatal server error: Caught signal 11. Server aborting
Xephyr :1with :1 to denote which display it should take (:0 should be in use by your session already).
Then, run which apps you need to inside Xephyr to reproduce the bug. (e.g. the Gimp).
You can tell them which X server to appear in by setting the DISPLAY variable like so
DISPLAY=:1 gimpNow, right before you cause the Xephyr X server to crash, run gdb on it
gdb --pid=`pidof Xephyr`You might not have the debuginfo files installed, which you'll want to be able to trace through the human-readable source code. gdb should prompt you with a command for any relevant, missing debuginfo. Note that, on Fedora 11, you'll also need librpm.so available for it to do this (provided by rpm-devel).
Once you have the symbols loaded and gdb connected to your Xephyr process, tell gdb to "continue", and now reproduce your crasher. gdb should catch the segfault (or signal SIGSEV or something). Then you can get a backtrace ("bt") from gdb and start finding out where you are.
After that, I tend to restart Xephyr, reconnect gdb, and "break" at the names of functions where the crash happens, and then start "step"ing and "next"ing through, "print"ing the variables whose values I want to see until I find out why I'm crashing.
RH bug 505823 will let me know if this was at all useful.
No comments:
Post a Comment