15.9 调试提示

自我保护的程序,错误报告何其它的编码技术只能帮助你这么多了,要单步跟踪你的代码,检查每个变量的值,准确的告诉你你的程序有什么异常行为或者从代码的什么地方退出,你还需要使用一个调试工具.因此,针对你的代码,你至少需要维护两套配置文件,一套调试版本何一套正式版本.调试版本将包含更多的错误检测,将关闭编译器的优化开关并且将包含调试程序需要的文件名,行号等调试信息.在调试模式,宏WXDEBUG总是被定义了,因此你可以使用这个宏来编写那些仅存在于调试版本中的代码,不过类似wxLogDebug这样的函数,即使你没有使用WXDEBUG宏将其包含,它仍然将在正式版本中被移除.

确实有很多人从来没有使用过调试器,但是在你熟悉了这些工具以后,它将大大降低你的工作量.在windows平台上,VC自带了一个很不错的调试器.如果你使用的是GCC,你可以使用GDB工具包,它工作在命令行模式下,你也可以使用一些集成了GDB的IDE环境.更多的信息可以参考附录E,"wxWidgets的第三方工具".

wxWidgets支持同时编译多个版本.在windows平台上,你可以给对应的Makefile传递BUILD=debug或 BUILD=release这样的开关.如果你使用的是configure程序,你可以配置不同的版本编译在不同的目录,然后在各个版本中使用类似-- enable-debug或--disable-debug这样不同的开关.某些集成开发环境出于各种各样的原因不允许你的应用程序同时使用不同的配置文件,对于这样的集成开发环境,作者的忠告是:不要使用它们.

调试X11错误

极少的情形下,wxGTK程序会由于X11的错误而崩溃,这时候你的应用程序将立即退出而不给你任何栈调用情况的打印,这种问题是非常难以跟踪的,在这种情况下,你需要象下面代码展示的那样,增加一个错误处理函数:

#if defined(__WXGTK__)
#include &lt;X11/Xlib.h&gt;
typedef int (*XErrorHandlerFunc)(Display *, XErrorEvent *);
XErrorHandlerFunc gs_pfnXErrorHandler = 0;
int wxXErrorHandler(Display *display, XErrorEvent *error)
{
    if (error->error_code)
    {
          char buf[64];
          XGetErrorText (display, error->error_code, buf, 63);
          printf ("** X11 error in wxWidgets for GTK+: %s\n  serial %ld error_code %d
 request_code %d minor_code %d\n",
           buf,
           error->serial,
           error->error_code,
           error->request_code,
                   error->minor_code);
    }
    // 去掉下面的注释以便将错误重定向道你的处理函数.
#if 0
    if (gs_pfnXErrorHandler)
        return gs_pfnXErrorHandler(display, error);
#endif
    return 0;
}
#endif
  // __WXGTK__
bool MyApp::OnInit(void)
{
#if defined(__WXGTK__)
    // 安装错误处理函数
    gs_pfnXErrorHandler = XSetErrorHandler( wxXErrorHandler );
#endif
    ...
    return true;
}

现在,你的应用程序在遇到这样的错误的时候,将会产生一个普通的段错误.如果你在启动你的应用程序的时候传递了--sync参数,这个段错误将正好显示在被传递了错误参数的X11函数的地方.

一个简单有效的定位问题方法

如果你确实碰到了一个很难定位的问题,一个好的方法是使用尽量少的代码来重现这个问题,你可以修改wxWidgets自带的任何一个例子,增加一些代码来重现你的问题,或者把你的代码制作一份拷贝,逐段的去掉那些不影响这个错误的代码,直至你可以准确的定位出是那些代码导致了这个错误的产生.如果你认为这是wxWidgets本身的错误,把你修改后的导致问题出现的wxWidgets例子发送给wxWidgets社区,相信这个问题将被很快修正.

调试一个发布版本

某些情况下,你的应用程序可能在调试版本工作正常,而在正式版本中则工作不正常,这可能是由于编译器使用的不同运行期库文件的细微差别导致的.如果你正在使用的是VC,你可以创建一个和调试版本一模一样的配置,但是却定义了NDEBUG宏,这将使得你的代码和wxWidgets和调试信息都具备,运行的时候却使用的是发布版本的运行库.这至少可以让你确定是不是由于运行期库的原因导致了这个问题.

通常当你发布你的应用程序的时候都将使用去除了所有调试信息的版本,但是有时候你的客户会遇到一些在你的机器上很难重现的问题,,这时候你可能想给你的用户发送一份调试版本的程序(在windows平台上,通常你需要使用静态编译的方法以避免同时发送那些调试模式的动态链接库).然后在你的客户的机器上,可以使用一个叫做Dr.Watson的程序来运行你的包含调试信息的程序,在程序异常退出的时候,将会产生一个文件记录当时的情况.参考你的编译器的信息以及网上的教程来了解怎样使用由Dr.Watson产生的这个文件来定位你的代码中的异常.

如果你使用的是MinGW,你可以使用一个叫做Dr.MinGW的工具来在程序异常退出时候打印出一个有用的当前函数调用堆栈(当然, 如果你的代码包含调试信息(打开了-g开关)的话).你可以从 http://www.mingw.org 下载这个工具,如果你的客户有耐心并且很合作,你可以把这个工具发送给他们然后让他们把产生的报告发送给你.

在Unix平台上,调试版本的可执行文件可以产生一个core文件(这依赖于系统的设置,参考Unix命令ulimit的man手册).你可以象你平时调试可执行文件那样使用这个core文件,以便观察程序退出时候的现场情况.然后,这个core文件可能会很大,你的客户可能不大愿意发送给你这样的一个core dump文件.

另外的一个替代方案是,你可以在你的程序中自己记录程序的重要的执行情况.这方面你可以参考wxWidgets手册中 wxDebugReport类相关的内容,这个类可以产生一个合适email给程序开发商的报告.类似的,你还可以使用来自http: //wxcode.sf.net的wxCrashPrint(for linux)或者来自 http://www.codeproject.com/tools/blackbox.asp 的BlackBox(for windows).