All Stories

可以自动提交dump分析记录了

  今天花了近一天的时间,重新写了一遍自动分析mini dump然后将分析结果提交到wiki上的程序。通过这次实践,也确认了我原先的想法是可行的,内嵌一个IE,然后通过它暴露的COM接口,进行一些基本的操作,主要有遍历已有元素,填充TextArea,提交。只是发现这些操作,全都不是阻塞的,所以具体应用的时候还是得留心一下。  晚上加班,看了一下一个公司的人写的ppt,介绍Erlang的,看得让我觉得有点不舒服。按我的理解来看这ppt,似乎他的意思是公司目前使用C/C++来开发电信类软件,而且有那么多的问题,而Erlang从语言的机制上就提供了不少的保障机制,可以写出更快更稳的程序来。让我感觉他在鼓吹这就是银弹。就我以为,写这个ppt的目的就不明确,或者说就算明确了,也是动机不纯,我们应该立足于眼前,如何提高公司开发人员的设计和编码水平,而不是考虑着换一种语言就妄图可以解决一堆问题。  不过总的说来,我看了《Erlang程序设计》中的前面一两章后,就觉得这是我真的需要的一种东西,也许它在保证并发上,或者FP编码风格的处理上并不完美和彻底,但就目前看来,它应该是比较适合我的需求的一个选择。

原来一直都理解错了

  嗯,一直以来都以为UTF-8和Unicode是一类的,今天才明白过来,UTF-8确实明明是多字节一类的才对啊,我的理解能力实在是太差了,唉!  不过今天倒是也知道了,如果只是要在ANSI、Unicode、UTF-8之间进行转换,使用两个Win32 API就可以全部搞定了,不需要用什么iconv和ICU了。总是觉得微软做的东西易用性真的很好,通用软件产品很适合普通用户使用,而那些开发工具、库、API对于开发者来说,也很好用啊!  唉,我也就只用玩一下这些容易的东西了。

桌面时钟换肤

  看到搜狗输入法网站上有那么多皮肤,想到哪里可以利用一下。最后想到,桌面时钟啊,以前为了弄些皮肤来,还找了不少其他的桌面日历桌面时钟之类的小程 序,把它们的皮肤里的图片都抠出来,然后转换成自己的程序可以用的格式,还真花了不少时间。输入法的皮肤与桌面时钟的布局有些微差别,于是只好只用来显示 一下数字了,不能显示那种模拟钟面的了又花了近8个小时吧,其中还有不少代码是直接复制的。好在搜狗皮肤文件是用ZIP打包的,这比较方便,原先写的那块 解压缩的功能是调用7z实现的,那接口太繁复了,不好用,还自己特地写了个小小的dll来简化,但还是怎么看怎么觉得不爽。这次就索性全部改成zip的, 从codeproject上找了个解压zip的代码。  刚弄得可以显示出来的时候,发现显示的字体有点问题。首先是字体很小,其次是字体显示部 分是透明的,颜色不明显。字体小我倒不是很关心,但颜色不明显就比较严重了,属于不可控问题了。后来乱试了一下,偶然发现用GDI+来写字时,字体不要从 HDC那里获取,而要直接从字体名称和大小创建一个,这样就可以了,两个问题都一起解决了。  演示如下:

兴致缺缺

  又要开始做环境设计编辑器了,几乎是全部重新做过。这次的计划是自己画,可是现在的我却兴致缺缺,想当年,嗯,也就是一两年前吧,我是多么的希望可以自己动手专心地实现一个这种图形编辑器啊。  我现在的想做的是把自动分析崩溃报告的事情做好。不过这种事情收益有一些,不过却不是主要业务,因为对用户来说,没有多少良好的体验可以从中体现出来。唯一的好处是,开发人员可以减少工作量,嗯,这点上我倒是真有点典型的程序员风格——懒惰!

x和dt偶尔还是有些用处的

  事实证明,x和dt偶尔还是有些用处的,有几个core dump记录,经过分析后,嗯,是x或dt后,发现就是在倒数第二次或倒数第三次调用某个对象的方法时崩溃的,而崩溃的原因就是因为那个指向对象的指针其实是个0,只要调用的方法引用了什么成员变量,那么对不起,保证完成“死给你看”的任务。想来,在知道用x和dt前,那些问题我估计是分析不出什么结果来的。  今天,抱着试试看,用VC9重新全部编译了一下Scintilla,发现真可以用了。在这之前的几天里,偶然发现只要向Scintilla发送什么消息,应用程序就会崩溃,还以为是CVS里的代码有问题。  这软件的问题啊,真是个很缠人的事啊!

