View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0016111 | CMake | CMake | public | 2016-05-26 02:39 | 2016-06-10 14:21 | ||||
Reporter | Sergey Kiselev | ||||||||
Assigned To | Brad King | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | Windows | OS | OS Version | ||||||
Product Version | CMake 3.5.2 | ||||||||
Target Version | CMake 3.6 | Fixed in Version | CMake 3.6 | ||||||
Summary | 0016111: Memory leak during function call | ||||||||
Description | There is a memory leak during function call if function contains any if/else/endif statement. | ||||||||
Steps To Reproduce | • Create simple CMakeLists.txt with next content: cmake_minimum_required(VERSION 3.5) project (MyTestProject) function (test_memory_leak) if(ON) endif() endfunction() while(ON) test_memory_leak() endwhile() • Run cmake-gui.exe • Try to configure the project Result: cmake-gui.exe will crash with out of memory (can be seen in Task Manager) | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | CMakeLists.txt [^] (165 bytes) 2016-05-26 02:41 [Show Content] | ||||||||
Relationships | |
Relationships |
Notes | |
(0041097) David Cole (manager) 2016-05-26 04:19 |
That's not a memory leak, that's an infinite loop. |
(0041098) Sergey Kiselev (reporter) 2016-05-26 04:21 edited on: 2016-05-26 04:56 |
Dear David Cole, please make non-infinite while -> situation will be the same. It is just a sample. |
(0041099) Sergey Kiselev (reporter) 2016-05-26 04:26 |
Or try to remove if/else statement from function -> only infinite loop without memory leak |
(0041100) Sergey Kiselev (reporter) 2016-05-26 04:53 edited on: 2016-05-26 05:15 |
Not reproduced in CMake 3.0.0 and 3.3.2 |
(0041101) Sergey Kiselev (reporter) 2016-05-26 05:15 edited on: 2016-05-26 05:22 |
It seems that problem can be reproduced with CMake 3.4.3 and 3.5.2 only. |
(0041104) Rolf Eike Beer (developer) 2016-05-26 06:48 |
This is not exactly a memory leak, as these things get properly cleaned up when CMake terminates. But during the runtime of CMake something keeps accumulating, probably somewhere here: ==29799== 2,000,592 bytes in 22,734 blocks are still reachable in loss record 568 of 569 ==29799== at 0x4C2A68F: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==29799== by 0x647049: cmDefinitions::Set(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*) (in /usr/bin/cmake) ==29799== by 0x501680: cmMakefile::AddDefinition(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*) (in /usr/bin/cmake) ==29799== by 0x5B086E: cmFunctionHelperCommand::InvokeInitialPass(std::vector<cmListFileArgument, std::allocator<cmListFileArgument> > const&, cmExecutionStatus&) (in /usr/bin/cmake) ==29799== by 0x50CFF7: cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) (in /usr/bin/cmake) ==29799== by 0x600687: cmWhileFunctionBlocker::IsFunctionBlocked(cmListFileFunction const&, cmMakefile&, cmExecutionStatus&) (in /usr/bin/cmake) ==29799== by 0x503060: cmMakefile::IsFunctionBlocked(cmListFileFunction const&, cmExecutionStatus&) (in /usr/bin/cmake) ==29799== by 0x50CC25: cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) (in /usr/bin/cmake) ==29799== by 0x50D487: cmMakefile::ReadListFile(cmListFile const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (in /usr/bin/cmake) ==29799== by 0x50F437: cmMakefile::Configure() (in /usr/bin/cmake) ==29799== by 0x6CD5EA: cmGlobalGenerator::Configure() (in /usr/bin/cmake) ==29799== by 0x6DC011: cmGlobalUnixMakefileGenerator3::Configure() (in /usr/bin/cmake) ==29799== ==29799== 7,602,176 bytes in 1 blocks are still reachable in loss record 569 of 569 ==29799== at 0x4C2A68F: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==29799== by 0x546201: void std::vector<cmState::SnapshotDataType, std::allocator<cmState::SnapshotDataType> >::_M_emplace_back_aux<cmState::SnapshotDataType const&>(cmState::SnapshotDataType const&) (in /usr/bin/cmake) ==29799== by 0x54667C: cmLinkedTree<cmState::SnapshotDataType>::Push(cmLinkedTree<cmState::SnapshotDataType>::iterator, cmState::SnapshotDataType) (in /usr/bin/cmake) ==29799== by 0x54177D: cmState::CreateFunctionCallSnapshot(cmState::Snapshot, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (in /usr/bin/cmake) ==29799== by 0x511A54: cmMakefile::PushFunctionScope(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, cmPolicies::PolicyMap const&) (in /usr/bin/cmake) ==29799== by 0x5B0206: cmFunctionHelperCommand::InvokeInitialPass(std::vector<cmListFileArgument, std::allocator<cmListFileArgument> > const&, cmExecutionStatus&) (in /usr/bin/cmake) ==29799== by 0x50CFF7: cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) (in /usr/bin/cmake) ==29799== by 0x600687: cmWhileFunctionBlocker::IsFunctionBlocked(cmListFileFunction const&, cmMakefile&, cmExecutionStatus&) (in /usr/bin/cmake) ==29799== by 0x503060: cmMakefile::IsFunctionBlocked(cmListFileFunction const&, cmExecutionStatus&) (in /usr/bin/cmake) ==29799== by 0x50CC25: cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) (in /usr/bin/cmake) ==29799== by 0x50D487: cmMakefile::ReadListFile(cmListFile const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (in /usr/bin/cmake) ==29799== by 0x50F437: cmMakefile::Configure() (in /usr/bin/cmake) |
(0041105) Brad King (manager) 2016-05-26 08:48 |
This was fixed recently by the commits in this topic: Merge topic 'refactor-cmListFileBacktrace' https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fa4ae9fb [^] |
(0041106) Brad King (manager) 2016-05-26 08:48 |
Among those commits, the main fix is here: cmState: Avoid accumulating snapshot storage for backtraces https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1f6bd8a9 [^] The commit message shows the same example as in the description here. |
(0041163) Kitware Robot (administrator) 2016-06-10 14:21 |
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2016-05-26 02:39 | Sergey Kiselev | New Issue | |
2016-05-26 02:41 | Sergey Kiselev | File Added: CMakeLists.txt | |
2016-05-26 04:19 | David Cole | Note Added: 0041097 | |
2016-05-26 04:21 | Sergey Kiselev | Note Added: 0041098 | |
2016-05-26 04:23 | Sergey Kiselev | Note Edited: 0041098 | |
2016-05-26 04:24 | Sergey Kiselev | Note Edited: 0041098 | |
2016-05-26 04:26 | Sergey Kiselev | Note Added: 0041099 | |
2016-05-26 04:53 | Sergey Kiselev | Note Added: 0041100 | |
2016-05-26 04:55 | Sergey Kiselev | Note Edited: 0041100 | |
2016-05-26 04:56 | Sergey Kiselev | Note Edited: 0041098 | |
2016-05-26 05:15 | Sergey Kiselev | Note Added: 0041101 | |
2016-05-26 05:15 | Sergey Kiselev | Note Edited: 0041100 | |
2016-05-26 05:22 | Sergey Kiselev | Note Edited: 0041101 | |
2016-05-26 06:48 | Rolf Eike Beer | Note Added: 0041104 | |
2016-05-26 08:48 | Brad King | Note Added: 0041105 | |
2016-05-26 08:48 | Brad King | Assigned To | => Brad King |
2016-05-26 08:48 | Brad King | Status | new => resolved |
2016-05-26 08:48 | Brad King | Resolution | open => fixed |
2016-05-26 08:48 | Brad King | Fixed in Version | => CMake 3.6 |
2016-05-26 08:48 | Brad King | Target Version | => CMake 3.6 |
2016-05-26 08:48 | Brad King | Note Added: 0041106 | |
2016-06-10 14:21 | Kitware Robot | Note Added: 0041163 | |
2016-06-10 14:21 | Kitware Robot | Status | resolved => closed |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |