I am seeing an issue where, when using the Python API (as an external script rather than the embedded interpreter), the thread properties do not reflect what is in the description. Screenshot attached - I will try to come up with a minimal reproducible example. A simple console application soes not show the issue - maybe it is related to using a Gui application?
lldb version 19.0.0git (ea3d0db1)
lldb doesn’t ship with a summary provider for SBThread. Is this one you added? If so, can you show it here, that’s presumably what’s going wrong.
Sorry that probably wasn’t very clear - this is a Python stacktrace. The values returned from the Python SBThread.name and SBThread.GetName APIs don’t match what’s in SBThread.GetDescription (or SBThread.__repr__ which calls GetDescription)
Note, SBThread.GetDescription fetches that name value (provided you haven’t changed your thread-format setting) by evaluating:
{, name = ${ansi.fg.green}'${thread.name}'${ansi.normal}}
So it is also just accessing the name property on the SBThread. Not sure how those would get off? Maybe one path is triggering an update that the other isn’t.
It’s going to be hard to figure this out w/o a reproducer.
Managed to reproduce it with a reasonably minimal Qt example. Will report as a bug unless I’m missing something obvious.
A minimal Qt example will reproduce it - lldb-test.tar.gz via Dropbox
cd lldb-test
conan install . -of build/linux-debug/conan --build missing
cmake --preset linux-debug
cmake --build build/linux-debug
PYTHONPATH=$(lldb -P) python stacktrace.py build/linux-debug/lldb-test
Thread Description: thread #1: tid = 1512000, 0x00007ffff7fca660 ld-linux-x86-64.so.2`_dl_debug_state, name = 'lldb-test', stop reason = shared-library-event
Thread Name: "lldb-test"
Thread is_stopped: True
Thread stop_reason: "shared-library-event"
Thread Description: thread #1: tid = 1512000, 0x00007ffff7fca660 ld-linux-x86-64.so.2`_dl_debug_state, name = 'lldb-test', stop reason = shared-library-event
Thread Name: None
Thread is_stopped: False
Thread stop_reason: 0
Reproducible with a simple console app if I don’t set SBDebugger.SetAsync(False) - so I’m guessing this is the result of some asynchronous behaviour.
Maybe it’ll be easier if I actually explain what it is I’m trying to do.
I am trying to write a test fixture that, instead of just launching the application as a normal process, launches LLDB and starts the GUI application as a target.
If the application has crashed, when the test fixture exits it should detect this and print a stack trace.
The problem is, as above, the stack trace information is missing. I assume this is because SBDebugger.SetAsync(True).
Maybe I should be looking at the process_events.py example?
If you just want to attach to a process, then do nothing till the process stops, then report something and be done, then you aren’t gaining anything by running in async mode. After all, you are expecting the process to stop once, then you will do your analysis and exit, so managing events isn’t necessary.
Just set the debugger mode to Sync, then you will attach and continue the process you attached to with SBProcess.Continue, which in sync mode won’t return till the process exits or crashes.