类库大魔王
类库大魔王 懒惰,傲慢,以及无耐心

修正了一堆问题

  今天可算是最近两个月来状态最好一天了,修正了一堆问题,以至于调试器工作得像样起来了,剩下只要完成源代码断点的功能,就接近可发布的状态了!
  这里简单记一下这些已解决的问题。
  一开始,是有各种奇怪的问题的,比如在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发送个退出命令就可以了。
  今天心情真舒畅啊!

感觉本文不错,不妨小额鼓励我一下!
支付宝扫一扫

支付宝扫一扫

微信扫一扫

微信扫一扫

如果你看不到评论框,说明Disqus被墙了。