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

            玩心未泯

            卡爾斯希普拉斯

            C++博客 首頁(yè) 新隨筆 聯(lián)系 聚合 管理
              19 Posts :: 0 Stories :: 98 Comments :: 0 Trackbacks

            今天寫(xiě)程序的時(shí)候碰到一個(gè)問(wèn)題,調(diào)試的時(shí)候總是報(bào)錯(cuò)Heap corruption detected。一直沒(méi)碰到過(guò)這樣的問(wèn)題,所以實(shí)在不知道如何下手。后來(lái)偶然一次注釋掉一個(gè)釋放語(yǔ)句,就沒(méi)報(bào)錯(cuò)了Heap corruption detected了(但是報(bào)memory leak),才發(fā)現(xiàn)原來(lái)這個(gè)釋放有問(wèn)題。我的一個(gè)函數(shù)調(diào)用中,開(kāi)始的時(shí)候分配了一個(gè)char數(shù)組,結(jié)束的時(shí)候釋放這個(gè)數(shù)組空間,看起來(lái)完全是沒(méi)有問(wèn)題的,居然會(huì)引發(fā)Heap corruption detected。代碼大體如下:
             
            char* pCmd = new char[len+1];   // len has got value before
            memset( pCmd, 0, len+1);
            .........
            for(int i=0;i<len;i++) {
                  ........      //獲取一個(gè)str內(nèi)容形如:"1A", "0F"
                  sscanf(str, "%02X", &pCmd[i]);
            }
            .....
            delete [] pCmd;

            找到問(wèn)題的所在,再分析代碼才發(fā)現(xiàn)了這其中一個(gè)很隱蔽的問(wèn)題,就是那句sscanf,由于第二個(gè)參數(shù)用的是"%02X",那么對(duì)它而言,最后一個(gè)參數(shù)就是一個(gè)指向int類(lèi)型的指針了,而我給的實(shí)際是一個(gè)char的指針。
            如果上面的循環(huán)只進(jìn)行到i<len-2,或者pCmd的size擴(kuò)大到len+3,都可以避免heap corruption。
            后來(lái)我干脆用了一個(gè)零時(shí)的int型變量來(lái)完成這個(gè)工作。

            要分析這個(gè)問(wèn)題,太理論化的我將不上來(lái),應(yīng)該是sscanf調(diào)用的過(guò)程中,由于pCmd分配到的空間不足,因此引發(fā)了新的分配,pCmd不再是像聲明的那樣一個(gè)len+1大小的char數(shù)組,因此直接調(diào)用delete [] pCmd就會(huì)引發(fā)heap corruption了。到底咋回事,也許還要高人來(lái)講講。

            posted on 2007-04-10 17:39 SuperPlayeR 閱讀(13342) 評(píng)論(3)  編輯 收藏 引用 所屬分類(lèi): C/C++

            評(píng)論

            # re: 一個(gè)不小心引發(fā)的Heap corruption 2007-04-11 19:50 Paradoxiology
            從VS.Net之后,CRT帶的malloc都會(huì)在每次分配的內(nèi)存塊的前端和末尾增添一些額外的調(diào)試信息,每次free它們的時(shí)候都會(huì)檢測(cè)一下,如果改變了就說(shuō)明內(nèi)存溢出之類(lèi)的情況發(fā)生了。
            所以說(shuō)heap corruption的引發(fā)是因?yàn)槭褂胹scanf的時(shí)候覆蓋了調(diào)試信息,sscanf本身是不會(huì)分配內(nèi)存的。  回復(fù)  更多評(píng)論
              

            # re: 一個(gè)不小心引發(fā)的Heap corruption 2007-04-11 23:41 nick
            to Paradoxiology:
            不是從 vs.net 開(kāi)始的吧. 至少 vc6 就有了.  回復(fù)  更多評(píng)論
              

            # re: 一個(gè)不小心引發(fā)的Heap corruption 2011-07-18 16:05 啊啊
            應(yīng)該是VC6 就有了,這個(gè)應(yīng)該是一種基本的內(nèi)存檢測(cè)手段  回復(fù)  更多評(píng)論
              

            国产午夜精品久久久久免费视| 欧美亚洲另类久久综合婷婷| 亚洲国产精品无码久久| 精品久久久无码21p发布| 综合人妻久久一区二区精品| 亚洲精品乱码久久久久久蜜桃图片 | 三级片免费观看久久| 久久久国产99久久国产一| 日本五月天婷久久网站| 精品久久久久久| 99久久这里只精品国产免费| 亚洲午夜久久久久妓女影院| 亚洲国产精品久久久久网站 | 少妇久久久久久被弄到高潮| 综合人妻久久一区二区精品| 亚洲成人精品久久| 一本色综合网久久| 久久国产午夜精品一区二区三区| 亚洲精品成人网久久久久久| 久久不见久久见免费视频7| 久久亚洲中文字幕精品一区四| 人妻久久久一区二区三区| 国产精品青草久久久久福利99| 色综合久久无码中文字幕| 久久综合伊人77777| 99久久国产主播综合精品| 久久er99热精品一区二区| 亚洲午夜久久久| 欧美粉嫩小泬久久久久久久| 久久伊人精品青青草原高清| 久久婷婷五月综合97色 | 久久人人爽人人爽人人片AV不| 久久婷婷国产麻豆91天堂| 久久精品亚洲精品国产色婷| 午夜视频久久久久一区 | 久久精品亚洲日本波多野结衣 | 99久久99这里只有免费的精品| 久久精品一本到99热免费| 亚洲国产小视频精品久久久三级| 色天使久久综合网天天| 久久久精品久久久久久|