开发人员的月光宝盒 —— 基于CPU的“时光倒流”技术畅想

一. 重现罕见问题——开发人员永远的痛

但凡做过程序调试的开发人员,一定都有过面临难以重现的问题时仰天兴叹的经历,祈祷老天赐予传说中的“月光宝盒”,从而逆转时光揪出那引发程序错误的元凶!

即使在错误跟踪技术经历长足发展的今天,哪怕是经过周密故障跟踪机制加持的代码,程序员仍然对那些难以重现的问题提心吊胆。错误跟踪机制再先进,也难以完整记录整个程序的运行轨迹和任何过去时刻的系统状态。数据覆盖的不可逆决定了程序执行的单向性,就像时间之箭,谁也不能让它转向。但时间的单向性并不意味着过去的时光不能从头来过,就像“月光宝盒”虽然不能使你回身飞上万丈绝壁,但却可以将你带回过去的某一时刻,让后面的历史重新来过。

二. 挑战时间之箭,已逝历史也能重历?

继续阅读开发人员的月光宝盒 —— 基于CPU的“时光倒流”技术畅想

运用GDB进行UT/ST的小经验

用惯了VC/Eclipse图形化的程序调试界面后,要适应GDB这种“回归淳朴”的命令行方式,确实需要一些时间。不过当你熟悉了GDB的高级用法后,才能真正体会到程序调试那种随心所欲,尽在掌握的酣畅感。

最近一段时间用GDB作代码测试,积累了一些小小经验,希望对尚未熟悉GDB的朋友有所帮助。(本文以C语言为例说明相应的用法,其它语言可参考GDB帮助文档中对其的支持说明)

业界比较专业的UT(Unit Test,单元测试)工具很多,所以通常不必直接用GDB进行UT,但使用这些专业工具前往往需要花大力气配置环境,编译驱动等,若对于一个小项目,则比直接使用GDB作UT麻烦多了。所以,小项目往往可以借助GDB进行UT/ST合一的测试,效率提升是非常可观的。

ST(System Test,系统测试)一般需要尽可能的逼近实际运行环境,所以应尽量避免或减少对代码有直接介入的工具。这时以GDB作为测试/调试手段就非常实用了。

继续阅读运用GDB进行UT/ST的小经验