• <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這個(gè)不定時(shí)炸彈

            從上周開(kāi)始,當(dāng)大規(guī)模測(cè)試商城購(gòu)買(mǎi)道具時(shí),偶爾會(huì)出現(xiàn)客戶端收不到消息的情況。一開(kāi)始懷疑是邏輯層出了問(wèn)題,排查3天后,把問(wèn)題定位在了底層的
            發(fā)送網(wǎng)絡(luò)消息這塊有問(wèn)題。大家都知道分析網(wǎng)絡(luò)包是一件非常痛苦的事情,主要是費(fèi)眼。
            我抓取了一下包,進(jìn)行大致了分析:

            //
             發(fā)送方
            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
            發(fā)送方的數(shù)據(jù)和我程序解析后的數(shù)據(jù)是一致的,但是接收方的數(shù)據(jù)出錯(cuò)了,經(jīng)過(guò)多次的對(duì)比發(fā)現(xiàn),發(fā)送方和接收方的數(shù)據(jù)有交集,而且有一定規(guī)律的偏移。
            最終的定論接收方在拆包和粘包時(shí)處理數(shù)據(jù)出錯(cuò)了。
            其中有一段代碼如下:
            memcpy(m_pSrc, &m_pSrc[nLen], nOffset);

            引用上述的網(wǎng)絡(luò)包為用例如下:
            拷貝前的數(shù)據(jù)為:
            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];
            當(dāng)nLen=6, nOffset=24,調(diào)用
            memcpy(m_pSrc, &m_pSrc[nLen], nOffset); 
            拷貝后的數(shù)據(jù)為:
            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個(gè)字節(jié)的數(shù)據(jù)。

            對(duì),問(wèn)題就是出在這里了,至于為什么,現(xiàn)在還沒(méi)有時(shí)間去仔細(xì)排查,據(jù)說(shuō)是memcpy的一個(gè)使用陷阱,我換了一種方式移動(dòng)數(shù)據(jù)后,貌似問(wèn)題就解決了。
            等我確定原因后,把答案補(bǔ)充在這里,目前緊張測(cè)試中。
            眼睛盯著屏幕的0XABCDEF,都快花眼了,這真是一件苦逼的活。。。。 

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

            第二次更新:
            左思右想,沒(méi)有想到結(jié)論的前提下,我照抄了memcpy函數(shù),給他起了個(gè)別名
            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);
            后,運(yùn)行結(jié)果正常,我了個(gè)擦,到底發(fā)生了什么,難道系統(tǒng)函數(shù)不是這么寫(xiě)的?
            付上版本號(hào):
            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 閱讀(3262) 評(píng)論(15)  編輯 收藏 引用 所屬分類(lèi): c/c++

            評(píng)論

            # re: memcpy這個(gè)不定時(shí)炸彈 2012-09-11 00:21 ilvu

            當(dāng)memcpy有重疊時(shí)就要用memmove  回復(fù)  更多評(píng)論   

            # re: memcpy這個(gè)不定時(shí)炸彈[未登錄](méi) 2012-09-11 09:04 korall

            應(yīng)該是重疊引致的吧。
            復(fù)制時(shí)數(shù)據(jù)重疊本來(lái)就應(yīng)該要注意。
            相對(duì)來(lái)說(shuō),memcpy 不考慮重疊的情況,復(fù)制效率好;memmove會(huì)考慮到源于目標(biāo)的重疊,效率會(huì)低一點(diǎn)但是能正確工作。
            但支持重疊也有限,如果目標(biāo)頭部和源尾部重疊,那么兩者都無(wú)能為力。
            其實(shí)這是程序員的事情  回復(fù)  更多評(píng)論   

            # re: memcpy這個(gè)不定時(shí)炸彈[未登錄](méi) 2012-09-11 09:08 korall

            哦,倒是忘了,memmove 還有一種倒序拷貝,能支持目標(biāo)頭部與源尾部重疊的情況。  回復(fù)  更多評(píng)論   

            # re: memcpy這個(gè)不定時(shí)炸彈 2012-09-11 09:14 注冊(cè)好麻煩

            既然是粘包,怎么會(huì)有重疊問(wèn)題呢。難道一塊內(nèi)存還有多種用途?
            這種情況一般都是在數(shù)據(jù)量大的時(shí)候,出現(xiàn)的小幾率事件造成的,應(yīng)該檢查讀取邏輯  回復(fù)  更多評(píng)論   

            # re: memcpy這個(gè)不定時(shí)炸彈 2012-09-11 09:23 zuhd

            @注冊(cè)好麻煩
            也有拆包的情況
              回復(fù)  更多評(píng)論   

            # re: memcpy這個(gè)不定時(shí)炸彈 2012-09-14 15:51 hydra

            明顯的地址重疊問(wèn)題,msdn上對(duì)memcpy的這種情景已經(jīng)說(shuō)的很清楚了:
            If the source and destination overlap, the behavior of memcpy is undefined. Use memmove to handle overlapping regions.  回復(fù)  更多評(píng)論   

            # re: memcpy這個(gè)不定時(shí)炸彈 2012-09-15 06:55 neutralevil

            關(guān)于memcpy的實(shí)現(xiàn),還真就不是你抄出來(lái)的代碼那樣的,現(xiàn)代編譯器都支持所謂Intrinsics技術(shù),像memcpy這樣的函數(shù)根本不會(huì)照源碼老老實(shí)實(shí)生成函數(shù)代碼和函數(shù)調(diào)用代碼,而是在調(diào)用處直接插入優(yōu)化后的匯編代碼。要探究memcpy的真正行為,最好通過(guò)調(diào)試器查看匯編代碼。  回復(fù)  更多評(píng)論   

            # re: memcpy這個(gè)不定時(shí)炸彈[未登錄](méi) 2014-09-23 08:24 FongLuo

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

            国内精品久久久久久久97牛牛| 午夜精品久久影院蜜桃| 亚洲中文久久精品无码ww16| 色偷偷偷久久伊人大杳蕉| 好久久免费视频高清| 国产成人久久精品麻豆一区| 久久婷婷午色综合夜啪| 99精品国产在热久久| 性做久久久久久久久久久| 久久发布国产伦子伦精品| 久久亚洲国产成人精品无码区| 亚洲日本va中文字幕久久| 久久激情五月丁香伊人| 一本色综合网久久| 色播久久人人爽人人爽人人片aV| 国产精品无码久久久久久| 7777精品伊人久久久大香线蕉| …久久精品99久久香蕉国产| 大香伊人久久精品一区二区 | 亚洲va久久久噜噜噜久久| 国内精品久久久久影院网站| 久久午夜伦鲁片免费无码| 精品伊人久久久| 久久国产精品波多野结衣AV| 国产一级持黄大片99久久| 18岁日韩内射颜射午夜久久成人| 精品久久久久久久久久中文字幕| jizzjizz国产精品久久| 久久精品国产清自在天天线| 蜜桃麻豆www久久国产精品| 久久精品九九亚洲精品天堂| 99久久婷婷免费国产综合精品| 久久综合亚洲色HEZYO社区| 久久夜色精品国产亚洲av| 国产精品亚洲美女久久久| 久久久精品午夜免费不卡| 久久精品国产亚洲精品2020| 久久久久久亚洲精品成人| 久久久久无码精品国产| AAA级久久久精品无码片| 狠狠色丁香婷婷综合久久来|