https://github.com/daniilavdeev created https://github.com/llvm/llvm-project/pull/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. >From 8185bd9d8b617fdade03873ba9626296681644d5 Mon Sep 17 00:00:00 2001 From: Daniil Avdeev <[email protected]> Date: Thu, 22 Jan 2026 16:46:35 +0000 Subject: [PATCH] [lldb] address memory leakage in lldb-server 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. --- lldb/source/Host/common/MonitoringProcessLauncher.cpp | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lldb/source/Host/common/MonitoringProcessLauncher.cpp b/lldb/source/Host/common/MonitoringProcessLauncher.cpp index cf1d6b900cdfd..d6c71577421a5 100644 --- a/lldb/source/Host/common/MonitoringProcessLauncher.cpp +++ b/lldb/source/Host/common/MonitoringProcessLauncher.cpp @@ -62,6 +62,8 @@ MonitoringProcessLauncher::LaunchProcess(const ProcessLaunchInfo &launch_info, llvm::toString(maybe_thread.takeError())); if (log) log->PutCString("started monitoring child process."); + auto pthread = maybe_thread->Release(); + pthread_detach(pthread); } 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
