Как избежать следующей очистки обнаруженной утечки памяти в C++?

Question

Я получаю следующую утечку памяти. Вероятно, это вызвано std::string. как я могу избежать этого?

PLK: 23 bytes potentially leaked at 0xeb68278

  * Suppressed in /vobs/ubtssw_brrm/test/testcases/.purify [line 3]

  * This memory was allocated from:

        malloc         [/vobs/ubtssw_brrm/test/test_build/linux-x86/rtlib.o]

        operator new(unsigned) [/vobs/MontaVista/Linux/montavista/pro/devkit/x86/586/target/usr/lib/libstdc++.so.6]

        operator new(unsigned) [/vobs/ubtssw_brrm/test/test_build/linux-x86/rtlib.o]

        std::string<char, std::char_traits<char>, std::allocator<char>>::_Rep::_S_create(unsigned, unsigned, std::allocator<char> const&) [/vobs/MontaVista/Linux/montavista/pro/devkit/

x86/586/target/usr/lib/libstdc++.so.6]

        std::string<char, std::char_traits<char>, std::allocator<char>>::_Rep::_M_clone(std::allocator<char> const&, unsigned) [/vobs/MontaVista/Linux/montavista/pro/devkit/x86/586/tar

get/usr/lib/libstdc++.so.6]

        std::string<char, std::char_traits<char>, std::allocator<char>>::string<char, std::char_traits<char>, std::allocator<char>>(std::string<char, std::char_traits<char>, std::alloc

ator<char>> const&) [/vobs/MontaVista/Linux/montavista/pro/devkit/x86/586/target/usr/lib/libstdc++.so.6]

        uec_UEDir::getEntryToUpdateAfterInsertion(rcapi_ImsiGsmMap const&, rcapi_ImsiGsmMap&, std::_Rb_tree_iterator<std::pair<std::string<char, std::char_traits<char>, std::allocator<

char>> const, UEDirData >>&) [/vobs/ubtssw_brrm/uectrl/linux-x86/../src/uec_UEDir.cc:2278]

        uec_UEDir::addUpdate(rcapi_ImsiGsmMap const&, LocalUEDirInfo&, rcapi_ImsiGsmMap&, int, unsigned char) [/vobs/ubtssw_brrm/uectrl/linux-x86/../src/uec_UEDir.cc:282]

        ucx_UEDirHandler::addUpdateUEDir(rcapi_ImsiGsmMap, UEDirUpdateType, acap_PresenceEvent) [/vobs/ubtssw_brrm/ucx/linux-x86/../src/ucx_UEDirHandler.cc:374]

Answer 1

Однажды у меня был случай, когда Valgrind указал, что у меня есть утечки в std::string, но я не мог видеть как. Оказалось, что я пропускал другой объект, который содержал строки по значению, но Valgrind правильно также улавливал пропущенную строку памяти (которая была подавляющим большинством утечек). Я подозреваю что uec_UEDir неправильно управляет своими строками или сам просачивается. Я на самом деле в конечном итоге нашел мою проблему с помощью очень тщательной проверки кода.