Push-вызов в очередь STL <std :: string> вызывает Segfault, когда строка считывается из сокета - PullRequest
1 голос
/ 24 октября 2009

Я использую очередь STL в качестве входной очереди, она содержит std :: strings, которые я назвал String, используя typedef. Я читаю входную строку из сокета - используя сокеты Беркли. Он считывается в массив буферов символов и затем используется для установки строки, которая передается в очередь. Это происходит только для входной очереди - выходная очередь, которая не получает свои строки из прочитанного сокета, работает нормально.

Вот соответствующий код:

// Read from this socket's descriptor and send the input
// to its associated player for queueing and parsing.
void Socket::Read() {
 char buf[READ_SIZE + 1];

 int n = 0;
 if ((n = read(descriptor, buf, READ_SIZE)) < 0) {
  try {
   handleSocketError(__FILE__, __LINE__);
  }
  catch (...) {
   throw ;
  }
 }
 else if(n > 0) {
  buf[n] = 0;
  stripNewline(buf);
  log->log("Input received in Socket::Read: %s.", buf);
  String in = buf;
  p->input(in);
 }
}

Функция stripNewline - это служебная функция для удаления новых строк с конца вход получен. Я добавил это, чтобы помочь в отладке, его не было, когда впервые появился segfault:

// A utility function to strip the newlines off the end of
// a string.
void Socket::stripNewline(char *buf) {
 for(int i = strlen(buf); i > 0 && (buf[i] == '\n' || buf[i] == '\r' || buf[i] == 0); i--) {
   buf[i] = 0;
 }
}

Это место, откуда вводится и подается в p-> input в виде строки. p-> input просто помещает строку ввода в очередь:

// Push the String in to the tail of the input queue.
void Player::input(String in) {
 log->log("Player is sending input: %s.", in.c_str());
 std::cout << in << std::endl;
 inQ.push(in);
}

Здесь определена очередь входа внутри класса проигрывателя вместе с очередью выхода, которая работает нормально:

std::queue<String> inQ;
std::queue<String> outQ;

String определяется просто как typedef из std :: string:

typedef std::string String;

РЕДАКТИРОВАТЬ : исправлена ​​обратная typedef, то, что я получаю, когда записываю ее из памяти, когда отвлекаюсь, в коде было правильно.

Вывод до ошибки сегментации и вывод catchsegv следующие:

Sat Oct 24 11:02:34 2009:: New connection, waking up.
Sat Oct 24 11:02:34 2009:: Connection attempt begun.  Connection in the read set.
Sat Oct 24 11:02:34 2009:: Player has received output: Welcome to Muddy Reality Alpha version!
.
Sat Oct 24 11:02:35 2009:: Input received in Socket::Read: test.
Sat Oct 24 11:02:35 2009:: Player is sending input: test.
test
Segmentation fault
*** Segmentation fault
Register dump:

 EAX: 0000000c   EBX: 00000080   ECX: 00000000   EDX: 0000000c
 ESI: bfdbf080   EDI: 080497e0   EBP: bfdbee38   ESP: bfdbee20

 EIP: 0805640f   EFLAGS: 00010282

 CS: 0073   DS: 007b   ES: 007b   FS: 0000   GS: 0033   SS: 007b

 Trap: 0000000e   Error: 00000004   OldMask: 00000000
 ESP/signal: bfdbee20   CR2: 00000024

 FPUCW: ffff037f   FPUSW: ffff0000   TAG: ffffffff
 IPOFF: 00000000   CSSEL: 0000   DATAOFF: 00000000   DATASEL: 0000

 ST(0) 0000 0000000000000000   ST(1) 0000 0000000000000000
 ST(2) 0000 0000000000000000   ST(3) 0000 0000000000000000
 ST(4) 0000 0000000000000000   ST(5) 0000 0000000000000000
 ST(6) 0000 0000000000000000   ST(7) 0000 0000000000000000

Backtrace:
/lib/libSegFault.so[0xb7f9e100]
??:0(??)[0xb7fa3400]
/usr/include/c++/4.3/bits/stl_queue.h:226(_ZNSt5queueISsSt5dequeISsSaISsEEE4pushERKSs)[0x805647a]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/player.cpp:73(_ZN6Player5inputESs)[0x805377c]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/socket.cpp:159(_ZN6Socket4ReadEv)[0x8050698]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/socket.cpp:413(_ZN12ServerSocket4ReadEv)[0x80507ad]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/socket.cpp:300(_ZN12ServerSocket4pollEv)[0x8050b44]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/main.cpp:34(main)[0x8049a72]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7d1b775]
/build/buildd/glibc-2.9/csu/../sysdeps/i386/elf/start.S:122(_start)[0x8049801]

Насколько я могу судить, String нормальна, поэтому я понятия не имею, что может привести к тому, что очередь задохнется. Я продолжу тыкать и смотреть, что я получу, но я был бы очень признателен за любую информацию, которую может предложить сообщество переполнения стека.

РЕДАКТИРОВАНО , чтобы добавить результаты продолжения тыка:

Я пробовал два других метода помещения buf в строку, которая идет на p-> input:

p->input(String(buf));

и

String in;
in.assign(buf);
p->input(in);

Оба имели одинаковый результат. Я попытался отправить буфер в стандартный вывод символ за символом, чтобы убедиться, что в него не проникли странные символы:

 printf("Printing buf to determine sanity: \n");
 for(int i = 0; buf[i] != 0; i++) {
  printf("%d: %c\n", i, buf[i]);
 }

Результат которого был:

Printing buf to determine sanity: 
0: T
1: e
2: s
3: t

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

Далее: первоначально сравнивали size_t (целочисленный тип без знака) для значений, меньших нуля. Изменено как на ssize_t (целочисленный тип со знаком), так и на простой тип int без изменений - все равно происходит сбой. Спасибо Крис, не ответ, но все же хороший улов!

Ответил : Я по глупости в своем гнезде программы забыл установить Player * p в классе Socket. P является обратной связью между сокетом и игроком, в котором он находится. Я предположил, что с p все в порядке, потому что мы делали это так глубоко в плеере, прежде чем рухнуть, и поэтому это должно было быть что-то со строкой или очередью. Дурак я. Спасибо Крис!

1 Ответ

4 голосов
/ 24 октября 2009

size_t - это тип без знака, n - это size_t, поэтому это сравнение никогда не будет верным.

if ((n = read(descriptor, buf, READ_SIZE)) < 0) {

Если read возвращает -1, то else if попытается манипулировать буфером как очень большим буфером:

else if(n > 0) {

Я не уверен, что проблемы, которые я выделил, вызывают проблему, но их стоит исправить.

Редактировать

Ладно, получается, что это не проблема, но с точки зрения аварии можно было предположить (и было!), Что указатель Player 1020 * был нулевым.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...