RWCString сбрасывает ядро

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") возвращается RWDBValuegetString возвращается RWCString, Не учитывайте утечку памяти здесь. Мы на самом деле обертываем таблицу * в умный указатель.

Трассировка стека находится ниже. Я не могу понять, почему 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) +
 **0057a3b4 __1cJRWCString2T5B6M_v_ (ffbfbaf0, 0, fcaf3700, 0, fe092a00, 0) + c**
 0056dbfc __1cMConfirmKElitable6FrnKFXOMessage__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 основной (13, ffbff644, ffbff694, 8a8000, fc9b6900, 0) + b0
 00146490 _start   (0, 0, 0, 0, 0, 0) + 108

Answer 1

Трудно ответить, что именно является причиной этого сбоя, поскольку вы не опубликовали полный пример кода, который воспроизводит проблему. Вы должны использовать профилировщик памяти (например, Valgrind), чтобы найти место, где память повреждена или доступ выходит за пределы.

Answer 2

Если бы мне пришлось угадывать (и это все, что можно сделать с этим небольшим кодом), я бы сказал, что это проблема безопасности потоков. Похоже, что происходит сбой, потому что распределитель не может получить блокировку мьютекса при попытке обновить счетчик ссылок. Я бы искал места, где одна и та же строка изменялась в другом потоке или были выделены другие строки. Посмотрите в документации по безопасности потоков.