91精品久久久久久无码,伊人久久大香线蕉综合5g,yy6080久久

被delete難倒了

話說我有一個(gè)結(jié)構(gòu)體如下：

struct stReplayData

{

int nDelay; // 該數(shù)據(jù)在上一條消息之后的延遲，仿真（目前自定義1秒鐘）

char* pData; // 網(wǎng)絡(luò)數(shù)據(jù)包的內(nèi)容

int nLen; // 長度

stReplayData()

{

nDelay = 0;

nLen = 0;

pData = NULL;

}

stReplayData(int nLength)

{

nDelay = 0;

nLen = nLength;

pData = NULL;

if (nLen > 0)

{

pData = new char[nLen];

}

stReplayData(const stReplayData& src)

{

if (this == &src)

{

return;

}

*this = src;

}

stReplayData& operator = (const stReplayData& src)

{

if (this == &src)

{

return *this;

}

nDelay = src.nDelay;

if (pData != NULL)

{

delete[] pData;

pData = NULL;

}

nLen = src.nLen;

if (nLen > 0)

{

pData = new char[nLen];

memcpy(pData, src.pData, nLen);

}

return *this;

}

~stReplayData()

{

nDelay = 0;

nLen = 0;

if (pData != NULL)

{

delete[] pData;

pData = NULL;

}

};

我定義了一個(gè)vector<stReplayData*> m_vecReplay，然后new了一些stReplayData ，push_back這些指針進(jìn)去，最后程序釋放資源的時(shí)候，居然報(bào)調(diào)用釋放指針出錯(cuò)了，報(bào)的錯(cuò)就是平時(shí)見的很多的Heap上指針無效的錯(cuò)誤，基本上是說stReplayData的析構(gòu)函數(shù)有問題，我了個(gè)擦，我怎么沒看出哪里有問題呢？

=====================================更多的代碼如下===============================================
我封裝了一個(gè)dll作為一個(gè)公共模塊，自然數(shù)據(jù)都會(huì)在這個(gè)公共模塊中存儲(chǔ)，其中內(nèi)存數(shù)據(jù)的管理也會(huì)在這個(gè)dll中去做，也就是說，new和delete都會(huì)由這個(gè)dll自己去管理，
使用者只要去調(diào)接口，然后把需要存儲(chǔ)的數(shù)據(jù)地址傳給dll,讓dll自己去拷貝即可。模塊其實(shí)非常簡單：

class CReplayManager : public IReplayManager

{

typedef vector<stReplayData*> VECREPLAY;

public:

CReplayManager();

virtual ~CReplayManager();

virtual bool PushData(stReplayData* pData);

virtual stReplayData* PopData();

virtual stReplayData* GetTailData();

virtual void ClearData();

virtual void Release();

private:

VECREPLAY m_vecReplay;

};

這里還有個(gè)模版函數(shù)，讓主程序朝dll寫數(shù)據(jù)，

template<class M, class T>

void WriteReplay(M* m, const T& t)

{

CWrite cw;

cw.Write(t);

stReplayData* pReplay = new stReplayData(cw.GetLen());

if (pReplay != NULL)

{

pReplay->nLen = cw.GetLen();

memcpy(pReplay->pData, cw.GetData(), cw.GetLen());

m->PushData(pReplay);

}

另：在主程序里單獨(dú)的操作stReplayData是沒什么問題的，我也試驗(yàn)過。

=================================總結(jié)=================================
re: 被delete難倒了 2011-03-31 11:49 dizhu

問題就是SAFE_DELETE((*it)); 這個(gè)是在exe中new的，不能在dll中delete。

深入：
如果一個(gè)EXE調(diào)用一個(gè)DLL時(shí)，用new和delete分配和釋放內(nèi)存為什么應(yīng)該放在同一個(gè)背景下的原因。得出的結(jié)論是，如果EXE和DLL有一個(gè)不是用動(dòng)態(tài)鏈接CRT庫(C runtime library)的方式使用CRT的話（Multi-threaded Debug DLL (/MDd)），或者是EXE和DLL動(dòng)態(tài)鏈接的CRT庫的版本不同時(shí)，EXE和DLL將會(huì)各自擁有各自的堆空間，所以在DLL中new的東西務(wù)必在DLL中delete。

posted on 2011-03-30 17:29 zuhd 閱讀(2203) 評(píng)論(29) 編輯收藏引用所屬分類: c/c++

評(píng)論

# re: 被delete難倒了 2011-03-30 17:36 namelij

你去看看vector里面的對(duì)象是怎么釋放的，就明白了回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-30 17:46 dizhu

貼下完整的代碼回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-30 17:50 Kevin Lynx

@dizhu
問題確實(shí)可能出在其他地方。回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-30 17:55 千暮(zblc)

我按你說的做了一遍沒有報(bào)錯(cuò) - -bnr 你咋不把調(diào)用的代碼發(fā)下回復(fù) 更多評(píng)論

# re: 被delete難倒了[未登錄] 2011-03-30 20:58 vincent

應(yīng)該還是也指著啊回復(fù) 更多評(píng)論

# re: 被delete難倒了[未登錄] 2011-03-30 20:59 vincent

野指針…… 回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-31 00:50 Mensch88

1. 就這段代碼本身來說，有一個(gè)錯(cuò)誤：拷貝構(gòu)造函數(shù) stReplayData(const stReplayData& src) 里的指針pData沒有初始化！

2.stReplayData的析構(gòu)函數(shù)本身沒有問題。程序報(bào)錯(cuò)應(yīng)該是調(diào)用了兩次析構(gòu)函數(shù)造成的。
比如說，很有可能在使用時(shí)會(huì)犯這樣的錯(cuò)誤：
stReplayData data(otherdata);
vec.push_back(&data);
由于data本身會(huì)調(diào)用析構(gòu)函數(shù)delete pData，而delete vec里面的數(shù)據(jù)時(shí)也會(huì)調(diào)用data的析構(gòu)函數(shù)，于是掛了。

回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-31 01:13 Mensch88

不好意思，第二點(diǎn)我說得不大對(duì)，因?yàn)闃侵髟谖鰳?gòu)函數(shù)里判斷了 if (pData != NULL)，并且之后會(huì)把pData=NULL，所以調(diào)用兩次析構(gòu)在單線程環(huán)境里不會(huì)問題。當(dāng)然多線程環(huán)境下就另說了。

但我所陳述的問題依然是存在的，只是這不是因?yàn)閮纱挝鰳?gòu)造成，而是因?yàn)閐ata是棧上的數(shù)據(jù)，不允許delete，所以掛了。回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-31 09:14 zuhd

