Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!fafnir.la.locus.com!geoff From: geoff@ITcorp.com (Geoff Kuenning) Newsgroups: comp.windows.x Subject: Re: Debugging an X server Message-ID: <1991May16.033335.1201949@locus.com> Date: 16 May 91 03:33:35 GMT References: Sender: geoff@locus.com (Geoff Kuenning) Reply-To: geoff@ITcorp.com (Geoff Kuenning) Distribution: comp Organization: Locus Computing Corporation, Inglewood, CA Lines: 28 In article victor@watson.ibm.com writes: > What are recommended ways to debug an X server? There is a client > (info explorer on AIX 3.1 on the RS/6000) which always causes my X > server (an IBM rt/pc running BSD 4.3) to crash with a core dump. The > same client also causes X servers on RS/6000's running Mach 2.5 to > freeze up. To my way of thinking this is certainly a bug on the part > of the servers, but it would be neccessary to find out what sort of > trash this client is sending. My preferred approach is to use dbx or gdb and a second terminal. (You can't run a debugger via the server that is about to crash, for what I hope are obvious reasons). Depending on exactly how the server goes about locating its display, you may have to hack the startup code a bit or run it with some funny arguments. For example, under AIX/PS2 I have to type "run /dev/hft/3 2>/dev/hft/3" after first opening a dummy shell on /dev/hft/3. You may also find dbx's "ignore" command useful. Once you have the server running, you can set breakpoints and so forth quite normally. Run your offending client, then turn to your other terminal and step through the server to find the bug. Obviously, it's a Good Thing to have the two screens close to each other. When I port servers, I prefer to have the new screen and an old one (or a dumb terminal) sitting next to each other on my desk. -- Geoff Kuenning geoff@la.locus.com geoff@ITcorp.com