Author: daniilavdeev Date: 2026-02-23T12:14:17+03:00 New Revision: d7fac0f42a3a8a6d6cf827d1f8b38663f872fe0f
URL: https://github.com/llvm/llvm-project/commit/d7fac0f42a3a8a6d6cf827d1f8b38663f872fe0f DIFF: https://github.com/llvm/llvm-project/commit/d7fac0f42a3a8a6d6cf827d1f8b38663f872fe0f.diff LOG: [lldb] address memory leakage in lldb-server (#177572) lldb-server has exhibited fairly unexpected behaviour. The time each iteration of the main loop takes (attach + spawn a child process) has been progressively increasing over the course of the lldb-server execution. For instance, at the beginning of the remote tests run (when a single instance of lldb-server on the remote side processes all the incoming connections), each iteration took approximately 0.1 seconds, increasing to 1.5 seconds by the end. The analysis of the lldb-server application indicates that the __libc_fork function takes more and more time on each iteration. The most plausible interpretation of this fact would appear to be that the application accumulates a certain resource that the fork function subsequently had to process. The following investigation has shown that the memory leakage did seem to take place during the lldb-server execution. After the spawn of a child process lldb-server additionally creates a monitoring thread, the only purpose of which is to call a waitpid on the corresponding child process. However, it appears to me that lldb-server application tracks neither its children nor these internal threads, which ultimately results in the threads not being joined or detached and the resources associated with these threads won't be released. Meanwhile, the creation of the thread is followed by the allocation of the stack memory for this thread (usually 8MB), which is never released. Given this behaviour, the amount of unfreed memory accumulated by the lldb-server reaches approximately 30-35GB by the end of the test run. At the same time, the fork function maps the parent's memory to the child process, therefore the uncontrolled growth of unnecessary memory slows the execution of the fork function significantly. To summarise, the memory leakage that was caused by the inappropriate managing of the internal threads appears to be the underlying cause of the progressively increasing duration of the main loop, leading to performance degradation of lldb-server application, which is especially noticeable during long tests runs. The proposed solution at this stage is to simply detach internal threads, so that the OS can release memory associated with these threads. That is to say, it seems to me that lldb-server doesn't have appropriate mechanisms to track spawned threads, therefore a more thoughtful approach would likely require changes to a substantial part of the existing logic. Added: Modified: lldb/source/Host/common/MonitoringProcessLauncher.cpp Removed: ################################################################################ diff --git a/lldb/source/Host/common/MonitoringProcessLauncher.cpp b/lldb/source/Host/common/MonitoringProcessLauncher.cpp index cf1d6b900cdfd..2d9379f697742 100644 --- a/lldb/source/Host/common/MonitoringProcessLauncher.cpp +++ b/lldb/source/Host/common/MonitoringProcessLauncher.cpp @@ -56,12 +56,17 @@ MonitoringProcessLauncher::LaunchProcess(const ProcessLaunchInfo &launch_info, assert(launch_info.GetMonitorProcessCallback()); llvm::Expected<HostThread> maybe_thread = process.StartMonitoring(launch_info.GetMonitorProcessCallback()); - if (!maybe_thread) + if (!maybe_thread) { error = Status::FromErrorStringWithFormatv( "failed to launch host thread: {}", llvm::toString(maybe_thread.takeError())); - if (log) - log->PutCString("started monitoring child process."); + } else { + if (log) + log->PutCString("started monitoring child process."); + + // Allow the thread to exit on its own once its work is done. + maybe_thread->Reset(); + } } else { // Invalid process ID, something didn't go well if (error.Success()) _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
