KDE项目开发人员调试问题解答
（文：David Faure 廖铮编译 2001年07月16日 18:20）
你必须设置环境变量KDE_DEBUG（设置为1或者你实际喜欢的任何东西）。
所为核心文件就是应用程序崩溃的时候的内存影像。使用核心文件，你现在就可以知道设置了哪个变量，应用程序是在哪个地方崩溃的。某些发布版程序禁止生成核心文件。为了重新启用这一功能，请使用“ulimit -c unlimited”命令。
只要你在程序崩溃后获得核心文件，你就可以用gdb appname core命令察看核心文件的内容。这样就会对给定应用程序核心文件打开gdb，一旦gdb提示符出现，最有用的命令就是“bt”，该命令产生崩溃信息的记录（backtrace）。
要了解如何使用gdb的更多信息请参看该页。
| Q：打印stederr上的debug输出有更好的方法吗？ |
有的，你可以用kdDebug():kdDebug() << "KMyApp just started" <<endl;
该命令语法很像cout，“<<”之间可以使用多种内部类型。这样就会打印出调试信息，这些调试信息在程序发布的时候会自动关闭（通过--disable-debug）。如果你希望程序发布期间还要获得这些消息，那么，因为这些消息都是警告或者错误，你不妨使用kdWarning()或者kdError()达到这一目的。
组件和库最好使用调试区域代码，比如kdDebug(1234)。使用“kdebugdialog”程序（它是kdebase的一部分）可以关闭或者打开该区域号码的调试输出信息，“kdebugdialog --fullmode”还允许控制记录输出的位置。
说白了：不要使用qDebug()，该函数在程序发布的时候不会被禁用。还要避免使用assert()或者kdFatal()，他们会在出现问题的时候导致程序崩溃，对用户没有半点好处。最好在程序中检测错误，如果可能的话，输出kdWarning或者kdError再行恢复。
kdDebug()函数是一种简单、高效的应用程序调试方式。
gdb，GNU调试器是逐步执行和检查变量的最快方法（最好用5.0版本，该版本比4.1.x好多了）。
kdbg是采用KDE GUI的gdb前端。它支持多种Qt类型（包括QString）。
Memory leak tracer ：参看kdesdk/kmtrace。README解释得很全。
kdcop和dcop可以让用户浏览dcop接口、方便地执行dcop调用。
请查看该页面和kdesdk，那里有用的脚本很多。
请查看kdesdk，在你的~/.gdbinit中加入以下命令：
source /path/to/kde/sources/kdesdk/scripts/kde-devel-gdb
然后就可以在gdb中打印qstring myqstring察看其内容。
比如，QString myqstring = QString::fromLatin1("contents"); 可以使用以下的命令来检查：
(gdb) printqstring myqstring
$1 = 99 'c'
$2 = 111 'o'
$3 = 110 'n'
$4 = 116 't'
$5 = 101 'e'
$6 = 110 'n'
$7 = 116 't'
$8 = 115 's' |
请参看kde-devel-gdb文件了解其它定义宏。
| Q：当我调试kpart应用程序的时候我没有符号（symbol），我该怎么办？ |
你必须在主程序之后停止下来装载共享库的调试符号。之后，你就可以正常调试了。你甚至可以创建gdb宏以便停在被装载的part后面。以kword为例，我编写的代码如下所示：
define startkword
break main
run
break 'KoDocument::KoDocument(int, QWidget *, char const *, QObject *,
char const *, bool)'
cont |
请参看kdebase/kioslave/DEBUG.howto。
（责任编辑 吴北 jiaoxq@staff.ccidnet.com）
|
