• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            曲徑通幽

            programming_with_fun();

              C++博客 :: 首頁 :: 聯(lián)系 :: 聚合  :: 管理
              18 Posts :: 0 Stories :: 5 Comments :: 0 Trackbacks

            常用鏈接

            留言簿(6)

            我參與的團(tuán)隊(duì)

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            #

              最近發(fā)生一件有趣的事。過去一段代碼在64位windows系統(tǒng)上運(yùn)行有問題。一個 CopyFile的API返回正確,但目標(biāo)目錄system32下卻沒有相應(yīng)文件。
              查找了一遍,發(fā)現(xiàn)syswow64目錄下有該文件,于是猜測OS做了目錄映射。
              后來找到了依據(jù):http://support.microsoft.com/kb/942589
              32-bit APP在64-bit OS上運(yùn)行,很多方面都需要學(xué)習(xí)。

            posted @ 2010-11-01 00:07 Meiosis 閱讀(348) | 評論 (0)編輯 收藏

              最近QQ游戲開發(fā)群里有一位朋友出了一道題,“如何在基類中調(diào)用子類獨(dú)有的函數(shù),而不調(diào)用強(qiáng)制轉(zhuǎn)換”。這道題我一時(shí)間沒做出來,但是如果放寬限制,其實(shí)可以玩一個有趣的游戲。
              如果題目改為“如何在基類中調(diào)用子類獨(dú)有的虛函數(shù),而不調(diào)用Class類型強(qiáng)制轉(zhuǎn)換”,那就可以利用C++對象模型中的虛表的直接訪問來實(shí)現(xiàn)父類調(diào)用子類的特有虛函數(shù)。(注意,這里特有是指子類有而基類沒有。)
              以下是我的解法,也在QQ群里發(fā)了,想不到引起群成員小小的轟動,看來游戲開發(fā)還是有很多同學(xué)對底層不感興趣啊。

             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 閱讀(2194) | 評論 (1)編輯 收藏

              由于自己是寫Server端程序的。最近有個別客戶反映在服務(wù)端負(fù)載量大的情況下,經(jīng)常有客戶端的TCP請求處理超時(shí)。看了log文件,發(fā)現(xiàn)是服務(wù)端接收請求之后,未能及時(shí)處理請求并回復(fù)客戶端應(yīng)答造成。
              仔細(xì)觀察了請求的處理過程,唯一耗時(shí)的就是文件I/O的Flush操作,因?yàn)檫@個操作會強(qiáng)制要求OS提交IO請求,而不是用OS自帶的IO緩沖。如果在IO處理非常頻繁的情況下,的確會導(dǎo)致服務(wù)端I/O告急,磁盤壓力過大,性能大幅下降,

            posted @ 2010-08-24 19:14 Meiosis 閱讀(738) | 評論 (0)編輯 收藏

              昨晚有客戶反應(yīng),產(chǎn)品中的某個進(jìn)程啟動后1分鐘內(nèi)會消失,看了log未發(fā)現(xiàn)異常。
              于是遠(yuǎn)程過去,想看本潰報(bào)告,很遺憾的是,沒有生成任何本潰報(bào)告(我們用的是Debug系列的api寫的Crash Reporter)。情急之下,唯有求助偉大的Windbg了。
              attach,g,過一會兒,果然發(fā)現(xiàn)是有一處seh。但隨即發(fā)現(xiàn)缺symbols,于是馬上去發(fā)布服務(wù)器上找相應(yīng)的pdb文件,放到遠(yuǎn)程上去,.reload,果然,未知地址被準(zhǔn)確地翻譯成代碼中的標(biāo)識符。
              原來,崩潰的地方是動態(tài)加載的一個dll中的一個回調(diào)函數(shù),怪不得沒捕獲到Crash Report。
              總結(jié)下來,Release版本的PDB生成是個關(guān)鍵,單有Windbg仍舊是巧婦難為無米之炊啊。

            posted @ 2010-07-22 08:26 Meiosis 閱讀(343) | 評論 (0)編輯 收藏

              最近用戶發(fā)現(xiàn)某個進(jìn)程CPU占用率過高,導(dǎo)致服務(wù)器假死。
              于是想用Windbg嘗試調(diào)試一下。幸好我們的軟件發(fā)布時(shí)都會保留一份PDB文件。因此Windbg能夠準(zhǔn)確地找到Symbol,即使是Release Version。
              打開Windbg幫助文檔,搜索"CPU"關(guān)鍵字,隨即找到了“Tracking Down a Processor Hog”。按照上面的方法試了一下,果然可以準(zhǔn)確地定位到某個死鎖的線程。
              現(xiàn)在在工作中,利用Olldbg和Windbg的機(jī)會越來越多,在解決問題的過程中,也越發(fā)有成就感了。

            posted @ 2010-07-12 19:17 Meiosis 閱讀(1965) | 評論 (0)編輯 收藏

              今天在Code Project最新更新中看到"XCrashReport : Exception Handling and Crash Reporting"一文,泛讀之后,又讀了其中引用的幾篇文章。覺得挺不錯。主要講了VC Relase版本如何定位問題,主要思路是打開Link選項(xiàng)"Generate debug info"、添加參數(shù)"/OPT:REF"和/ignore:4089 ",用作Release版本產(chǎn)生PDF,且優(yōu)化的時(shí)候能使產(chǎn)生的目標(biāo)文件更小。效果比較明顯。
              隨便寫了一個會崩潰的工程,崩潰后記錄其崩潰位置,然后隨便打開一款調(diào)試器(OD,WinDBG,VC都可)運(yùn)行debug,然后改EIP到出錯的位置下斷,GO!
              其實(shí),在運(yùn)行出錯的位置,然后改EIP的方法,以前在用OD時(shí)會使用到(類似F4或VC調(diào)試時(shí)的移動EIP),一直覺得ESP和Call Stack應(yīng)該是分析Crash的重點(diǎn),有時(shí)忽略了EIP的重要性。
            posted @ 2010-07-01 14:43 Meiosis 閱讀(269) | 評論 (0)編輯 收藏

              今天在學(xué) 《Learning Cocoa With Objective-C》其中有個AddressBook的例子,會發(fā)生編譯錯誤。原來是少了引用的依賴。
              添加方法是:Project - Add to project, 尋找\System\Library\Framework\AddressBook.framework中找到依賴的項(xiàng)即可。

            posted @ 2010-06-20 23:42 Meiosis 閱讀(2581) | 評論 (0)編輯 收藏

              最近拿到一個第三方廠家的庫,由于Delphi的同事看不懂c++的例子,所以讓我用C++封裝一個簡單的Wrapper給其調(diào)用。
              后來發(fā)現(xiàn)一個問題,由于原始的函數(shù)聲明中的參數(shù)使用字符數(shù)組 (char szData[MAX_PATH])  而不是用常用的指針(char *),給Delphi同事調(diào)用后,發(fā)現(xiàn)函數(shù)調(diào)用完退棧時(shí)候程序本潰,原因是訪問違例,非法地址訪問0x72。
              這么一來感覺比較奇怪,0x72 這個地址顯然是個垃圾地址,一般如果是空指針的話因該是 0x00,如果是野指針,一般也不至于會那么小,0x72與程序加載地址都相去甚遠(yuǎn)。
              在vc6(公司只準(zhǔn)用vc6)里跟了一下反匯編,感覺信息缺少比較多,能看到的地方已經(jīng)堆棧被破壞了。于是用了OD跟一下。發(fā)現(xiàn)Delphi調(diào)用我封裝的 函數(shù)時(shí),明明2個入?yún)?,卻傳入了3個。多傳了個260。260對于vc程序員應(yīng)該比較熟悉了,就是MAX_PATH的值。于是乎,告知了Delphi程序 員,方才得知,原來Delphi是可以在聲明時(shí)指定數(shù)組長度的,也就是說,函數(shù)的入?yún)ⅲ瑪?shù)組和指針是兩種聲明,如此一來,水落石出了。
            posted @ 2010-06-20 23:34 Meiosis 閱讀(377) | 評論 (0)編輯 收藏

            僅列出標(biāo)題
            共2頁: 1 2 
            国产免费福利体检区久久 | 欧美久久久久久精选9999| 久久人人妻人人爽人人爽| 久久久久99精品成人片欧美| 国产成人精品综合久久久| 无码人妻久久一区二区三区蜜桃| 蜜桃麻豆www久久| 久久亚洲精品成人AV| 久久国产乱子精品免费女| 国产精品99久久免费观看| 99久久伊人精品综合观看| 国产亚洲色婷婷久久99精品91| 久久精品国产99国产精品澳门| 久久久久亚洲AV成人片| 久久综合九色综合97_久久久| 亚洲精品乱码久久久久久蜜桃 | 久久久久亚洲AV成人网人人软件 | 久久久久女人精品毛片| 久久精品成人免费网站| 国产精品久久久久久久久久影院| 欧美亚洲国产精品久久蜜芽| 91精品国产9l久久久久| 国产成人久久激情91| 免费观看久久精彩视频| 久久精品国产男包| 乱亲女H秽乱长久久久| 99精品久久精品| 国产精品99久久99久久久| 伊人色综合久久天天人守人婷 | 午夜精品久久久久9999高清| 国产精品伦理久久久久久| 日本久久久久久中文字幕| 国产午夜福利精品久久2021| 国产精品禁18久久久夂久| 99999久久久久久亚洲| 精品久久久久久久久免费影院| 国产精品成人无码久久久久久 | 色偷偷91久久综合噜噜噜噜| 青青青青久久精品国产h久久精品五福影院1421 | 狠狠精品干练久久久无码中文字幕| 国产精品热久久无码av|