[lldb] Introduce backtracing of Swift Tasks #9787

kastiglione · 2024-12-20T23:34:48Z

Introduces the first of a new group of commands for working with Swift Task instances.

The command group is named language swift task, and the first command is backtrace. This backtrace command takes the name of a variable of type Task<Success, Failure> type, and prints the task's backtrace. The output is similar to the builtin thread backtrace (bt) command.

kastiglione · 2024-12-20T23:36:51Z

lldb/source/Plugins/Language/Swift/SwiftFormatters.cpp

+          // Print a backtrace of the Task to stdout.
+          ExecutionContext exe_ctx{m_backend.GetExecutionContextRef()};
+          auto tt = std::make_shared<ThreadTask>(
+              3000, task_info->resumeAsyncContext, exe_ctx);
+          StreamString ss;
+          tt->GetStatus(ss, 0, 100, 0, false, true);
+          auto desc = ss.GetString();
+          printf("%.*s\n", (int)desc.size(), desc.data());


This part is the reason this PR is in draft state. This code prints the backtrace of a task to stdout, but that will be migrated to a separate command. Initially something like language swift task backtrace.

lldb/source/Plugins/LanguageRuntime/Swift/SwiftTask.cpp

lldb/source/Plugins/LanguageRuntime/Swift/SwiftTask.h

felipepiovezan · 2024-12-23T11:18:45Z

lldb/source/Plugins/LanguageRuntime/Swift/SwiftTask.h

+  /// The Task's async context.
+  addr_t m_async_ctx = LLDB_INVALID_ADDRESS;
+  /// The address of the async context's resume function.
+  addr_t m_pc = LLDB_INVALID_ADDRESS;


The name pc here is a bit misleading: it would be natural to think this contains the PC of the top frame of the thread, which is not what this variable contains.
Maybe it would be better to call this m_continuation_address?

When we are unwinding, we say "pc" because we are producing the register context of the frame above the current frame. Here, we just have a Thread class with a member pc, so I don't think the same interpretation would apply.

Actually I am confused now, is this really printing frame 0 correctly?
In the register context class, there is this code:

if (reg_info->kinds[eRegisterKindGeneric] == LLDB_REGNUM_GENERIC_PC) { reg_value = m_pc; return true; }

I could be missing something, but this looks like it prints the PC of frame 1 instead of frame 0.

maybe m_resume_address? since "resume" is the term used in AsyncContext.

I'm not sure where the confusion stems from, but yes this prints "frame 0" correctly.

I changed it to m_resume_fn, how does that sound?

I think I understand 2024 Felipe's confusion now. Usually, the "resume address" (to use the terminology of the code here) means the PC of the "frame above" or the "next funclet to execute after the current frame". However, here we have Tasks which are suspended, so there is no "current frame"; in other words, the "next funclet to execute" is going to be frame zero.

we have Tasks which are suspended, so there is no "current frame"; in other words, the "next funclet to execute" is going to be frame zero.

👍

lldb/source/Plugins/Language/Swift/SwiftFormatters.cpp

felipepiovezan · 2024-12-23T11:24:43Z

lldb/source/Plugins/LanguageRuntime/Swift/SwiftTask.cpp

+  auto resume_offset = ptr_size; // offsetof(AsyncContext, ResumeParent)
+  auto resume_ptr = async_ctx + resume_offset;
+  Status status;
+  m_pc = exe_ctx.GetProcessRef().ReadPointerFromMemory(resume_ptr, status);


I'm moderately concerned that this ctor may fail.
Should we make the constructor take the continuation ptr directly and instead create a "make thread function" that can fail?

That seems fine to me. Note that if ReadPointerFromMemory fails, the resulting address is LLDB_INVALID_ADDRESS, which subsequent code should handle.

Looking at the code where ThreadTask's are created, I don't see any handling of invalid pcs. IIUC we will just print a thread with a weird PC?

there's no handling of invalid pcs, what do you think should be done? I assumed the async context's resume function can be trusted to be valid, but you must see some ways in which it would be invalid?

There's now a failable Create function.

felipepiovezan · 2025-01-07T12:44:28Z

lldb/source/Plugins/LanguageRuntime/Swift/SwiftTask.cpp

+  uint32_t resume_ptr = async_ctx + resume_offset;
+  Status status;
+  m_resume_fn =
+      exe_ctx.GetProcessRef().ReadPointerFromMemory(resume_ptr, status);