@Mensch88
1. 就這段代碼本身來說，有一個(gè)錯(cuò)誤：拷貝構(gòu)造函數(shù) stReplayData(const stReplayData& src) 里的指針pData沒有初始化！

拷貝構(gòu)造函數(shù)是調(diào)用operator =來著回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-31 09:36 dizhu

@Mensch88
vector里面保存的是指針，不會(huì)調(diào)用delete 的，不會(huì)存在你說的兩次析構(gòu)函數(shù)調(diào)用回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-31 09:39 dizhu

@dizhu
如果樓主
stReplayData data(otherdata);
vec.push_back(&data);
然后還去delete vec里面的數(shù)據(jù)，那就是樓主代碼寫的有問題，所以說還是貼下完整的代碼，才能知道問題。但就這個(gè)stReplayData，還真看不出為什么會(huì)掛回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-31 10:13 zuhd

我更新了帖子貼了更多的代碼想嘗試的朋友可以自己簡單修改下即可回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-31 11:13 zuhd

問題我找到了，是我以前遇到的老問題
virtual bool PushData(stReplayData* pData);
這個(gè)接口設(shè)計(jì)有問題，dll的接口應(yīng)該用標(biāo)準(zhǔn)的c++類型，我只知道其然，不知道所以然，了解詳情的說下回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-31 11:17 dizhu

@zuhd
重點(diǎn)把delete stReplayData 的代碼和 CReplayManager 貼出來看下回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-31 11:22 zuhd

@dizhu
看了頭文件基本就能猜到代碼了吧中規(guī)中矩的容器操作代碼而已

另：我在gcc中的頭文件大量的使用了自定義的類，貌似沒發(fā)現(xiàn)過什么問題，怎么用vc上來就碰到這個(gè)，是巧合還是必然？腫么辦？有沒有，有沒有？回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-31 11:24 dizhu

@zuhd
我比較關(guān)心CReplayManager 的Release 以及 ClearData 的實(shí)現(xiàn)。是不是在這里面delete stReplayData 了？？回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-31 11:41 zuhd

void CReplayManager::ClearData()
{
VECREPLAY::iterator it = m_vecReplay.begin();
for (; it != m_vecReplay.end(); it++)
{
SAFE_DELETE((*it));
}
m_vecReplay.clear();
} 回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-31 11:49 dizhu

@zuhd
void CReplayManager::ClearData()
{
VECREPLAY::iterator it = m_vecReplay.begin();
for (; it != m_vecReplay.end(); it++)
{
SAFE_DELETE((*it));
}
m_vecReplay.clear();
}
問題就是SAFE_DELETE((*it)); 這個(gè)是在exe中new的，不能在dll中delete。
原因：http://blog.csdn.net/blz_wowar/archive/2008/03/13/2176536.aspx 回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-31 11:56 zuhd

@dizhu
在exe中new，不能在dll中delete的？
exe和dll用的是同一個(gè)堆棧空間的，回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-31 17:48 Mensch88

