Valgrind обнаруживает это как возможный утечек памяти

Question

Ниже приведена выдержка из кода, в которой я получаю некоторую возможную потерю памяти в отчете Valgrind.

681 int pbsc::PBSCAppMain(int argc, char **argv) 
682 { 
683  char pbscPath[255]; 
684  std::string configDir = "/../config/"; 
685  std::string pbscBinPath = getcwd(pbscPath,255); 
686  std::string pbscConfigPath = pbscBinPath + configDir; 
687 
688 
689 
690  std::string localConfigFile = pbsc::GetFileNameFromDir(pbscConfigPath, PBSC_LOCAL_CONFIG_FILE); 
691  if(false == localConfigFile.empty()) 
692  { 
693   std::string localConfigFileWithPath = pbscConfigPath + localConfigFile; 
694   ReadLocalConfiguration(localConfigFileWithPath); 
695  } 
696 
697  std::string loggerConfigFile = pbsc::GetFileNameFromDir(pbscConfigPath, PBSC_LOGGER_CONFIG_FILE); 
698  if(false == loggerConfigFile.empty()) 
699  { 
700   std::string loggerConfigFileWithPath = pbscConfigPath + loggerConfigFile; 
701   log4cxx::PropertyConfigurator::configureAndWatch(loggerConfigFileWithPath, 20000); 
702  } 
703 

Ниже ошибка, что я получаю от Valgrind

==4594== 
==4594== 67 bytes in 1 blocks are possibly lost in loss record 754 of 1,141 
==4594== at 0x4A075BC: operator new(unsigned long) (vg_replace_malloc.c:298) 
==4594== by 0x5812CA8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (new_allocator.h:104) 
==4594== by 0x581387A: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) (basic_string.tcc:629) 
==4594== by 0x5813913: std::string::reserve(unsigned long) (basic_string.tcc:510) 
==4594== by 0x58139B7: std::string::append(std::string const&) (basic_string.tcc:332) 
==4594== by 0x455446: std::basic_string<char, std::char_traits<char>, std::allocator<char> > std::operator+<char, std::char_traits<char>, std::allocator<char> >(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (basic_string.h:2369) 
==4594== by 0x45ED5F: pbsc::PBSCAppMain(int, char**) (PBSCApp.cpp:686) 
==4594== by 0x45EC9B: main (PBSCApp.cpp:677) 
==4594== 

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

Пожалуйста, укажите, где именно я делаю ошибку.

Добавление еще одного отрывка из отчета Valgrind, который показывает, что даже управление возвращается из функции, но память освобождается.

==4594== 4,620 bytes in 110 blocks are possibly lost in loss record 1,092 of 1,141 
==4594== at 0x4A075BC: operator new(unsigned long) (vg_replace_malloc.c:298) 
==4594== by 0x5812CA8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (new_allocator.h:104) 
==4594== by 0x581387A: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) (basic_string.tcc:629) 
==4594== by 0x5813913: std::string::reserve(unsigned long) (basic_string.tcc:510) 
==4594== by 0x5087CA2: log4cxx::helpers::Transcoder::decode(std::string const&, std::string&) (transcoder.cpp:248) 
==4594== by 0x503FA1A: log4cxx::LogManager::getLogger(std::string const&) (logmanager.cpp:120) 
==4594== by 0x503A498: log4cxx::Logger::getLogger(std::string const&) (logger.cpp:490) 
==4594== by 0x4204D0: FIELD_UT::InitializeLogger(unsigned int, int) (FIELD_UT.cpp:19) 
==4594== by 0x415074: BeamM::FIELD_UT(unsigned int, int, int, int&) (Beam.cpp:62) 
==4594== by 0x4158E0: BeamM::OnUplinkLlcPdu(rgw::pbscpmc::PMC-PBSC-MetaMessage const&, int&) (BeamM.cpp:134) 
==4594== by 0x425551: PBSC_SYS::OnUplinkLlcPdu(rgw::pbscpmc::PMC_PBSC_MetaMessage const&) (PBSC_SYS.cpp:135) 
==4594== by 0x4136A2: PBSCAppMain::HandleMessage(unsigned short, char const*, int) (PBSCAppMain.cpp:28) 

Я не могу отправить весь код, но может разработать последовательность, надеюсь, я буду в состоянии сделать это ....

1. Как показано в докладе Valgrind, PBSCAppMain() после получения что-то в вызове сокета, PBSC_SYS :: OnUplinkLlcPdu.
2. PBSC_SYS :: OnUplinkLlcPdu вызывает BeamM :: OnUplinkLlcPdu.
3. BeamM :: OnUplinkLlcPdu создает объект для FIELD_UT.

4. от BeamM :: OnUplinkLlcPdu, FIELD_UT :: InitializeLogger вызывается для инициализации своего регистратора. Вот точная строка кода для этого.

   void BeamM :: UpdateUT() { shared_ptr pUt = nullptr; pUt = AddUT (lli); pUt-> InitializeLogger (lli); }

   недействительными УТ :: InitializeLogger (без знака INT TLLI, Int beamId) { mLogger = log4cxx :: Logger :: getLogger ("ут." + To_string (LLI)); LOG4CXX_DEBUG (mLogger, «UT Logger created»); }

Теперь, если я не ошибаюсь, после initilizing управления Logger будет тогда, почему в этом случае также, valgring говорит ... Возможно, утечка.

Спасибо ..

Answer 1

попробуйте изменить

char pbscPath[255]; 
std::string configDir = "/../config/"; 
std::string pbscBinPath = getcwd(pbscPath,255); 
std::string pbscConfigPath = pbscBinPath + configDir; 

в

char pbscConfigPath[300]; 
getcwd(pbscConfigPath,255); 
strcat(pbscConfigPath,"/../config/"); 

старой школы, но вам не придется беспокоиться о том, скрытый класс вещей, (и это быстрее тоже).

Answer 2

он остается в то время как 1, непрерывно продолжает проверять данные на сокет, а также продолжать читать файлы

Ну, если он остается в петле навсегда (или, вернее, пока процесс не будет завершен принудительно), то (в контексте программы) управление никогда не оставляет функцию.

Итак, когда вы ожидали, что эти ресурсы будут освобождены? Valgrind тоже не знает.

Это ложное срабатывание; не беспокойтесь об этом.
(Обратите внимание, что он говорит, что «возможно, потерял», а не «определенно потерял».)