RWCString is dropping core

In our code we use RWCString instead of std::string. One of the functions is dropping core and the stacktrace points to RWCString. The function looks like this.

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

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

((*tmpTable)("xyz") returns RWDBValue getString returns RWCString. Don't consider the memory leak here. We are actually wrapping the Table* in a smart pointer.

The stack trace is below. I am unable to figure out why RWCString is dumping core.

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_FXORTCConfirmGinvoke6MpnFCORB开发者_高级运维ANServerRequest__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

---

It is hard to answer what exactly is causing this crash since you didn't post a complete code example that reproduces the problem. You have to use a memory profiler (for example - Valgrind) in order to find the place where memory gets corrupted or access goes out of bounds.

---

If I had to guess (and that's all anyone can do with that little code) then I'd say that it's a thread safety issue. It looks like the crash happens because the allocator can't get the mutex lock when trying to update a reference count. I'd look for places where the same string was being modified in a different thread, or other strings were being allocated. Check the rw docs about it's thread safety policy.