今天可算是最近两个月来状态最好一天了，修正了一堆问题，以至于调试器工作得像样起来了，剩下只要完成源代码断点的功能，就接近可发布的状态了！
这里简单记一下这些已解决的问题。
一开始，是有各种奇怪的问题的，比如在Lua扩展中解析XML格式的回应信息时，会报invalid node，有时候又会报call stack节点不存在，有时候在VS的调试器中运行时，会在分配内存的时候异常。这些问题，最终的原因可能是相同的。我的设计是另有一个工作线程通过socket在与debuggee进程通信，它会接收debuggee进程发回来的回应消息，并把这些回应消息压入一个队列中。而界面线程，会在应用程序消息空闲时，从该队列中撮回应消息，并转发给Lua扩展进行处理。这时我犯了一个错误，我会把一个可能不完整的消息结构体压入队列中，而界面线程取出处理时，并不能检测出是否内容完整。而且，我还是通过动态堆分配来存储这些额外信息，在界面线程中又会去释放这块内存，于是工作线程很可能去读写一块已经无效的内存。
另一个问题是，debuggee有时候会启动即崩溃，通过打印的调试信息显示，是boost::shared_ptr的使用有问题。我仔细检查了代码，发现只有两个boost::shared_ptr，还发现，其中有一个是不必要的，那是一个放在线程函数中的临时对象，生命周期只在该线程函数中有效，所以换成栈上创建就可以了。这样一来，后来经过几次测试，也确实没再出现崩溃。
还有问题是，只能调试一次，再启动debuggee就自动退出了，还有调试的时候用户手动停止调试，debugger会崩溃。其实这是没有仔细划分好各模块的职责，没有仔细设计各模块交互的协议。后来总结发现，如果debuggee要退出，分两种情况，即自动运行完退出和手动强制退出，无论哪种退出，都给Lua扩展发送一个通知，然后Lua扩展把调试端口（socket通信）停掉，而这个通知如果debuggee有能力发（手动强制退出），就让debuggee发，如果没能力（自动运行完），就让debugger发。而手动强制退出，则是只要向debuggee发送个退出命令就可以了。
今天心情真舒畅啊！
支付宝扫一扫
微信扫一扫