曲径通幽

programming_with_fun();

  C++博客 :: 首页 :: 联系 :: 聚合  :: 管理
  18 Posts :: 0 Stories :: 5 Comments :: 0 Trackbacks

常用链接

留言簿(6)

我参与的团队

搜索

  •  

最新评论

阅读排行榜

评论排行榜

#

  最近发生一件有趣的事。过去一段代码在64位windows系统上运行有问题。一个 CopyFile的API返回正确,但目标目录system32下却没有相应文件。
  查找了一遍,发现syswow64目录下有该文件,于是猜测OS做了目录映射。
  后来找到了依据:http://support.microsoft.com/kb/942589
  32-bit APP在64-bit OS上运行,很多方面都需要学习。

posted @ 2010-11-01 00:07 Meiosis 阅读(328) | 评论 (0)编辑 收藏

  最近QQ游戏开发群里有一位朋友出了一道题,“如何在基类中调用子类独有的函数,而不调用强制转换”。这道题我一时间没做出来,但是如果放宽限制,其实可以玩一个有趣的游戏。
  如果题目改为“如何在基类中调用子类独有的虚函数,而不调用Class类型强制转换”,那就可以利用C++对象模型中的虚表的直接访问来实现父类调用子类的特有虚函数。(注意,这里特有是指子类有而基类没有。)
  以下是我的解法,也在QQ群里发了,想不到引起群成员小小的轰动,看来游戏开发还是有很多同学对底层不感兴趣啊。

 1 #include <stdio.h>
 2 
 3 class CFather{
 4 public:
 5     virtual ~CFather(){}
 6 };
 7 
 8 class CSon : public CFather{
 9     virtual ~CSon(){}
10 
11     virtual void DoSomething(void){ printf("son is crying\n"); }
12 };
13 
14 int _tmain(int argc, _TCHAR* argv[])
15 {
16     CFather* fa = new CSon();
17     DWORD dwDoSomething =  (*(DWORD*)(*(DWORD*)fa+4));
18     _asm MOV ecx, fa
19     _asm CALL dwDoSomething
20 
21     system("pause");
22     return 0;
23 }
24 
25 


posted @ 2010-10-18 18:07 Meiosis 阅读(2173) | 评论 (1)编辑 收藏

  由于自己是写Server端程序的。最近有个别客户反映在服务端负载量大的情况下,经常有客户端的TCP请求处理超时。看了log文件,发现是服务端接收请求之后,未能及时处理请求并回复客户端应答造成。
  仔细观察了请求的处理过程,唯一耗时的就是文件I/O的Flush操作,因为这个操作会强制要求OS提交IO请求,而不是用OS自带的IO缓冲。如果在IO处理非常频繁的情况下,的确会导致服务端I/O告急,磁盘压力过大,性能大幅下降,

posted @ 2010-08-24 19:14 Meiosis 阅读(717) | 评论 (0)编辑 收藏

  昨晚有客户反应,产品中的某个进程启动后1分钟内会消失,看了log未发现异常。
  于是远程过去,想看本溃报告,很遗憾的是,没有生成任何本溃报告(我们用的是Debug系列的api写的Crash Reporter)。情急之下,唯有求助伟大的Windbg了。
  attach,g,过一会儿,果然发现是有一处seh。但随即发现缺symbols,于是马上去发布服务器上找相应的pdb文件,放到远程上去,.reload,果然,未知地址被准确地翻译成代码中的标识符。
  原来,崩溃的地方是动态加载的一个dll中的一个回调函数,怪不得没捕获到Crash Report。
  总结下来,Release版本的PDB生成是个关键,单有Windbg仍旧是巧妇难为无米之炊啊。

posted @ 2010-07-22 08:26 Meiosis 阅读(327) | 评论 (0)编辑 收藏

  最近用户发现某个进程CPU占用率过高,导致服务器假死。
  于是想用Windbg尝试调试一下。幸好我们的软件发布时都会保留一份PDB文件。因此Windbg能够准确地找到Symbol,即使是Release Version。
  打开Windbg帮助文档,搜索"CPU"关键字,随即找到了“Tracking Down a Processor Hog”。按照上面的方法试了一下,果然可以准确地定位到某个死锁的线程。
  现在在工作中,利用Olldbg和Windbg的机会越来越多,在解决问题的过程中,也越发有成就感了。

posted @ 2010-07-12 19:17 Meiosis 阅读(1902) | 评论 (0)编辑 收藏

  今天在Code Project最新更新中看到"XCrashReport : Exception Handling and Crash Reporting"一文,泛读之后,又读了其中引用的几篇文章。觉得挺不错。主要讲了VC Relase版本如何定位问题,主要思路是打开Link选项"Generate debug info"、添加参数"/OPT:REF"和/ignore:4089 ",用作Release版本产生PDF,且优化的时候能使产生的目标文件更小。效果比较明显。
  随便写了一个会崩溃的工程,崩溃后记录其崩溃位置,然后随便打开一款调试器(OD,WinDBG,VC都可)运行debug,然后改EIP到出错的位置下断,GO!
  其实,在运行出错的位置,然后改EIP的方法,以前在用OD时会使用到(类似F4或VC调试时的移动EIP),一直觉得ESP和Call Stack应该是分析Crash的重点,有时忽略了EIP的重要性。
posted @ 2010-07-01 14:43 Meiosis 阅读(254) | 评论 (0)编辑 收藏

  今天在学 《Learning Cocoa With Objective-C》其中有个AddressBook的例子,会发生编译错误。原来是少了引用的依赖。
  添加方法是:Project - Add to project, 寻找\System\Library\Framework\AddressBook.framework中找到依赖的项即可。

posted @ 2010-06-20 23:42 Meiosis 阅读(2553) | 评论 (0)编辑 收藏

  最近拿到一个第三方厂家的库,由于Delphi的同事看不懂c++的例子,所以让我用C++封装一个简单的Wrapper给其调用。
  后来发现一个问题,由于原始的函数声明中的参数使用字符数组 (char szData[MAX_PATH])  而不是用常用的指针(char *),给Delphi同事调用后,发现函数调用完退栈时候程序本溃,原因是访问违例,非法地址访问0x72。
  这么一来感觉比较奇怪,0x72 这个地址显然是个垃圾地址,一般如果是空指针的话因该是 0x00,如果是野指针,一般也不至于会那么小,0x72与程序加载地址都相去甚远。
  在vc6(公司只准用vc6)里跟了一下反汇编,感觉信息缺少比较多,能看到的地方已经堆栈被破坏了。于是用了OD跟一下。发现Delphi调用我封装的 函数时,明明2个入参,却传入了3个。多传了个260。260对于vc程序员应该比较熟悉了,就是MAX_PATH的值。于是乎,告知了Delphi程序 员,方才得知,原来Delphi是可以在声明时指定数组长度的,也就是说,函数的入参,数组和指针是两种声明,如此一来,水落石出了。
posted @ 2010-06-20 23:34 Meiosis 阅读(365) | 评论 (0)编辑 收藏

仅列出标题
共2页: 1 2