Программа C ++ всегда падает при выполнении присваивания std :: string - PullRequest
11 голосов
/ 21 февраля 2010

Я пытался отладить сбой в моем приложении, которое вылетает (т.е. * Обнаружен glibc * free (): неверный указатель: 0x000000000070f0c0 ***), в то время как я пытаюсь сделать простое присвоение строке. Обратите внимание, что я компилирую в системе Linux с gcc 4.2.4 с уровнем оптимизации, установленным в -O2. При -O0 приложение больше не падает.

* 1005 Е.Г. *

std::string abc;

abc = "testString";

но если я изменил код следующим образом, он больше не падает

std::string abc("testString");

Итак, я снова почесал голову! Но интересная закономерность состояла в том, что сбой переместился позже в приложении, СНОВА в другой строке. Мне показалось странным, что приложение постоянно зависало при назначении строки. Типичная обратная трассировка сбоя будет выглядеть следующим образом:

#0  0x00007f2c2663bfb5 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007f2c2663bfb5 in raise () from /lib64/libc.so.6
#1  0x00007f2c2663dbc3 in abort () from /lib64/libc.so.6
#2  0x00000000004d8cb7 in people_streamingserver_sighandler (signum=6) at src/peoplestreamingserver.cpp:487
#3  <signal handler called>
#4  0x00007f2c2663bfb5 in raise () from /lib64/libc.so.6
#5  0x00007f2c2663dbc3 in abort () from /lib64/libc.so.6
#6  0x00007f2c26680ce0 in ?? () from /lib64/libc.so.6
#7  0x00007f2c270ca7a0 in std::string::assign (this=0x7f2c21bc8d20, __str=<value optimized out>)
    at /home/bbazso/ThirdParty/sources/gcc-4.2.4/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:238
#8  0x00007f2c21bd874a in PEOPLESProtocol::GetStreamName (this=<value optimized out>,
    pRawPath=0x2342fd8 "rtmp://127.0.0.1/mp4:pop.mp4", lStreamName=@0x7f2c21bc8d20)
    at /opt/trx-HEAD/gcc/4.2.4/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../include/c++/4.2.4/bits/basic_string.h:491
#9  0x00007f2c21bd9daa in PEOPLESProtocol::SignalProtocolCreated (pProtocol=0x233a4e0, customParameters=@0x7f2c21bc8de0)
    at peoplestreamer/src/peoplesprotocol.cpp:240

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

  • Valgrind с использованием memcheck и exp-ptrcheck
  • электрический забор
  • Libsafe
  • Я скомпилировал с -fstack-protector-all в gcc
  • Я пытался установить MALLOC_CHECK_ на 2
  • Я провёл свой код через проверку lint, а также cppcheck (чтобы проверить ошибки)
  • И я прошел через код, используя gdb

Так что я много чего перепробовал и все-таки пришел с пустыми руками. Поэтому мне было интересно, может ли это быть что-то вроде проблемы с компоновщиком или какой-то проблемы с библиотекой, которая может быть причиной этой проблемы. Есть ли известные проблемы с std :: string, которые делают make подверженным сбоям в -O2 или, возможно, это не имеет никакого отношения к уровню оптимизации? Но единственная закономерность, которую я могу видеть до сих пор в моей проблеме, заключается в том, что она, кажется, всегда падает на строку, и поэтому мне было интересно, знает ли кто-нибудь о каких-либо проблемах, которые могут быть причиной такого поведения.

Большое спасибо!

Ответы [ 4 ]

10 голосов
/ 21 февраля 2010

Это первоначальное предположение, использующее всю информацию, которую я могу извлечь из вашего обратного следа.

Скорее всего, вы смешиваете и сопоставляете версию gcc, компоновщик и libstdc ++, что приводит к необычному поведению на хост-машине:

  1. libc - это система: /lib64/libc.so.6
  2. libstdc ++ находится в каталоге "ThirdParty" - это подозрения, так как он говорит мне, что он может быть скомпилирован в другом месте с другой целью - /home/bbazso/ThirdParty/sources/gcc-4.2.4/x86_64-pc-linux-gnu/libstdc++-v3/
  3. Еще один libstdc ++ в /opt: /opt/trx-HEAD/gcc/4.2.4/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../include/c++/4.2.4/bits/basic_string.h:491

Кроме того, GCC может смешивать системный ld вместо себя, что может вызвать дальнейшее странное использование карт памяти.

7 голосов
/ 21 февраля 2010

Можете ли вы повторить сбой с помощью основной двухстрочной программы?

#include <string>

int main()
{
    std::string abc;
    abc = "testString";
}

Если произойдет сбой, пожалуйста, опубликуйте ваши точные параметры компиляции / ссылки?

Если нет, начните анализировать ваш код. Удалите несколько строк, пока ошибка не исчезнет. Если у вас есть другие изменения, которые вы можете добавить, чтобы вызвать сбой, и удалить, чтобы он исчез, это должно помочь вам найти проблему.

1 голос
/ 19 октября 2015

Произошло со мной из-за использования malloc для класса, который имел std :: strings в качестве членов данных. Tricky.

0 голосов
/ 21 февраля 2010

Как вы сказали, это странное поведение.

Чтобы быть честным, я думаю, вы тратите время на поиск возможной ошибки с std :: strings. Струны совершенно безопасны, если вы используете их хорошо.

В любом случае, с информацией, которую вы предоставляете: Во-первых, вы используете темы? Это может быть проблема потока. Во-вторых, вы проверяете свою программу, используя valgrind. У вас вообще нет предупреждений?

Примечание. Наиболее важные предупреждения Вальгринда - недопустимое чтение и недопустимая запись.

PS: Как сказано в комментарии, вам, вероятно, следует использовать g ++ для компиляции кода C ++;)

...