在我们的代码中，我们使用RWCString而不是std:：string。其中一个函数是丢弃core，stacktrace指向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(+8fcab333c thr_panic(fcadc15c，73，3b088，fcab5788，ffbfb52f，a(+d8fcabbcec_ceil_prio_inherit(b8，fcaf53c4，32658，fcabbc60，fcaee2f4，fe092a00(+5cfcabddbc互斥锁内部(13359f8，0，1，0，0，ae(+17000584db0 __1cL_RWSTDMutexHaquire6M_v_(13359f8，1，fcaf3700，0，fe092a00，13b2ce0(+2000583e20 __1cL_RWSTDGuard2t5B6MrnL_RWTDMutex__v_(ffbfb8d0，13359f8，fe07d85b，ffbfb6d8，2，0(+20005846b8 __1cH__rwstdM__string_ref4CcnDstdLchar_traits4Cc__n0BJallocator4Cc___R__removeReference6M_l_(13359f8，0，2，0，0(+2800581a4c__1cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJallocator4Cc___I_unLink6M_v_(ffbfbaf0，ffbfb958，ffbfb 95b，243604，0，0(+5400580874 __1cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJ分配器4Cc___2T5B6M_v_(ffbfbaf0，ffbfb9c8，ffbfb 9f8，0，fcaf5424，ffbfe278(+c**0057a3b4 __1cJRWCString2T5B6M_v_(ffbfbaf0，0，fcaf3700，0，fe092a00，0(+c**0056dbfc __1cMConfirmKEligible6FnKFXOMessage__b_(ffbfe8f0，0，216b8c，8a5668，8a5668bc550(+1b400214da4 __1cPFXORTCConfirm_iOprocessMessage6MrknMFXOWLSModuleIFXOQdDD数据__h(99bc28，9cdee0，fd171bc8，4007482800(+24140020f63c __1cRPOA_FORTCConfirmGinvoke6MpnFCORBANServer请求__v_(99bc28，9cf3d8，8e4e50，fcfb7a40，7c770，0(+1bcfd124f2c __1cSObjectStateManager Ginvoke6MpnJTP内容__v_(8e56c8，ffbfebf8，8e2a08，8da8f8，800，8da8 f8(+60fd12c338 __1cNObjectManagerGinvoke6MpnFCORBANServer请求__v_(8bf288，9cf3d8，fd85d6cc，70726f63，80808080，1(+28fd867a4c__1cHPOAImplOProcessRequest6MpnRServerRequestImpl_rnJErrorInfo__v_(fd171a54、9cf3d8、ffbfee60、fd12c3f4、fd171a5、fd85f908(+270fd85c65c__1cRObjectAdapterImplbBProcessRequestServerRequest6MpnRServerRequestImpl_rnJErrorInfo__v_(8fe828，9cf3d8，ffbfee60，1，70，0(+b4fc61c95c __1cNTGIOPProtocolHRequest6MrnORequestMessage_rnHBinding_rnJErrorInfo__v_(8e9ea8，99a1a0，9d3508，ffbfee60，ffffffff 2c，0(+10fc62525c __1cNTGIOP协议创建消息6MpCLrirpcrlrnLGIOP消息HMsgType_irnJErrorInfo__v_(8e9ea8，ed5298，1，2，1，aa9958(+6c0fc61f218 __1cNTGIOPProtocolMTGIOPService6Mpvrirpcrl_v_(8e9ea8，8dbde4，ffbfef38，ffbfef3c，ffbfef34，fc61f124(+f4fcff0014 __1cRGIOP协议塔TGIOP服务6Fvrirpcrl_v_(8dbde4，ffbfef38，ffbfef3c，ffbfef34，fd0db020，fd0e7c38(+b00068caf8 CORBA_SVC(8dbde4，8dbde4，0，ed51d0，2e，0(+38fcc54d04_tmsvcdsp(0，628，0，62c，0(+1120fcc798c0 _tmrunserver(8d7a381400，fcd6e618，fb44be3c，8e2a08，8da8f8(+1598fcc537e4_tmstartserver(13，ffbff644，8a8a6c，1d3c，8d1238，1(+1b80020b228主(13，ffbff444，ffbff694，8a8000，fc9b6900，0(+b000146490 _启动(0,0,0,0,0,0(+108
很难回答到底是什么导致了这次崩溃，因为您没有发布一个完整的代码示例来重现这个问题。您必须使用内存探查器(例如-Valgrind(才能找到内存损坏或访问超出范围的地方。
如果非要我猜测(这就是任何人都可以用这个小代码做的(，那么我会说这是一个线程安全问题。看起来崩溃是因为分配器在尝试更新引用计数时无法获得互斥锁。我会寻找在不同线程中修改同一个字符串或分配其他字符串的地方。查看有关其线程安全策略的rw文档。