Question

在我们的代码中，我们使用RWCString而不是std :: string。其中一个功能是删除核心，堆栈跟踪指向RWCString。该功能看起来像这样。

bool Eligible(const Message& message)
{
   Table* tmpTable = GetTableFromMessage<Table>(message, "TABLE"));  

    return  ( tmpTable != NULL && tmpTable->getNumRows() > 0 ) ?
              ( getString((*tmpTable)("xyz"))  == "xyz")                   :
              false;
}

((*tmpTable)("xyz")返回RWDBValue getString返回RWCString。不要在这里考虑内存泄漏。我们实际上是在智能指针中包装Table *。

堆栈跟踪如下。我无法弄清楚为什么RWCString正在转储核心。

fcac642c _lwp_kill (ffbfb530, fcaf7ba8, 3b15c, 0, fcaee2f4, fcaf83f4) + 8
 fcab333c thr_panic (fcadc15c, 73, 3b088, fcab5788, ffbfb52f, a) + d8
 fcabbcec _ceil_prio_inherit (b8, fcaf53c4, 32658, fcabbc60, fcaee2f4, fe092a00) + 5c
 fcabddbc mutex_lock_internal (13359f8, 0, 1, 0, 0, ae) + 170
 00584db0 __1cL_RWSTDMutexHacquire6M_v_ (13359f8, 1, fcaf3700, 0, fe092a00, 13b2ce0) + 20
 00583e20 __1cL_RWSTDGuard2t5B6MrnL_RWSTDMutex__v_ (ffbfb8d0, 13359f8, fe07d85b, ffbfb6d8, 2, 0) + 20
 005846b8 __1cH__rwstdM__string_ref4CcnDstdLchar_traits4Cc__n0BJallocator4Cc___R__removeReference6M_l_ (13359f8, 0, 2, 0, 0, 0) + 28
 00581a4c __1cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJallocator4Cc___I__unLink6M_v_ (ffbfbaf0, ffbfb958, ffbfb95b, 243604, 0, 0) + 54
 00580874 __1cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJallocator4Cc___2T5B6M_v_ (ffbfbaf0, ffbfb9c8, ffbfb9f8, 0, fcaf5424, ffbfe278) + c
 **0057a3b4 __1cJRWCString2T5B6M_v_ (ffbfbaf0, 0, fcaf3700, 0, fe092a00, 0) + c**
 0056dbfc __1cMConfirmKEligible6FrnKFXOMessage__b_ (ffbfe8f0, 0, 216b8c, 8a5668, 8a5668, 8bc550) + 1b4
 00214da4 __1cPFXORTCConfirm_iOprocessMessage6MrknMFXOWLSModuleIFXOQdDData__h_ (99bc28, 9cdee0, fd171bc8, 400, 748, 2800) + 2414
 0020f63c __1cRPOA_FXORTCConfirmGinvoke6MpnFCORBANServerRequest__v_ (99bc28, 9cf3d8, 8e4e50, fcfb7a40, 7c770, 0) + 1bc
 fd124f2c __1cSObjectStateManagerGinvoke6MpnJTPContext__v_ (8e56c8, ffbfebf8, 8e2a08, 8da8f8, 800, 8da8f8) + 60
 fd12c338 __1cNObjectManagerGinvoke6MpnFCORBANServerRequest__v_ (8bf288, 9cf3d8, fd85d6cc, 70726f63, 80808080, 1) + 28
 fd867a4c __1cHPOAImplOProcessRequest6MpnRServerRequestImpl_rnJErrorInfo__v_ (fd171a54, 9cf3d8, ffbfee60, fd12c3f4, fd171a54, fd85f908) + 270
 fd85c65c __1cRObjectAdapterImplbBProcessRequestServerRequest6MpnRServerRequestImpl_rnJErrorInfo__v_ (8fe828, 9cf3d8, ffbfee60, 1, 70, 0) + b4
 fc61c95c __1cNTGIOPProtocolHRequest6MrnORequestMessage_rnHBinding_rnJErrorInfo__v_ (8e9ea8, 99a1a0, 9d3508, ffbfee60, ffffff2c, 0) + 10
 fc62525c __1cNTGIOPProtocolNCreateMessage6MpCLrirpcrlrnLGIOPMessageHMsgType_irnJErrorInfo__v_ (8e9ea8, ed5298, 1, 2, 1, aa9958) + 6c0
 fc61f218 __1cNTGIOPProtocolMTGIOPService6Mpvrirpcrl_v_ (8e9ea8, 8dbde4, ffbfef38, ffbfef3c, ffbfef34, fc61f124) + f4
 fcff0014 __1cRGIOPProtocolTowerMTGIOPService6Fpvrirpcrl_v_ (8dbde4, ffbfef38, ffbfef3c, ffbfef34, fd0db020, fd0e7c38) + b0
 0068caf8 CORBA_SVC (8dbde4, 8dbde4, 0, ed51d0, 2e, 0) + 38
 fcc54d04 _tmsvcdsp (0, 628, 0, 0, 62c, 0) + 1120
 fcc798c0 _tmrunserver (8d7a38, 1400, fcd6e618, fb44be3c, 8e2a08, 8da8f8) + 1598
 fcc537e4 _tmstartserver (13, ffbff644, 8a8a6c, 1d3c, 8d1238, 1) + 1b8
 0020b228 main     (13, ffbff644, ffbff694, 8a8000, fc9b6900, 0) + b0
 00146490 _start   (0, 0, 0, 0, 0, 0) + 108

Answer 1

由于您没有发布重现问题的完整代码示例，因此很难回答导致此崩溃的原因。您必须使用内存分析器（例如 - Valgrind）才能找到内存损坏或访问超出范围的位置。

Answer 2

如果我不得不猜测（并且所有人都可以使用这些小代码）那么我就说它是一个线程安全问题。看起来崩溃是因为分配器在尝试更新引用计数时无法获得互斥锁。我正在寻找在不同线程中修改相同字符串的地方，或者正在分配其他字符串。检查rw docs有关它的线程安全策略。

RWCString正在放弃核心

2 个答案: