дамп кода в строковом присваивании - PullRequest
Новая
       17

дамп кода в строковом присваивании

1 голос
/ 30 января 2012

Я получаю дамп ядра в следующей части кода: 

void Debug::writeToFile()
{
 _ptrMutex->getLock();
 write(_fd,_cacheStr.c_str(),_cacheStr.size());
 _cacheStr = ""; //flush the write string
 _ptrMutex->releaseLock();
}

И ядро ​​произошло один раз, а дамп стека выглядит следующим образом 

Thread 1 (Thread 8426):
#0  0x00a2a402 in __kernel_vsyscall ()
#1  0x0072bdf0 in raise () from /lib/libc.so.6
#2  0x0072d701 in abort () from /lib/libc.so.6
#3  0x0545651a in ?? () from /usr/lib/libstdc++.so.6
#4  0x05456552 in std::terminate() () from /usr/lib/libstdc++.so.6
#5  0x0545668a in __cxa_throw () from /usr/lib/libstdc++.so.6
#6  0x053ed1ef in std::__throw_length_error(char const*) () from /usr/lib/libstdc++.so.6
#7  0x0543211d in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) () from /usr/lib/libstdc++.so.6
#8  0x05433e28 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_mutate(unsigned int, unsigned int, unsigned int) () from /usr/lib/libstdc++.so.6
#9  0x05433fca in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace_safe(unsigned int, unsigned int, char const*, unsigned int) () from /usr/lib/libstdc++.so.6
#10 0x05434065 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::assign(char const*, unsigned int) () from /usr/lib/libstdc++.so.6
#11 0x0815e9a8 in Debug::writeToFile() ()
#12 0x08161866 in Debug::LOG_PRINT_ERROR(char*, ...) ()
#13 0x0812bcc6 in DimInternalMsgHandler::handlePeerStatusIndication(DimPeerStatusInd*) ()
#14 0x0812c52a in DimInternalMsgHandler::handleInternalMessage(unsigned char*, int) ()
#15 0x0812aa05 in DimDanIfController::handleInMessage(NwPacket&) ()

1 Ответ

1 голос
/ 30 января 2012

Сомневаюсь, что проблема в самом writeToFile().

Я вижу несколько возможностей:

  1. Первая возможность состоит в том, что _cacheStr поврежден, возможно, из-за ошибки памяти в другом месте.

  2. Вторая возможность заключается в том, что есть параллельная модификация _cacheStr другим потоком. Я вижу, что writeToFile() защищен мьютексом, но любое другое место, где можно изменить _cacheStr, должно сделать то же самое.

...