All Stories

搞定源代码断点

  今天主要搞定了源代码断点,之前遇到的如果有断点,debuggee启动就会崩溃的问题,其实是通过socket发送命令过去后,debuggee在接收时会把不完整的信息压入到队列中,跟昨天遇到的回应消息不完整是一个道理。   最后我仍然是采用了完全使用debug库的功能实现的方式,这种方式的缺点是调试执行的效率很低,因为每次debug库回调时,都要判断一下是否在当前行有断点。至于之前我想过的那种快速断点的方案,就留到以后版本中实现吧!

修正了一堆问题

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

进展不错

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

代码合得没问题,哈哈

  前次说到,我觉得我把wxScintilla的代码合得有问题了,我的程序中使用了wxScintilla不能多选。其实是我毛躁了,没认真看Scintilla的文档。其实当时我也是浏览了一遍代码的,发现在wxScintilla中处理用户输入后,就直接转发到Scintilla的平台无关的代码中去了,而这部分平台无关代码我基本是严格复制了官方Scintilla的代码,所以照理是应该没问题的。昨天在整理《Free Software Collection》一文时,考虑到用什么软件来替代UltraEdit,结果发现SciTE的列编辑模式已经可以做得跟UltraEdit很接近了,看了看修改版的SciTE-Ru,也同样如此。当时我还有点怀疑是不是需要在容器应用程序中做单独的处理,想想又有点不太可能。看了一下SciTE-Ru的配置文件,发现是有这么个选项的,后来就去看Scintilla的文档了,看到在Multiple Selection & Virtual Space一节里,确实有相应的设置选项。   土了啊,代码合得没问题,哈哈!

成功恐惧症

  我是突然发现,原来我患的是这个病:成功恐惧症!在《反模式》中看到,原来我这样的病症并不唯一,很多人都会有,以至于他们都把它写到书中去了!   说到底,还是出于不够自信,以及毅力缺乏。古时候有句话,叫“行百里者半九十”,其中有一层含义就是最后那10%的工作是最难完成的,不光是因为可能工作内容的难度增加,还有执行者心理上的障碍,就像我这样。   一直以来,我都是一个缺乏毅力的人,很少会从头到尾认认真真地完成一件事情。不论是工作,还是其他生活中的琐碎的小事,比如看书,总是会把最后一部分丢掉。以前有领导说我,做事情总是喜欢只做到90分,而不去追求那完美的100,我不以为然,我是有点小骄傲的,有点自以为是的,这种关键部分有技术难度的部分完成了么,剩下的修修补补让别人去做好了!   现在不行了,所有的事情都得亲历亲为了,这个毛病带来的隐患就爆发了,将将引起严重后果了。记得类似的严重情况在公司时有过一次,那是我第一次独立负责一个特性,不但要完成自己的功能,还得提供接口给其他人使用,到了最后那段时间,心里非常焦虑,极度没信心,到后来都是只敢埋头写代码,不敢调试运行,生怕调试不过,把自己打击得再无法拾起从头来过的勇气了。最后运气很不错,因为本来也只是简单地调用别人的接口,我自己的特性完成后,提供给别人的接口基本功能也是能保障的。   眼下我那个调试器部分,已经持续2个月了吧,一直没有正常的进展,实在是挑战我的心理承受能力。我只能强行扭转自己的心理喜好习惯,自我灌输些心理暗示,希望能顺利度过这一关吧!

