English

带您走出调试云雾

2009-08-12 来源:中华读书报 作者:■monkeycz 我有话说
记得几年前我们公司对一款核心产品进行升级,测试人员发现了一个会导致整个程序崩溃的BUG。这个BUG在程序的运行过程中随机出现,很难重现。更为棘手的是,当开发人员用VC以调试模式运行该程序,BUG就再也不重现了。根据
以往的经验,这种情况多和多线程处理导致缓冲区非法操作有关,调试器引起的“海森堡效应”会导致程序在这种情况下可能无法重现BUG。开发人员之前常用的LOG定位法在多线程程序中也显得力不从心,线程的交错运行使得LOG根本无法在程序崩溃的时候定位到正确的位置。当时已经是产品发布的前夜,重新检查可疑的相关代码已经不可能了,工作量太大,时间不够用。于是我们只好试图改变调试手段来解决问题。当我们尝试了一种可行的调试方法后,BUG迎刃而解,从定位到代码修复完成总共花了不到十分钟。方法很简单:当程序崩溃的时候,对程序进程附加上调试器,根据调用堆栈分析可能引发缓冲区问题的位置,然后通过在源码中对应的位置加上“__asmint3”语句使程序可以在运行时激发调试器,继而对将要引发异常的内存区域设置读写断点,在激发断点后终于顺藤摸瓜找到了罪魁祸首。而在此之前我们已经在门外摸黑乱撞了两个小时!

正确可行的调试技巧在软件开发中是如此重要,奇怪的是,这个事实在多数开发者那里并未引起足够的重视,也许是“Debug”更多时候是和“Reverse Engineering”这个神秘的名词画上等号而显得高深莫测,使得一般的开发人员和初学者望而生畏踟蹰不前。其实在日常的开发中,调试技术使用非常普遍――当一段代码编写完成,在合适的地方设下断点,启动调试器,等待程序运行到断点处,查看运行流程和相关变量是否符合预期;或是为了修正程序中存在的逻辑上的BUG,使用调试器进行逐句跟踪,寻找引发错误的关键点――这些都是最常见的调试工作,但也只是调试技巧的简单应用。与其说是“调试”,倒不如说是“测试”,以调试技术来实施单元测试,未免有些大材小用。在我看来,“现场分析”、“状态回溯”、“事后调试”之类的技术才更加接近调试的精髓。所谓“调试技术”,就是分析归纳的技术。它引导你从程序崩溃的废墟中一点一滴地搜集蛛丝马迹,再从中抽丝剥茧归纳整理,依靠有预见性的想象和符合事实的推理,从而还原出一个真实的错误景象。

最近收到了一本机械工业出版社出版的《Windows高级调试》,原以为是给分析人员使用的工具用书,仔细翻阅了几章,却发现并非如此。在这本书中,作者针对一般的开发人员和测试人员,深入探讨了调试技术的“高级”应用。书中通过融入一个个实例当中的调试过程和技巧,由浅入深地讲解操作系统的内部运行机制和调试的基本原理。深入阅读,你会发现Debug不再是hacker手中的“奇技淫巧”,而是软件开发过程中的有力工具。对于有经验的分析人员,这本书同样值得一读。相信书内详尽的描述和深入的分析能够印证你对操作系统底层构架的理解,并在调试技术上予以新的启发。

  (《Windows高级调试》,[美]Mario Hewardt;Daniel Pravat著,聂雪军译,机械工业出版社,2009年6月,79.00元)

手机光明网

光明网版权所有

光明日报社概况 | 关于光明网 | 报网动态 | 联系我们 | 法律声明 | 光明网邮箱 | 网站地图

光明网版权所有