std::map<const char*, GhMemoryRecord*>::iterator funcIter = g_oMemoryRecordFunctionMap.find(pFuncKey);
開始一段時間還好，過了一段時間就崩潰了。
不會是執行緒問題，訪問之前加了執行緒鎖。
uj5u.com熱心網友回復：
存個string唄，別用char *。uj5u.com熱心網友回復：
用了，照樣嗝屁……
uj5u.com熱心網友回復：
是在find內部崩潰的嘛，如果改成string又加上鎖了還有問題。那是不是用于查找的key值有問題呢。看不到原始碼都不好說什么情況的。uj5u.com熱心網友回復：
大概率是其他地方的記憶體操作影響了map的存盤結構uj5u.com熱心網友回復：
可以肯定不是：
１、有鎖。釋放時肯定不影響。
２、都是新建的。
uj5u.com熱心網友回復：
柳大都搞不定的一定是神問題。不浪費時間想了。就搬板凳看吧。uj5u.com熱心網友回復：
不敢。
懷疑還是執行緒問題。改進辦法是，將操作加入執行緒佇列；由執行緒執行相應操作。
uj5u.com熱心網友回復：
key是字串，函式名、10數字、16數字。
uj5u.com熱心網友回復：
現在的解決思路有：1、不使用map，自己進行搜索處理。
2、使用執行緒，將作業先加入執行緒中，由專用執行緒進行處理。
uj5u.com熱心網友回復：
最好是能將能重現問題的代碼段都貼出來。這樣只有一條陳述句是很難定位問題的。uj5u.com熱心網友回復：
就往map中放東西，哪里有什么高科技。代碼很簡單：int gh_memory_record_increase(const void* pAddr, const int nSize,
const char* pFile, const char* pFunction, const int nLine)
{
#if MEMORY_TRACE_FLAG
if (pAddr == NULL)
{
//GH_LOG_INFO("addr=NULL, postion=%s-%s(%d)", pFile, pFunction, nLine);
return -1;
}
pthread_mutex_lock(g_pMemoryMutex);
//if (strstr(pFunction, "gh_mysql_query_camera_function")) GH_LOG_INFO("size=%d, postion=%s-%s(%d)", nSize, pFile, pFunction, nLine);
if (g_lStartTime == 0)
{
g_lStartTime = TIMESTAMP();
}
char* pAddrKey = gh_memory_addr_to_key(pAddr);
GhMemoryRecord* pAddrRecord = (GhMemoryRecord*)malloc(sizeof(GhMemoryRecord));
memset(pAddrRecord, 0, sizeof(GhMemoryRecord));
pAddrRecord->addr = (void*)pAddr;
pAddrRecord->time = TIMESTAMP();
pAddrRecord->size_total = nSize;
pAddrRecord->size_list[0] = nSize;
pAddrRecord->size_count = 1;
sprintf(pAddrRecord->file, "%s", pFile);
sprintf(pAddrRecord->function, "%s", pFunction);
pAddrRecord->line = nLine;
g_oMemoryRecordAddressMap[pAddrKey] = pAddrRecord;
//GH_LOG_INFO("addr=%s, size=%d, postion=%s-%s(%d)", pKey, nSize, pFile, pFunction, nLine);
#if MEMORY_TRACE_FUNCTION_MAP
char* pFuncKey = gh_memory_ffl_to_key(pFile, pFunction, nLine);
//第二次死在這里，為什么？
GH_LOG_HERE();
std::map<char*, GhMemoryRecord*, cmp_str>::iterator funcIter = g_oMemoryRecordFunctionMap.find(pFuncKey);
GH_LOG_HERE();
if (funcIter == g_oMemoryRecordFunctionMap.end())
{
GhMemoryRecord* pFuncRecord = (GhMemoryRecord*)malloc(sizeof(GhMemoryRecord));
memcpy(pFuncRecord, pAddrRecord, sizeof(GhMemoryRecord));
g_oMemoryRecordFunctionMap[pFuncKey] = pFuncRecord;
}
else
{
GhMemoryRecord* pFuncRecord = funcIter->second;
if (pFuncRecord == NULL)
{
GH_LOG_HERE();
}
pFuncRecord->size_total += nSize;
pFuncRecord->size_list[pFuncRecord->size_count] = nSize;
pFuncRecord->size_count ++;
free(pFuncKey);
}
#endif
pthread_mutex_unlock(g_pMemoryMutex);
#endif
return 0;
}
uj5u.com熱心網友回復：
崩潰的時候在彈出的對話框按相應按鈕進入除錯，按Alt+7鍵查看Call Stack即“呼叫堆疊”里面從上到下列出的對應從里層到外層的函式呼叫歷史。雙擊某一行可將游標定位到此次呼叫的源代碼或匯編指令處，看不懂時雙擊下一行，直到能看懂為止。uj5u.com熱心網友回復：
不是WINDOWS，是LINUX
uj5u.com熱心網友回復：
行程意外退出會在當前目錄下產生‘core’檔案或形如‘core.數字’的檔案比如‘core.1234’
使用命令
gdb 運行程式名 core或core.數字
進入gdb然后使用bt命令
可以查看行程意外退出前函式呼叫的堆疊，內容為從上到下列出對應從里層到外層的函式呼叫歷史。
如果行程意外退出不產生core檔案，參考“ulimit -c core檔案最大塊大小”命令
uj5u.com熱心網友回復：
看到了也解決不了。關鍵在于，吾這樣寫，哪里導致其崩潰？用法上哪里不對？
uj5u.com熱心網友回復：
執行緒沒有加鎖吧？uj5u.com熱心網友回復：
當然有加鎖
uj5u.com熱心網友回復：
沒看到有問題的代碼,就重新編譯, 有時候是編譯器的問題uj5u.com熱心網友回復：
哈哈，即使沒有問題，吾代碼一天也會編譯十次。
其實這個問題吾目前可以肯定就是執行緒問題。為什么是執行緒問題？應該是呼叫函式的執行緒，有一些特殊屬性。
uj5u.com熱心網友回復：
樓主這個問題解決沒，我現在遇到了同樣的問題，而且是單執行緒里面，map::find 程式就崩潰了，linux環境uj5u.com熱心網友回復：
沒有解決。后來使用執行緒將就
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/69225.html
標籤：C++ 語言
下一篇：員工獎金加提成