С++ std::string пулы, отладочные сборки? std::string и проблемы с вальгриндом

У меня есть проблема со многими предупреждениями valgrind о возможных утечках памяти в std::string, как этот:

120 bytes in 4 blocks are possibly lost in loss record 4,192 of 4,687
    at 0x4A06819: operator new(unsigned long) (vg_replace_malloc.c:230)
    by 0x383B89B8B0: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.8)
    by 0x383B89C3B4: (within /usr/lib64/libstdc++.so.6.0.8)
    by 0x383B89C4A9: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, unsigned long, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.8)

Мне интересно:

  • использует ли std::string (GCC 4.1.2) любые пулы памяти?
  • если да, есть ли способ отключить пулы (в виде отладочной сборки и т.д.)?

Ответы

Ответ 1

Отметьте FAQ. В контейнерах есть раздел "Утечки памяти". Вы должны

  • проверьте свою версию Valgrind
  • используйте отладочную сборку вашей программы (и не оптимизированную).
  • и при необходимости определите GLIBCXX_FORCE_NEW. (Это переменная среды, которая влияет на поведение вашей программы во время выполнения, а не на время компиляции #define, как вы могли бы ожидать.)

Ответ 2

Это кажется ложным. Это может быть подавлено, как описано в manual

Ответ 3

Если я правильно помню, многие распределители STL реализуют какое-то сохранение памяти. IE они не освобождают выделенную память сразу, но сохраняют ее и повторно используют. У меня наверняка было много ложных срабатываний в valgrind, исходящих из памяти, выделенных моей реализацией STL.

Лучшим способом, который я нашел для решения проблемы, является (просто) использование файла подавления.

Ответ 5

У меня была эта проблема, и для меня это было связано с тем, что я связывался с версией разработки библиотеки, но мой тестовый код собирал старую версию, установленную системой. Изменения были достаточно тонкими, что он мог бы связываться и работать без каких-либо очевидных проблем, но Valgrind обнаруживал бы странные утечки. Используя ldd вместо valgrind, подтвердил, что он собирал неправильный файл библиотеки. Установка LD_LIBRARY_PATH правильно исправила его, хотя правильное решение - увеличить версию библиотеки, поскольку она, очевидно, не совместима в обратном направлении, если вы это делаете.

Я также видел эту проблему, когда объект не был уничтожен должным образом, например класс с функциями virtual, отсутствующий деструктор virtual. Когда класс помещается в класс-указатель на базовый класс и затем уничтожается, запускается только деструктор базового класса, утечка чего-либо, выделенного в производных классах, например, экземпляры std::string в вашем примере. Подсказка заключалась в том, чтобы проверить, какой класс использует пропущенный string, и следовать иерархии классов обратно в базовый класс и подтвердить, что у него есть явный деструктор virtual, даже пустой. Я предполагал, что они неявны, если в классе есть функции virtual, но, по-видимому, нет, и GCC не предупреждает вас об этом.

Ответ 6

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