zuhd@zuhd
--拷貝構(gòu)造函數(shù)是調(diào)用operator =來著

拷貝構(gòu)造函數(shù)是調(diào)用了operator=，但是operator=里面會(huì)判斷pData是否為NULL：
if (pData != NULL)
{
delete[] pData;
pData = NULL;
}
必須注意的是，這時(shí)pData還沒有被初始化。這樣就會(huì)執(zhí)行 delete[] pData;
從而出錯(cuò)。回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-31 17:55 Mensch88

@dizhu
--然后還去delete vec里面的數(shù)據(jù)，那就是樓主代碼寫的有問題，所以說還是貼下完整的代碼，才能知道問題。但就這個(gè)stReplayData，還真看不出為什么會(huì)掛

因?yàn)闃侵髡f了vec里面是一些new出來的指針，而之后程序釋放資源時(shí)報(bào)錯(cuò)，于是我估計(jì)樓主所說的程序釋放資源就是指將vec里面的指針delete。
樓主后來的代碼也證實(shí)了我的猜測(cè)。

回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-31 18:31 Mensch88

樓主的問題算是CRT的bug么？
Linux下測(cè)試，無論是靜態(tài)還是動(dòng)態(tài)鏈接都沒發(fā)現(xiàn)這種問題。回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-03-31 23:54 flyinghearts

建議還是用 vector<char> 或 string 代替 char*

stReplayData 設(shè)計(jì)得有點(diǎn)問題，
一般都是在拷貝構(gòu)造函數(shù)中進(jìn)行分配新內(nèi)存處理，然后在賦值函數(shù)中調(diào)用拷貝構(gòu)造函數(shù)，構(gòu)造一個(gè)臨時(shí)類對(duì)像，與原類對(duì)象進(jìn)行交換。

你的實(shí)現(xiàn)剛好相反，拷貝構(gòu)造函數(shù)調(diào)用賦值函數(shù)，但賦值函數(shù)中用到的 nlen 和 pdata兩個(gè)值都未初始化，UB行為。

實(shí)際上，這兩個(gè)判斷都是可以去掉的，new char[0] 是有意義的，沒必要對(duì) nlen進(jìn)行判斷
delete[] p 當(dāng)p是空指針時(shí)，沒有任何效果，因此沒必要對(duì)pdata進(jìn)行判斷

拷貝構(gòu)造函數(shù)中對(duì)指針的判斷也是多余的。
另外，要先分配新內(nèi)存，再釋放舊內(nèi)存，保證異常安全。

回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-04-01 09:44 zuhd

@flyinghearts
那個(gè)拷貝構(gòu)造函數(shù)確實(shí)有點(diǎn)問題，以前拷貝構(gòu)造函數(shù)調(diào)用=寫順手了，沒發(fā)現(xiàn)有內(nèi)存操作的這么寫有這個(gè)陷阱，改了一下：
stReplayData(const stReplayData& src)
{
if (this == &src)
{
return;
}
nDelay = src.nDelay;
nLen = src.nLen;
pData = new char[nLen];
if (pData != NULL)
{
memcpy(pData, src.pData, nLen);
}
}

stReplayData& operator = (const stReplayData& src)
{
if (this == &src)
{
return *this;
}
nDelay = src.nDelay;
nLen = src.nLen;
if (pData != NULL)
{
delete[] pData;
pData = NULL;
}
pData = new char[nLen];
if (pData != NULL)
{
memcpy(pData, src.pData, nLen);
}
return *this;
}

至于你說的：
另外，要先分配新內(nèi)存，再釋放舊內(nèi)存，保證異常安全。
好像我一直都是先delete 再new ，可能一直懶得用個(gè)臨時(shí)的指針來保存pData吧，不過你這么說的道理是？？回復(fù) 更多評(píng)論

# re: 被delete難倒了[未登錄] 2011-04-01 11:32 hdqqq

如果樓主使用 /mt 編譯，dll啟動(dòng)時(shí)使用自己的堆，在主程序中new 出來的對(duì)象，再通過指針傳給dll，然后在dll中釋放，會(huì)產(chǎn)生錯(cuò)誤，主程序和dll使用不同的堆。回復(fù) 更多評(píng)論

# re: 被delete難倒了[未登錄] 2011-04-01 14:39 楊粼波

把struct改為class，然后把數(shù)據(jù)private，測(cè)試一次看看。排除客戶代碼應(yīng)用上的錯(cuò)誤。

當(dāng)然了，也有可能在調(diào)用的時(shí)候，被其他地方的錯(cuò)誤牽連導(dǎo)致這個(gè)struct的數(shù)據(jù)被損壞。

