[Lldb-commits] [lldb] [lldb] Don't crash when attaching to pid and no binaries found (PR #100287)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda created https://github.com/llvm/llvm-project/pull/100287

There is a narrow window during process launch on macOS where lldb can attach and no binaries will be seen as loaded in the process (none reported by libdyld SPI).  A year ago I made changes to set the new-binary-loaded breakpoint correctly despite this.  But we've seen a crash when this combination is seen, where CommandObjectProcessAttach::DoExecute assumed there was at least one binary registered in the Target.  Fix that.

Also fix two FileSpec API uses from when we didn't have a GetPath() method that returned a std::string, and was copying the filepaths into fixed length buffers.  All of this code was from ~14 years ago when we didn't have that API.

rdar://131631627

>From 4cec9c8e71229cb47ab0d0536f7e654caf05d2f1 Mon Sep 17 00:00:00 2001
From: Jason Molenda <jmolenda at apple.com>
Date: Tue, 23 Jul 2024 17:33:24 -0700
Subject: [PATCH] [lldb] Don't crash when attaching to pid and no binaries
 found

There is a narrow window during process launch on macOS where
lldb can attach and no binaries will be seen as loaded in the
process (none reported by libdyld SPI).  A year ago I made
changes to set the new-binary-loaded breakpoint correctly despite
this.  But we've seen a crash when this combination is seen, where
CommandObjectProcessAttach::DoExecute assumed there was at least
one binary registered in the Target.  Fix that.

Also fix two FileSpec API uses from when we didn't have a GetPath()
method that returned a std::string, and was copying the filepaths
into fixed length buffers.  All of this code was from ~14 years ago
when we didn't have that API.

rdar://131631627
---
 lldb/source/Commands/CommandObjectProcess.cpp | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/lldb/source/Commands/CommandObjectProcess.cpp b/lldb/source/Commands/CommandObjectProcess.cpp
index 50695af556939..e605abdb3c771 100644
--- a/lldb/source/Commands/CommandObjectProcess.cpp
+++ b/lldb/source/Commands/CommandObjectProcess.cpp
@@ -369,25 +369,23 @@ class CommandObjectProcessAttach : public CommandObjectProcessLaunchOrAttach {
 
     // Okay, we're done.  Last step is to warn if the executable module has
     // changed:
-    char new_path[PATH_MAX];
     ModuleSP new_exec_module_sp(target->GetExecutableModule());
     if (!old_exec_module_sp) {
       // We might not have a module if we attached to a raw pid...
       if (new_exec_module_sp) {
-        new_exec_module_sp->GetFileSpec().GetPath(new_path, PATH_MAX);
-        result.AppendMessageWithFormat("Executable module set to \"%s\".\n",
-                                       new_path);
+        result.AppendMessageWithFormat(
+            "Executable binary set to \"%s\".\n",
+            new_exec_module_sp->GetFileSpec().GetPath().c_str());
       }
+    } else if (!new_exec_module_sp) {
+      result.AppendWarningWithFormat("No executable binary.");
     } else if (old_exec_module_sp->GetFileSpec() !=
                new_exec_module_sp->GetFileSpec()) {
-      char old_path[PATH_MAX];
-
-      old_exec_module_sp->GetFileSpec().GetPath(old_path, PATH_MAX);
-      new_exec_module_sp->GetFileSpec().GetPath(new_path, PATH_MAX);
 
       result.AppendWarningWithFormat(
-          "Executable module changed from \"%s\" to \"%s\".\n", old_path,
-          new_path);
+          "Executable binary changed from \"%s\" to \"%s\".\n",
+          old_exec_module_sp->GetFileSpec().GetPath().c_str(),
+          new_exec_module_sp->GetFileSpec().GetPath().c_str());
     }
 
     if (!old_arch_spec.IsValid()) {