除了!analyze -v外什么都不行

  那些个core dump,都是我抠了FileZilla早期版本中的源代码出来,利用DbgHelp.dll的功能整出来的mini dump,本来有点迷惑的为什么查看变量内容时,老说访问内存错误,又翻了一会儿书才偶然发现,原来是这mini dump本来就只保存了寄存器和栈回调的信息,这也可以理解了,不然加上完整的内存dump,怎么可能只有几十KB大小。于是只好很沮丧地得出一个结论:对于mini dump,除了!analyze -v外,还真的什么都不行。

除了!analyze -v外

  今天发现,对于core dump文件的分析,除了!analyze -v外,还可以.frame一下,再x或者dt一下的。不过也就只能这么一下了,而且不知道为什么,那时x或dt出来的对于之前调用栈中的内存,显示都是读取错误,而且有时候看地址似乎也真的不对。  由于发现了x和dt这样的命令,于是今天在分析core dump时也稍微卖力了点,不过最后我却又不得不怀疑我这样的理解是不是正确的,因为有两个core dump到最后分析出来都是因为类指针为空而对它进行提领,而看代码实现是很不像会出现这种指针为空的情况啊!我大汗!  还是得继续学习啊!

写程序是件很诡异的事

  上午花了两个多小时,嗯,确实是两个多小时,写了个小程序,每隔一段时间扫描一下指定的文件夹下所有core dump文件,和历史数据库中的记录进行比较,如果历史数据库中没有记录,则认为是新追加的文件,一边将其添加到历史数据库中,一边则使用cdb.exe通过命令行进行分析,最后将分析结果连同那个core dump文件一起通过SMTP协议发送到notes邮箱中。  其中遇到不少奇怪的问题。本来是打算cdb.exe将分析结果重定向到文件后,自己读一下这个文件的内容,把这个内容作为邮件的正文发送的。结果首先是发现,使用system这个CRT函数,其中是调用了cmd.exe /c这个命令行,所以如果传给这个函数的参数如果同间有空格,是要用双引号包括起来的。尤其要注意的是,如果打算执行的是一个带参数的命令行,得从头到尾一起括起来。接着我就想用ifstream的方式把文件内容读出来,然而很诡异的是,直接将其输入到一个stringstream时,只有一小部分内容读出来了;通过getline一行一行读出来后,本来打算全部追加到另一个string中去的,但是就是追加不进去,最后想使用API吧,直接CreateFile,再ReadFile,内容但是全读出来了,最后通过SMTP发送这部分正文时,依旧只能发送前面一小部分。放弃了,本来就昆个Quick & Dirty的东西,于是还是直接把这个文本文件作为附件发送吧。也不知道是不是那个SMTP类本来就有问题,运行的过程中时不时弹出个出错信息来,什么delete指针时错了呀,堆被破坏了呀,等等等等,不一而足,实在无语得很!  不过尽管还是会弹错误框,但手工点一下也不麻烦,先这么着吧,至少可以当成一个监视器用了。  这两天我一直在想一个问题:是不是mini dump只有一个用途——!analyze -v?没有找到答案,但翻遍所有的能找到的参考资料,似乎这个猜想是真的!

炮轰Boost build

  今天在Boost的开发maillist上看到有人在抱怨Boost Build系统的不好用,我难得耐下性子来看了看,其中提到好几个问题:Getting Start文档中没有明确的说明命令行;编译MPI库需要修改user-config.jam文件;与ICU一起编译Regex库会报静态链接和动态静态不兼容的错;解决了Regex编译时链接的问题后,用的ICU lib文件名却需要自己修改一下;编译Graph库时链接Expat时需要修改jamfile.v2文件来修改链接的lib文件名。除了MPI的问题外,其他的我也都遇到过,也都差不多自己解决了,我还真是个可以逆来顺受的人,虽然觉得很麻烦,但却想不起要求Boost来改进这些缺点。不过今天看到这个帖子后,感觉大快人心啊,哈哈!  顺便提一下,今天我找到可用通过cdb.exe来直接使用命令行对dump文件进行分析的的方法了,可以直接将分析结果在控制台上输出,这样就简单地利用管道将分析结果获取到了。这样基本解决自动分析dump文件的技术上的障碍,最多是要再自己写个小程序,可以分成两部分,分别是前端和后端。前端负责获取新的dump文件,可以是定时扫描某个文件夹,或者定时扫描email,或者通过其他的socket传输等,反正就是获取到一个新的dump,然后调用cdb.exe这个命令行,而后端则是将cdb.exe输出的结果重定向到其他地方去,可以是通过email发送出去,或者是写到数据库中,或是写到excel中,或是直接填充到WIKI上去。总之,现在怎么整都可以了。