如果牽扯到DLL的話，那有可能是exe和dll兩者之間的版本不一致所導(dǎo)致，DLL的導(dǎo)出地址是用的一個(gè)，卻不想exe用了另外一個(gè)，所以發(fā)生錯(cuò)誤，這是有可能發(fā)生的。用VS的編譯器，特別是2003，你需要依照以下步驟重編譯：清理全部(包括dll和exe)->重編。回復(fù) 更多評(píng)論

# re: 被delete難倒了[未登錄] 2011-04-01 15:40 楊粼波

http://blog.csdn.net/ssli/archive/2009/06/16/4272484.aspx 回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-04-01 23:30 flyinghearts

class stReplayData
{
  int nDelay;     // 該數(shù)據(jù)在上一條消息之后的延遲，仿真（目前自定義1秒鐘）
  size_t nLen;  // 長度
  char* pData;    // 網(wǎng)絡(luò)數(shù)據(jù)包的內(nèi)容

public:
  stReplayData(size_t nLength = 0): nDelay(0),
      nLen(nLength), pData(new char[nLength]()) {}

  ~stReplayData() { delete[] pData; }

  stReplayData(const stReplayData& src):  nDelay(src.nDelay),
      nLen(src.nLen), pData(new char[src.nLen])
  {
    memcpy(pData, src.pData, nLen);
  }

  stReplayData& operator=(stReplayData tmp) //構(gòu)建一個(gè)臨時(shí)對(duì)像
  {
    nDelay = tmp.nDelay;
    nLen = tmp.nLen;
    std::swap(pData, tmp.pData);
    return *this;
  }
};

可參考以前寫的這篇文章：

http://blog.csdn.net/flyinghearts/archive/2010/06/16/5673089.aspx

回復(fù) 更多評(píng)論

# re: 被delete難倒了 2011-04-02 11:42 tingya

涉及到跨模塊內(nèi)存使用的問題，應(yīng)該遵守誰使用，誰釋放回復(fù) 更多評(píng)論

刷新評(píng)論列表

只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
【推薦】100%開源！大型工業(yè)跨平臺(tái)軟件C++源碼提供，建模，組態(tài)！

相關(guān)文章: 不錯(cuò) 記一個(gè)小bug 1長度數(shù)組使用備忘證明題： x & 3 == x % 4 成為符合ANSI和Unicode的應(yīng)用程序 memcpy這個(gè)不定時(shí)炸彈被delete難倒了 C++的函數(shù)返回引用 union 晦澀的代碼

網(wǎng)站導(dǎo)航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

focus on linux, c/c++, lua

導(dǎo)航

統(tǒng)計(jì)

常用鏈接

留言簿(4)

隨筆分類

隨筆檔案

搜索

最新評(píng)論

閱讀排行榜

評(píng)論排行榜

被delete難倒了

評(píng)論

# re: 被delete難倒了 2011-03-30 17:36 namelij

# re: 被delete難倒了 2011-03-30 17:46 dizhu

# re: 被delete難倒了 2011-03-30 17:50 Kevin Lynx

# re: 被delete難倒了 2011-03-30 17:55 千暮(zblc)

# re: 被delete難倒了[未登錄] 2011-03-30 20:58 vincent

# re: 被delete難倒了[未登錄] 2011-03-30 20:59 vincent

# re: 被delete難倒了 2011-03-31 00:50 Mensch88

# re: 被delete難倒了 2011-03-31 01:13 Mensch88

# re: 被delete難倒了 2011-03-31 09:14 zuhd

# re: 被delete難倒了 2011-03-31 09:36 dizhu

# re: 被delete難倒了 2011-03-31 09:39 dizhu

# re: 被delete難倒了 2011-03-31 10:13 zuhd

# re: 被delete難倒了 2011-03-31 11:13 zuhd

# re: 被delete難倒了 2011-03-31 11:17 dizhu

# re: 被delete難倒了 2011-03-31 11:22 zuhd

# re: 被delete難倒了 2011-03-31 11:24 dizhu

# re: 被delete難倒了 2011-03-31 11:41 zuhd

# re: 被delete難倒了 2011-03-31 11:49 dizhu

# re: 被delete難倒了 2011-03-31 11:56 zuhd

# re: 被delete難倒了 2011-03-31 17:48 Mensch88

# re: 被delete難倒了 2011-03-31 17:55 Mensch88

# re: 被delete難倒了 2011-03-31 18:31 Mensch88

# re: 被delete難倒了 2011-03-31 23:54 flyinghearts

# re: 被delete難倒了 2011-04-01 09:44 zuhd

# re: 被delete難倒了[未登錄] 2011-04-01 11:32 hdqqq

# re: 被delete難倒了[未登錄] 2011-04-01 14:39 楊粼波

# re: 被delete難倒了[未登錄] 2011-04-01 15:40 楊粼波

# re: 被delete難倒了 2011-04-01 23:30 flyinghearts

# re: 被delete難倒了 2011-04-02 11:42 tingya