宿命化

  我有经常看一下Google Analytic的习惯,差不多每天上网的话都会去瞧一下。发现有好些访问,从从搜索引擎(Google)那里通过关键字“星座”、“双鱼座”等等过来的,今天还发现有个“双鱼座今年会和喜欢的人在一起吗 ”,让我觉得比较好笑。   我是个有点迷信星座的人,但只迷信它的大概的说法,对于每日/每月/每年的运程,我就不太信了。已经不记得在什么时候了,看过一段有点“伪”科学的解释,星座按出生月份划分,正好当时母亲在怀胎十月以及分娩时分受天气变化的影响,由此可能影响了胎儿的大脑等,就会影响到人的性格,而性格决定命运,所以我觉得似乎是有些道理的。   跟小师妹聊天时,偶尔会提及到我的缺点短处,我常会说“双鱼座就这样的啊”,小师妹就说我太宿命化了。以前确实没想到这层面上去,但被小师妹这么一说,我虽然表面上还说什么扬长避短之类的来狡辩一下,实际上心里有点惊悚的。照理说,我一直以为自己是一个不甘于受命运摆布的人,怎么这事上,就这么懦弱了呢?我一直认为人的出身已经注定,但通过后天努力是可以在一定程度上修改自己的命运的,可是现在想想,对于那些已有的缺点,我或无视之或逃避之,对于它们可能造成的不良影响完全无动于衷,这不是掩耳盗铃儿响叮当嘛!是该好好反省下了。   话说,昨晚居然梦见跟小妞一起看一本围棋书,醒来后真是心有余悸而力不足,不过好像在周公解梦中,男人梦见读书好像是好事呢!

代码合得有点问题

  用了wxScintilla,我一直试图让其中用到的Scintilla代码保持跟官方CVS中的同步。现在发现,还是合得有问题了,功能没合进来,但是光是看代码,我也不知道到底哪里出错了。具体的现象是,现在官方的Scintilla是已经能直接支持多块选择了,昨天试了试我的程序是不行的。不过这个问题暂时倒不要紧,可以放到以后去修改。   看到SciTE开始有实验性的支持使用Lua脚本实现lexer了,不过接口还没有稳定下来。不过我猜这个特性可能不会合到Scintilla里面去,而且即使合进去了,我暂时也没有这个需求。   自从前些天看到TextMate的Bundles的介绍,以及Zen Coding的介绍,心里一直蠢蠢欲动!VS在有VA强大的智能提示的帮助下,或许可以不用这种方式的支持。但对于已经习惯于UNIX使用文化的人来说,这种自动代码生成方式是很符合他们的使用习惯的,而且同时又能极大地提升编码效率。我就开始琢磨着能不能也实现一下。   Zen Coding的效果看来,主要适用于HTML这种从SGML衍生而来的标识语言,这主要是它的语法,以及它的生成代码上的限制,所以如果不是这方面的应用,可以暂时不管它。   而TextMate的Bundles看起来就很让人心动了,以前只是听说过却没有直观地体验过,所以感触不深,前些天看了一些评论和操作视频以及manual,冲击太大了。当然这种机制在Windows平台上命令行工具并不流行,脚本解释器又不默认安装的环境下,可能不如Linux/Unix/Mac上那么突出,但如果能做成对少数几种工具、脚本语言的支持,也是很有诱惑力的。   大概想了下,如果要实现这套机制,要修改一下Scintilla中对Tab和Back Tab的实现。目前Scintilla中的Tab有两种不同的行为,如果选中整行或多行了,则会对选中行进行缩进,其他情况则是插入空格或制表符。在Bundles中或者说Tab Triggers中,Tab又多了两种行为,一个是缩写扩展,如果同时有多个扩展使用相同的缩写,则要显示AutoCompletion下拉框,另一个是缩写扩展后光标自动跳转。所以我的想法是,要在Scintilla原来的两种行为中增加缩写扩展的行为,并在内部保存一个状态,表示缩写扩展后,所有的Tab操作不再进行默认的缩进或插入空格(制表符),而是在这些时候都给个通知,让宿主程序自己处理这个操作。而宿主程序在适合的时候再发个消息给Scintilla重置那个状态,以便Scintilla又退回原来的Tab处理方式。   算了,不说了,先搞定调试器,再来看这个吧!

