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

            focus on linux, c/c++, lua

            memcpy這個不定時炸彈

            從上周開始,當大規模測試商城購買道具時,偶爾會出現客戶端收不到消息的情況。一開始懷疑是邏輯層出了問題,排查3天后,把問題定位在了底層的
            發送網絡消息這塊有問題。大家都知道分析網絡包是一件非常痛苦的事情,主要是費眼。
            我抓取了一下包,進行大致了分析:

            //
             發送方
            data=0 18 6 5E 0 FFFFFFD5 5B 2E 53 5D FFFFFFCA 52 12 FFFFFFB7 FFFFFF8E 7D 1D 40 FFFFFFBC 4E 6B 46 59 FFFFFFFA C FFFFFFDF FFFFFF92 37 FFFFFFE0 3F

            //
            接收方
            data=46 59 FFFFFFFA C FFFFFFDF FFFFFF92 37 FFFFFFE0 3F 5D FFFFFFCA 52 12 FFFFFFB7 FFFFFF8E 7D 1D 40 FFFFFFBC 4E 6B 46 59 FFFFFFFA C FFFFFFDF FFFFFF92 37 FFFFFFE0 3F

            data=C FFFFFFDF FFFFFF92 37 FFFFFFE0 3F C FFFFFFDF FFFFFF92 37 FFFFFFE0 3F C FFFFFFDF FFFFFF92 37 FFFFFFE0 3F C FFFFFFDF FFFFFF92 37 FFFFFFE0 3F C FFFFFFDF FFFFFF92 37 FFFFFFE0 3F
            發送方的數據和我程序解析后的數據是一致的,但是接收方的數據出錯了,經過多次的對比發現,發送方和接收方的數據有交集,而且有一定規律的偏移。
            最終的定論接收方在拆包和粘包時處理數據出錯了。
            其中有一段代碼如下:
            memcpy(m_pSrc, &m_pSrc[nLen], nOffset);

            引用上述的網絡包為用例如下:
            拷貝前的數據為:
            data=46 59 FFFFFFFA C FFFFFFDF FFFFFF92 37 FFFFFFE0 3F 5D FFFFFFCA 52 12 FFFFFFB7 FFFFFF8E 7D 1D 40 FFFFFFBC 4E 6B 46 59 FFFFFFFA C FFFFFFDF FFFFFF92 37 FFFFFFE0 3F
            m_pSrc定義為 char m_pSrc[1024*10];
            當nLen=6, nOffset=24,調用
            memcpy(m_pSrc, &m_pSrc[nLen], nOffset); 
            拷貝后的數據為:
            data=C FFFFFFDF FFFFFF92 37 FFFFFFE0 3F C FFFFFFDF FFFFFF92 37 FFFFFFE0 3F C FFFFFFDF FFFFFF92 37 FFFFFFE0 3F C FFFFFFDF FFFFFF92 37 FFFFFFE0 3F C FFFFFFDF FFFFFF92 37 FFFFFFE0 3F
            這里我均打印出了m_pSrc的前30個字節的數據。

            對,問題就是出在這里了,至于為什么,現在還沒有時間去仔細排查,據說是memcpy的一個使用陷阱,我換了一種方式移動數據后,貌似問題就解決了。
            等我確定原因后,把答案補充在這里,目前緊張測試中。
            眼睛盯著屏幕的0XABCDEF,都快花眼了,這真是一件苦逼的活。。。。 

            2012-09-11
            第一次更新:
            用memmove取代memcpy之后,問題得到了解決,但不符合常理,因為這里基本否定了地址重疊的情況,摸索中。。。

            第二次更新:
            左思右想,沒有想到結論的前提下,我照抄了memcpy函數,給他起了個別名
            void * my_memcpy (void *dest, const void *src, size_t len)
            {
            char *d = (char*)dest;
            const char *s = (const char*)src;
            while (len--)
            *d++ = *s++;
            return dest;
            }
            改成:my_memcpy(m_pSrc, &m_pSrc[nLen], nOffset);
            后,運行結果正常,我了個擦,到底發生了什么,難道系統函數不是這么寫的?
            付上版本號:
            Linux version 2.6.32-38-generic-pae (buildd@rothera) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #85-Ubuntu SMP Wed Jan 25 15:37:46 UTC 2012

            posted on 2012-09-10 16:31 zuhd 閱讀(3239) 評論(15)  編輯 收藏 引用 所屬分類: c/c++

            評論

            # re: memcpy這個不定時炸彈 2012-09-11 00:21 ilvu

            當memcpy有重疊時就要用memmove  回復  更多評論   

            # re: memcpy這個不定時炸彈[未登錄] 2012-09-11 09:04 korall

            應該是重疊引致的吧。
            復制時數據重疊本來就應該要注意。
            相對來說,memcpy 不考慮重疊的情況,復制效率好;memmove會考慮到源于目標的重疊,效率會低一點但是能正確工作。
            但支持重疊也有限,如果目標頭部和源尾部重疊,那么兩者都無能為力。
            其實這是程序員的事情  回復  更多評論   

            # re: memcpy這個不定時炸彈[未登錄] 2012-09-11 09:08 korall

            哦,倒是忘了,memmove 還有一種倒序拷貝,能支持目標頭部與源尾部重疊的情況。  回復  更多評論   

            # re: memcpy這個不定時炸彈 2012-09-11 09:14 注冊好麻煩

            既然是粘包,怎么會有重疊問題呢。難道一塊內存還有多種用途?
            這種情況一般都是在數據量大的時候,出現的小幾率事件造成的,應該檢查讀取邏輯  回復  更多評論   

            # re: memcpy這個不定時炸彈 2012-09-11 09:23 zuhd

            @注冊好麻煩
            也有拆包的情況
              回復  更多評論   

            # re: memcpy這個不定時炸彈 2012-09-14 15:51 hydra

            明顯的地址重疊問題,msdn上對memcpy的這種情景已經說的很清楚了:
            If the source and destination overlap, the behavior of memcpy is undefined. Use memmove to handle overlapping regions.  回復  更多評論   

            # re: memcpy這個不定時炸彈 2012-09-15 06:55 neutralevil

            關于memcpy的實現,還真就不是你抄出來的代碼那樣的,現代編譯器都支持所謂Intrinsics技術,像memcpy這樣的函數根本不會照源碼老老實實生成函數代碼和函數調用代碼,而是在調用處直接插入優化后的匯編代碼。要探究memcpy的真正行為,最好通過調試器查看匯編代碼。  回復  更多評論   

            # re: memcpy這個不定時炸彈[未登錄] 2014-09-23 08:24 FongLuo

            char m_pSrc[1024*10];
            當nLen=6, nOffset=24,調用
            memcpy(m_pSrc, &m_pSrc[nLen], nOffset);
            明顯重疊了:
            源范圍:&m_pSrc[6] <==> &m_pSrc[6+24]
            目的范圍:&m_pSrc[0] <==> &m_pSrc[24]   回復  更多評論   

            一本色道久久综合狠狠躁篇 | 青春久久| 伊人久久大香线蕉精品| 久久青青草原综合伊人| 国产精品久久久久无码av| 久久国产成人午夜AV影院| 久久国产影院| 亚洲乱亚洲乱淫久久| 性欧美大战久久久久久久久| 91麻豆精品国产91久久久久久| 久久91精品国产91| 亚洲精品国产第一综合99久久 | 久久99热国产这有精品| 久久夜色精品国产亚洲| 性高湖久久久久久久久| 日产精品久久久久久久性色| 色偷偷88欧美精品久久久| 久久无码中文字幕东京热| 久久婷婷五月综合国产尤物app| 久久久久九九精品影院| 日韩一区二区久久久久久| 色妞色综合久久夜夜| 欧美精品乱码99久久蜜桃| 久久久精品日本一区二区三区 | 久久精品国产久精国产一老狼| 观看 国产综合久久久久鬼色 欧美 亚洲 一区二区 | 久久久久高潮毛片免费全部播放 | 人人妻久久人人澡人人爽人人精品 | 99久久99久久精品国产片果冻| 久久精品国产只有精品66| 久久精品成人欧美大片| 91精品国产乱码久久久久久| 久久久久亚洲AV成人网| 青青草国产精品久久久久| 久久精品亚洲AV久久久无码| 久久久青草久久久青草| 粉嫩小泬无遮挡久久久久久| 日韩乱码人妻无码中文字幕久久| 国产精品岛国久久久久| 亚洲精品无码专区久久同性男| 香蕉久久夜色精品国产2020|