Open matthiaskrgr opened 7 years ago
I believe the leaks are intentional as ninja is not (currently) intended for use in a daemon or library mode, so simple process termination is faster/simpler than releasing memory.
For the record, the two biggest leaks in the sample above add up to quite a bit when building larger projects. This is an empty (rebuild with everything already being compiled) run on llvm/clang:
Direct leak of 154168 byte(s) in 2753 object(s) allocated from:
#0 0x4ea86b in operator new(unsigned long) /home/matthias/LLVM/LLVM_3_9/stage_2/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:78:35
#1 0x5bc1a9 in BuildLog::Load(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) /home/matthias/vcs/github/ninja/src/build_log.cc:309:15
#2 0x4f31b1 in (anonymous namespace)::NinjaMain::OpenBuildLog(bool) /home/matthias/vcs/github/ninja/src/ninja.cc:875:19
#3 0x4ee872 in (anonymous namespace)::real_main(int, char**) /home/matthias/vcs/github/ninja/src/ninja.cc:1163:16
#4 0x4ecabd in main /home/matthias/vcs/github/ninja/src/ninja.cc:1211:10
#5 0x7fbee1baf400 in __libc_start_main /usr/src/debug/glibc-2.24-33-ge9e69e4/csu/../csu/libc-start.c:289
Direct leak of 38224 byte(s) in 2389 object(s) allocated from:
#0 0x4ea86b in operator new(unsigned long) /home/matthias/LLVM/LLVM_3_9/stage_2/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:78:35
#1 0x5f7283 in DepsLog::Load(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, State*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) /home/matthias/vcs/github/ninja/src/deps_log.cc:225:20
#2 0x4f44e9 in (anonymous namespace)::NinjaMain::OpenDepsLog(bool) /home/matthias/vcs/github/ninja/src/ninja.cc:910:18
#3 0x4ee8e0 in (anonymous namespace)::real_main(int, char**) /home/matthias/vcs/github/ninja/src/ninja.cc:1163:41
#4 0x4ecabd in main /home/matthias/vcs/github/ninja/src/ninja.cc:1211:10
#5 0x7fbee1baf400 in __libc_start_main /usr/src/debug/glibc-2.24-33-ge9e69e4/csu/../csu/libc-start.c:289
What sgraham said. The two leaks you mention allocate data that's needed during the build.
If ASAN can find definitely-leaked memory (allocated memory that has no references) as distinct from memory that is still referenced at shutdown that would be valuable. I seem to recall valgrind makes this distinction.
On Feb 23, 2017 9:52 AM, "Nico Weber" notifications@github.com wrote:
What sgraham said. The two leaks you mention allocate data that's needed during the build.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ninja-build/ninja/issues/1247#issuecomment-282067932, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAPB9j4DxBnV3cuktI0aNSxIqQIr7maks5rfcdAgaJpZM4MJZoT .
ASAN does report "direct leaks" and "indirect leaks" is this what you mean? I just did not add the indirect leaks to the report because there were way too much to have them inlined.
@matthiaskrgr Is this still reproducible with Ninja 1.10.0?
If ASAN can find definitely-leaked memory (allocated memory that has no references)
This is exactly what ASan finds. Memory that is still referenced at shutdown (i.e. transitively reachable from a number of root regions through anything that looks like a pointer) in not a leak. It is OK to exit without deallocating everything.
Basically, compile add "-fsanitize=address,undefined -g3 -fno-omit-frame-pointer" to your CFLAGS and "-fsanitize=address,undefined" to your LDFLAGS, build and run ninja.
To do this, I edited the configure.py script since I didn't know any better.
These leaks were reported while bootstrapping ninja:
The "ninja_test" binary also reported a lot of leaks, I am not gonna flood the ticket with these