• <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>

            Dump調用堆棧的原理以及異常信息的反饋

            Dump 調用堆棧的原理以及異常信息的反饋

            動機:

            在游戲開發過程中,我們利用 QA 部門來做產品的質量保證,盡可能將絕大部分錯誤消化在內部,保證游戲的版本質量,但是 QA 部門畢竟有他的局限性,盡管經過嚴格的測試也很難保證將所有的問題一網打盡.

             

            通過在 Log 中轉儲的錯誤信息,我們可以進一步找出問題,但是 Log 文件產生在終端,我們拿到的也僅僅是公司內部測試部門產生的 Log 文件,顯然公司內部得到的信息是很有限的,如果能從玩家那里拿到異常信息,我們才能最快的去解決問題,盡可能在錯誤產生重大影響之前將其解決,所以我們有必要從被動的獲取異常信息,轉為主動去獲取.

             

            可行性 :

                   在錯誤發生時 Dump 調用堆棧,可以讓我們知道錯誤發生的位置,這比已往普通的 LOG 更加有效的多.我們可以將出錯的堆棧地址反饋回來.這一切在終端出現異常的時候自動進行. Windows 操作系統提供的 SEH 結構化異常機制可能讓我們在程序崩潰的瞬間處理這些事情.

             

            效率問題 :

                   SEH windows 的異常機制,除非在編譯時候特別指定不使用,否則總有默認的 SEH 處理機制, kernel32.dll 中有默認的 SEH 處理接口,當我們需要自己處理異常的時候,我們的處理點會掛接在異常處理鏈的最前端,這種鏈類似 Hook 的鏈.鏈的頭部放在 fs[0] 的位置.也就是說效率的問題是可以不必考慮,

             

             

            具體實現 :

                   通過閱讀反匯編代碼可以了解函數調用過程中堆棧的結構 :

                  

                   1 函數調用時 CALL 將下一行指令地址壓入堆棧

                   2 函數運行第一行會將 EBP 壓入堆棧

                   3 保存當前堆棧地址到 EBP (mov ebp,esp)

                  

                   再遇到 call 時從第一步執行,所以每次第二步壓入堆棧的都是上一層函數調用的 ESP 地址,而這個地址 +4 字節偏移則是當前調用函數返回后的下一條指令,也就是上一層函數的地址,所以我們只要知道當前函數的 EBP ( 也就是當前函數的棧頂 ) 就能夠遍歷得到所有調用堆棧層次.

                   dumpebp.jpg

            我們將windows SEH 結構化異常引入后,可以在異常發生的時候得到當前的EBP值,從而通過這個值得到整個調用堆棧的地址.

             

            在發布工程的時候,我們只需要生成map文件,就可以通過這個地址得到崩潰位置.使用HTTP GET 或POST方式可以將我們所需要的崩潰信息提交到我們指定的網站.這種方式只是通過URL參數來提交數據,只需要使用API InternetOpenUrl就可以很方便的將信息提交.此外如果不使用HTTP方式,我們也可以在這個時候創建新的socket 對指定的服務器進行連接來傳輸數據.

                
                static TCHAR hdrs[] 
            = _T("Content-Type: application/x-www-form-urlencoded"); 
                static 
            const TCHAR* accept= _T("Accept: */*"); 
                    static TCHAR action[]=_T("datecomit.aspx");//預提交的頁面
                    static TCHAR server[]=_T("192.168.9.119");//提交的server地址

                static TCHAR frmdata[
            1024={0}; 
                _tcscpy(frmdata,_T("message=this is a test message");  //提交數據, message為提交名字   
                
                
            // for clarity, error-checking has been removed 
                HINTERNET hSession 
            = InternetOpen("MyAgent"
                INTERNET_OPEN_TYPE_PRECONFIG, 
            NULLNULL0); 
                HINTERNET hConnect 
            = InternetConnect(hSession, server
                INTERNET_DEFAULT_HTTP_PORT, 
            NULLNULL, INTERNET_SERVICE_HTTP, 01); 
                HINTERNET hRequest 
            = HttpOpenRequest(hConnect, "POST", actionNULLNULL&accept, 01); 
                HttpSendRequest(hRequest, hdrs, strlen(hdrs), frmdata, strlen(frmdata)); 

             

            此后我們只需要定期觀察所提交的內容,便可以立即得知是否有異常出現.根據同一異常出現的幾率可以得知是否是致命的錯誤,是否需要緊急更新.

             


            posted on 2007-03-27 16:32 修一居士 閱讀(5304) 評論(7)  編輯 收藏 引用

            評論

            # re: Dump調用堆棧的原理以及異常信息的反饋 2007-03-28 15:47 Navi

            Windows 操作系統提供的 SHE 結構化異常機制可能讓我們在程序崩潰的瞬間處理這些事情

            SEH not SHE.  回復  更多評論   

            # re: Dump調用堆棧的原理以及異常信息的反饋 2007-03-29 13:31 南斗

            筆誤,已改  回復  更多評論   

            # re: Dump調用堆棧的原理以及異常信息的反饋 2007-05-11 22:02 nick

            坦白說, 通過這種方式獲取調用棧并不理想.
            首先是繁瑣.
            其次是有局限. 遇上 FPO 就不行了. 而現在的程序, 尤其是游戲程序, 哪個不是優化到極致.

            其實最好的辦法還是 minidump. 一個幾十K的 dump 文件就可以包含完整的調用棧了. 再大一點的文件就可以包含臨時變量、參數等的值了.
            可以看看 www.debuginfo.com 上面關于 minidump 的文章.

            我的 blog 上也有一個例子. 基本上是抄 debuginfo 的. 呵呵  回復  更多評論   

            # re: Dump調用堆棧的原理以及異常信息的反饋 2007-05-26 00:29 南斗

            獲取簡單的堆棧地址已經完全夠用了,用minidump弄那么大的dump文件我還要傳回服務器你不覺得很恐怖嗎,利用調用堆棧地址在map文件中就可以找到所有的問題了,我在我的項目中一直用這個方法 ;)  回復  更多評論   

            # re: Dump調用堆棧的原理以及異常信息的反饋 2008-03-20 11:01 Bright

            @nick
            不錯啊!終于找到能產生MiniDump文件的方法了,非常感謝!!  回復  更多評論   

            # re: Dump調用堆棧的原理以及異常信息的反饋 2008-07-29 16:07 ershu

            不是很好的方法。還有其他的方法,我們也使用過。都不是很好。信息不準確。

            minidump是我們試過最好的方法。微軟自己也用它。

            minidump壓縮一下以后才10幾k?上傳到你們的服務器就不行了?
            我們的服務器工作得很好。  回復  更多評論   

            # re: Dump調用堆棧的原理以及異常信息的反饋 2010-07-07 12:00 南斗

            @ershu
            呵呵 這要看你的具體應用了,我這里應用在游戲客戶端的崩潰記錄,同時在線的用戶數量可能有幾十萬,畢竟為了節約成本只會配置這樣一臺崩潰信息記錄服務器,所以上傳還是盡量越少越好。

            而實際上我們也不需要那么詳細的崩潰記錄信息,minidump大部分記錄了當前的進程、線程、以及內存狀況,實際上我們只需要簡單的堆棧信息就夠用了。

            對于信息記錄不準確的問題,我想這個一般都是因為當前指令指針錯誤,跳躍到了非法的地址,而無法通過ebp反推出堆棧信息,目前應該是無論何種方法都解決不了的。  回復  更多評論   

            導航

            <2008年7月>
            293012345
            6789101112
            13141516171819
            20212223242526
            272829303112
            3456789

            統計

            常用鏈接

            留言簿(3)

            隨筆檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            中文字幕人妻色偷偷久久| 亚洲AV无码久久| 久久久久国产成人精品亚洲午夜| 久久精品国产精品亚洲人人 | 人妻无码αv中文字幕久久琪琪布 人妻无码精品久久亚瑟影视 | 国产精品美女久久久久AV福利| 香蕉久久av一区二区三区| 久久99热只有频精品8| 久久妇女高潮几次MBA| 日韩十八禁一区二区久久| 久久综合综合久久97色| 久久99精品国产麻豆| 91精品国产色综久久| 亚洲国产精品久久久久久| 香蕉久久永久视频| 91精品国产91久久| 久久亚洲精品成人av无码网站| 亚洲色欲久久久综合网东京热| 日本道色综合久久影院| 亚洲AV日韩AV天堂久久| 久久亚洲2019中文字幕| 久久久久久久波多野结衣高潮| 国产精品久久久久影视不卡| 久久国产精品无码一区二区三区| 久久综合噜噜激激的五月天| 久久亚洲视频| 国产高潮国产高潮久久久91| 久久精品国产99久久无毒不卡| 色狠狠久久综合网| 久久久久亚洲Av无码专| 亚洲欧美一区二区三区久久| 久久毛片免费看一区二区三区| 久久精品www| 婷婷久久综合九色综合绿巨人| 久久99国产综合精品免费| 国产aⅴ激情无码久久| 囯产精品久久久久久久久蜜桃| 精品久久久久久无码不卡| 亚洲精品99久久久久中文字幕| 亚洲国产美女精品久久久久∴| 久久99热这里只有精品66|