IIUC to apply the skip prologue trick, you would need to factor out the fragment below of SwiftLanguageRuntime::TrySkipVirtualParentProlog into a separate function, and say that pc_value = m_resume_fn:

Address pc; Target &target = process.GetTarget(); pc.SetLoadAddress(pc_value, &target); if (!pc.IsValid()) return {}; SymbolContext sc; if (!pc.CalculateSymbolContext(&sc, eSymbolContextFunction | eSymbolContextSymbol)) return {}; if (!sc.symbol && !sc.function) return {}; auto prologue_size = sc.symbol ? sc.symbol->GetPrologueByteSize() : sc.function->GetPrologueByteSize(); return pc_value + prologue_size;

This will be added in a follow up change, which adds language swift task select <task>.

jasonmolenda · 2025-01-07T20:57:13Z

lldb/source/Plugins/LanguageRuntime/Swift/SwiftTask.cpp

+  //   TaskContinuationFunction *ResumeParent;  // offset 8
+  // };
+  uint32_t resume_offset = ptr_size; // offsetof(AsyncContext, ResumeParent)
+  uint32_t resume_ptr = async_ctx + resume_offset;


Given that you show the offsets of Parent and ResumeParent in the comment, is it clarifying to have resume_offset. Why not just addr_t resume_ptr = async_ctx + ptr_size. (also why is resume_ptr uint32_t, it's adding an addr_t and an offset isn't it?)

also why is resume_ptr uint32_t, it's adding an addr_t and an offset isn't it?

yep you caught a bug, it was after I switched these variables away from auto types.

That's one of the reasons I will die on the proverbial auto hill 👀

I'm with you

kastiglione · 2025-01-14T23:52:06Z

@swift-ci test

kastiglione · 2025-01-15T17:35:00Z

@swift-ci test windows

adrian-prantl

Looks good with some minor comments inline.

adrian-prantl · 2025-01-15T18:24:07Z

lldb/source/Plugins/LanguageRuntime/Swift/SwiftLanguageRuntime.cpp

+      return;
+    }
+
+    if (command[0].ref().empty()) {


Is command always guaranteed to be non-empty?

thanks for catching this… it is not.

adrian-prantl · 2025-01-15T18:26:04Z

lldb/source/Plugins/LanguageRuntime/Swift/SwiftLanguageRuntime.cpp

+      return;
+
+    ValueObjectSP task_obj_sp = valobj_sp->GetChildMemberWithName("_task");
+    if (!task_obj_sp)


Shouldn't there something being logged to the command's error stream for all of these failures, so users see what's wrong?

adrian-prantl · 2025-01-15T18:26:35Z

lldb/source/Plugins/LanguageRuntime/Swift/SwiftLanguageRuntime.cpp

+    if (auto err = task_info.takeError()) {
+      LLDB_LOG(GetLog(LLDBLog::DataFormatters | LLDBLog::Types),
+               "could not get info for async task {0:x}: {1}", task_ptr,
+               fmt_consume(std::move(err)));


same here, I think this should be surfaced to the user instead of the log?

adrian-prantl · 2025-01-15T18:28:04Z

lldb/test/API/lang/swift/async/tasks/TestSwiftTaskBacktrace.py

+                "`second() at main.swift:6",
+                "`first() at main.swift:2",
+                "`closure #1 in static Main.main() at main.swift:12",
+            ],


does (lldb) help language swift task (backtrace) work?

yes, the help is here in the definitions of these commands.

kastiglione · 2025-01-15T22:38:30Z

I've applied your advice @adrian-prantl, thanks.

kastiglione · 2025-01-15T22:38:34Z

@swift-ci test

adrian-prantl

Awesome. The error handling will pay off big time when we get bug reports :-)

Introduces the first of a new group of commands for working with Swift Task instances. The new command group is `language swift task`, and the first command is `backtrace`. This `backtrace` command takes the name of a task variable and prints the task's backtrace. The variable can be either `Task<Success, Failure>` or `UnsafeCurrentTask`. The output is similar to the builtin `thread backtrace` (`bt`) command. See the original PR: #9787

Introduces the first of a new group of commands for working with Swift Task instances. The new command group is `language swift task`, and the first command is `backtrace`. This `backtrace` command takes the name of a task variable and prints the task's backtrace. The variable can be either `Task<Success, Failure>` or `UnsafeCurrentTask`. The output is similar to the builtin `thread backtrace` (`bt`) command. See the original PR: #9787 (cherry picked from commit 2c3335d)

