挖井

类库大魔王的挖井日记

挖一口属于自己的井


修正了一堆问题

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

本文地址:

https://minidump.info/blog/2010/02/e4-bf-ae-e6-ad-a3-e4-ba-86-e4-b8-80-e5-a0-86-e9-97-ae-e9-a2-98/

上一篇

进展不错

  这两天整调试器,经过不怎样的努力,到现在为止,功能上基本算是具备了,不过就是剩下些bug,主要有:  从debuggee发送过来的信息有时候经过XML解析会出错。  从debuggee发送过来的信息,有时候没有调用栈信息。  断点工作不正常。  有时候刚启动debuggee,debugge...…

CodingStudio Editor,IDE Lua,Script Shareware 全文阅读
下一篇

搞定源代码断点

  今天主要搞定了源代码断点,之前遇到的如果有断点,debuggee启动就会崩溃的问题,其实是通过socket发送命令过去后,debuggee在接收时会把不完整的信息压入到队列中,跟昨天遇到的回应消息不完整是一个道理。  最后我仍然是采用了完全使用debug库的功能实现的方式,这种方式的缺点是...…

CodingStudio Lua,Script 全文阅读