由於Linux C++中的SIGABRT導致的崩潰PowerPC

我的程序在字符串賦值中崩潰。我不能忽視它的確切原因。多個線程執行相同的代碼。由於Linux C++中的SIGABRT導致的崩潰PowerPC

這是我的代碼。

char* cTemp = new char[5]; 
    memset(cTemp,'\0', 5); 
    snprintf(cTemp , 5 , "%04x" , iParameter); 
    string sVar1 = cTemp; 
    delete[] cTemp; 
    if(sVar1 == "0") 
    sVar1 = "0000"; 
    pSharedLib->setVar1(sVar1);

所設定的功能（在共享庫）

bool A::setVar1(CString& temp) 
    { 
    m_sVar1= temp; 
    return true; 
    }

碰撞BT示出了誤差作爲

#0 0x48194444 in raise() from /lib/libc.so.6 
#0 0x48194444 in raise() from /lib/libc.so.6 
No symbol table info available. 
#1 0x48199694 in abort() from /lib/libc.so.6 
No symbol table info available. 
#2 0x481d4ecc in ??() from /lib/libc.so.6 
No symbol table info available. 
#3 0x481e14d4 in ??() from /lib/libc.so.6 
No symbol table info available. 
#4 0x481e32b0 in free() from /lib/libc.so.6 
No symbol table info available. 
#5 0x480df8b8 in operator delete(void*)() from /usr/lib/libstdc++.so.6 
No symbol table info available. 
#6 0x480b136c in std::string::_Rep::_M_destroy(std::allocator<char> const&) 
() from /usr/lib/libstdc++.so.6 
No symbol table info available. 
#7 0x480b35f4 in std::string::assign(std::string const&)() 
from /usr/lib/libstdc++.so.6 
No symbol table info available.

來源

2011-04-18 Prashanth

'string'和'CString'似乎是不同的類型。 – Erik 2011-04-18 11:13:03

多數民衆贊成在一個錯別字對不起....都是字符串..我已經淡化了一些函數/ typedefs，使其更簡單！ – Prashanth 2011-04-18 11:20:23

我看不出有任何的同步對象保護組m_sVar1的。您提到setVar1可以同時從多個線程中調用，STL的線程保證並不保證該分配對於多線程是安全的。

來源

2011-04-18 11:24:05

雅，這可能是問題一起通過裁判，我現在正在做的!!!但我想知道這是否會導致SIGABRT？ – Prashanth 2011-04-18 11:29:10

當然。字符串:: assign在邏輯上是「刪除字符串;字符串= arg;」。如果兩個線程試圖刪除同一塊內存（並注意到你在free（）中崩潰），那麼你可能會損壞這個堆。在這種情況下，它看起來像堆檢測到錯誤，並調用abort（），然後引發SIGABRT。 – 2011-04-18 11:48:21

感謝信息人！這確實有很大的幫助！ – Prashanth 2011-04-18 11:53:02

我懷疑的關鍵，這個問題是

多個線程執行相同的代碼。

如果有一個字符串m_sVar1，和多個線程同時被分配給它，那麼機會是相當不錯的一個競爭條件會導致腐敗。您需要通過關鍵部分妥善保護該變量。

來源

2011-04-18 11:27:51

謝謝，我想這可能是問題所在。讓我試着通過互斥或信號量來保護它，從而再次重現問題！ – Prashanth 2011-04-18 11:35:06

由於Linux C++中的SIGABRT導致的崩潰PowerPC

回答

相關問題