Friday, September 02, 2005

Solaris application crashes

When a Solaris application crashes, it usually produces a core file,
which is a disk copy of the application's memory at the time of the
crash.

One way to generate a traceback is to use a debugger such as dbx with
the core file:

% dbx /path/executable core
(dbx) where > traceback.t

Q13: A KDE application crashed and I want to file a bug report at
http://bugs.kde.org, but the backtrace in the KDE Crash Manager is
"useless". What can I do?

A13 DrKonqi . To get backtraces from crashing applications on
Solaris you need to run them in gdb or use Dtrace (Solaris 10).
Additionally most of the Solaris binary packages are not compiled with
debugging information enabled, so you will probably have to recompile
them first:

- To enable debugging support in a KDE port, build it with
WANT_KDE_DEBUG defined. You can set it on the commandline (example:
make -DWANT_KDE_DEBUG && make install or put it into /etc/make.conf
(WANT_KDE_DEBUG=YES. A similar switch exists for enabling debugging
symbols in QT: WANT_QT_DEBUG. Note that those switches ONLY work in
the ports of the main KDE module ports like kdebase, kdemultimedia,
arts, etc. They will not work in ports of 3rd party KDE apps like for
example kmldonkey or kbear.
- To run an application in gdb, do: gdb /path/to/application. This
will give you a prompt:
(gdb)
You can run the program now by typing run:
(gdb) run
Then you make the program crash. You will be returned to the
prompt. Type bt:
(gdb) bt
and you will get the backtrace you want. Some KDE applications
spawn a new process after being launched and thus don't stay under
gdb's control - an example for such an application is kmail. To debug
those, you need to type
(gdb) set args --nofork
prior to run on the gdb prompt.

0 Comments:

Post a Comment

<< Home