Windows下编译器内存分配释放性能对比(续)

  今天搞到了C++Builder2010,里面的bcc是6.21版本,相比bcc5.5,也是经过4个版本升级了,隐约记得在某个版本中,把CRT中的内存管理部分改用FastMM了,所以它的表现应该有所不同。   经过与前一次基本相同的测试,得到结果。从该数据中可以看到,6.21版本提升了多线程情况下的小块内存操作的性能,在1024字节以下的malloc测试中,表现优于所有其他的编译器!但在1M字节以上的测试中,还不如bcc5.5版本。而且,它的new操作耗时比malloc操作耗时多很多,大约是半倍到一倍的样子。在单线程小块内存的操作中,表现可以用技惊四座来形容,直逼OpenWatcom,甚至偶尔略有超越。但是在大块内存操作中,反而都不如原来BCC5.5。   详细测试用可执行程序与测试结果可以点击这里下载。

Windows下编译器内存分配释放性能对比

  前些天有人在群里说起测试malloc和HeapAlloc的效率,后来又在豆瓣上有人讨论起大块内存的策略问题,于是我决心再稍微仔细地测试一下各个编译器在这方面的表现。   首先,我选取了OpenWatcom 1.8、Digital Mars 8.51、Borland 5.5、MinGW GCC 4.4.0、MSVC 2008、Intel 11.0.061一共6种编译器,除了Intel C++,其他的编译器都可以在网上下载并免费使用。   然后写了一个非常简单的小程序,分别对1字节,1000字节,1024字节,1M字节,10M字节和50M字节进行重复的分配和释放,前三种大小重复15000000次,后三种大小重复150000次。为什么前三种的重复次数是后三种的100倍呢?因为测试过程中我发现,后三种的耗时在某些编译器中太长了,等不及了!   接着,使用所有这些编译器编译出4种不同CRT配置的可执行程序。分别是单线程静态链接,单线程动态链接,多线程静态链接和多线程动态链接。我都是使用bjam的默认参数编译的,其中Intel编译器不能生成单线程静态链接的可执行程序,但我想影响很小,也就不再追究。   最后就是运行每个程序,我的机器配置是Thinkpad T43,1.86GHz的P4m,1.5G内存,Windows XP SP3。每种跑10次,计平均时间,可以得到一些有趣的结果。从不同的维度观察这些数据,可以得到不同的结论。   先比较不同编译器间的差别。从实际上看,MinGW和Intel都是使用了msvcrt,只不过默认情况下MinGW使用的是6.0版本,Intel则使用当前安装的VC的最高版本的CRT库,我的机器上是9.0,所以总的说来这三者的差别应该不大。   在1字节的大小时,Digital Mars表现平稳而出色都在2s出头,而VC、MinGW和Intel都超过3s,OpenWatcom跟VC类似,但在单线程静态链接时就爆发了,只需要1s出头,而Borland在单线程中都只用1s多。   1000字节的测试基本与1字节的情况相同,但Digital Mars的耗时却飚升了近1倍!   而1024字节时,VC、MinGW和Intel的耗时又比1000字节时多了近1倍,看来这1000和1024之间有个阀值影响msvcrt使用不同的分配策略。   在1M、10M和50M字节的测试中,三个测试的数据差别不大,但与前三者的测试数据比较可以看出,OpenWatcom和DigitalMars的表现平稳,变化不大,但使用msvcrt的三者则耗时飚升,大约是前二者的400~500倍,是1024字节的200~250倍,这个差别比较大!   总的说来,Borland C++只有在单线程,小块内存分配时的表现还不错,这在DOS时代是好的,但进入了Windows时代,程序开发纷纷往多线程,大内存占用的方向发展时,它几乎没有进步。Open Watcom是受分配内存块大小影响最小的,几乎没有变化,而且总体上它在各个横向比较中性能是最好的。Digital Mars略次于Open Watcom,但它在单线程或多线程,静态或动态链接中几乎没有差别,估计最终使用的是同一个CRT库。VC、MinGW和Intel的表现基本相同,除了单线程静态链接小块内存分配外,其他情况都略好于Borland C++,所以可以看到Intel编译器的优化是集中在指令流的调整上,而对内存这块是忽略了。...