[lldb] Introduce backtracing of Swift Tasks

01c80c9

kastiglione requested a review from a team as a code owner December 20, 2024 23:34

kastiglione requested review from adrian-prantl, felipepiovezan and jasonmolenda December 20, 2024 23:35

kastiglione marked this pull request as draft December 20, 2024 23:35

kastiglione commented Dec 20, 2024

View reviewed changes

adrian-prantl reviewed Dec 21, 2024

View reviewed changes

lldb/source/Plugins/LanguageRuntime/Swift/SwiftTask.cpp Show resolved Hide resolved

adrian-prantl reviewed Dec 21, 2024

View reviewed changes

lldb/source/Plugins/LanguageRuntime/Swift/SwiftTask.cpp Outdated Show resolved Hide resolved

adrian-prantl reviewed Dec 21, 2024

View reviewed changes

lldb/source/Plugins/LanguageRuntime/Swift/SwiftTask.cpp Outdated Show resolved Hide resolved

felipepiovezan reviewed Dec 23, 2024

View reviewed changes

Apply code review advice

ead37d6

felipepiovezan reviewed Jan 7, 2025

View reviewed changes

jasonmolenda reviewed Jan 7, 2025

View reviewed changes

Add backtrace command, and tests

6bdbcdc

kastiglione marked this pull request as ready for review January 14, 2025 23:41

kastiglione requested a review from adrian-prantl January 14, 2025 23:51

adrian-prantl approved these changes Jan 15, 2025

View reviewed changes

Improve command error messages

64253ac

kastiglione requested a review from adrian-prantl January 15, 2025 22:38

kastiglione mentioned this pull request Jan 16, 2025

[lldb] Introduce command to select task "threads" #9840

Merged

adrian-prantl approved these changes Jan 16, 2025

View reviewed changes

adrian-prantl merged commit 94fd311 into swift/release/6.1 Jan 16, 2025
3 checks passed

adrian-prantl deleted the dl/lldb-Introduce-backtracing-of-Swift-Tasks branch January 16, 2025 17:47

This was referenced Jan 16, 2025

Revert "[lldb] Introduce backtracing of Swift Tasks" #9844

Merged

[lldb] Introduce backtracing of Swift Tasks #9845

Merged

kastiglione mentioned this pull request Jan 22, 2025

[lldb] Introduce backtracing of Swift Tasks (#9845) #9870

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[lldb] Introduce backtracing of Swift Tasks #9787

[lldb] Introduce backtracing of Swift Tasks #9787

kastiglione commented Dec 20, 2024 •

edited

Loading

kastiglione Dec 20, 2024

felipepiovezan Dec 23, 2024

felipepiovezan Dec 23, 2024

kastiglione Dec 23, 2024 •

edited

Loading

kastiglione Jan 6, 2025

felipepiovezan Jan 7, 2025

kastiglione Jan 7, 2025

felipepiovezan Dec 23, 2024

kastiglione Dec 23, 2024

felipepiovezan Jan 7, 2025

kastiglione Jan 7, 2025

kastiglione Jan 14, 2025

felipepiovezan Jan 7, 2025

kastiglione Jan 14, 2025

jasonmolenda Jan 7, 2025

kastiglione Jan 7, 2025

felipepiovezan Jan 7, 2025

kastiglione Jan 9, 2025

kastiglione commented Jan 14, 2025

kastiglione commented Jan 15, 2025

adrian-prantl left a comment

adrian-prantl Jan 15, 2025

kastiglione Jan 15, 2025 •

edited

Loading

adrian-prantl Jan 15, 2025

adrian-prantl Jan 15, 2025

adrian-prantl Jan 15, 2025

kastiglione Jan 15, 2025

kastiglione commented Jan 15, 2025

kastiglione commented Jan 15, 2025

adrian-prantl left a comment

[lldb] Introduce backtracing of Swift Tasks #9787

[lldb] Introduce backtracing of Swift Tasks #9787

Conversation

kastiglione commented Dec 20, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kastiglione Dec 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kastiglione commented Jan 14, 2025

kastiglione commented Jan 15, 2025

adrian-prantl left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kastiglione Jan 15, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kastiglione commented Jan 15, 2025

kastiglione commented Jan 15, 2025

adrian-prantl left a comment

Choose a reason for hiding this comment

kastiglione commented Dec 20, 2024 •

edited

Loading

kastiglione Dec 23, 2024 •

edited

Loading

kastiglione Jan 15, 2025 •

edited

Loading