Program stopped without a specific reason. How to interpret this?

Subprojects LLDB
1

Hi,
I’m using lldb to debug a live aarch64 program (attaching to it).
Usually the program stops at some breakpoints but I do see it stops without a reason. Does the program stop waiting for the mutex based on bt output?

The terminal output is like


### ... means omitted content below

(lldb) c
Process 462778 resuming
(lldb) 
error: Process is running.  Use 'process interrupt' to pause execution.
Process 462778 stopped
(lldb) bt
* thread #1, name = 'binary'
  * frame #0: ... `absl::synchronization_internal::Waiter::Wait` ...
    frame #1: ...
    frame #2: ... `absl::Mutex::Await`
    frame #3: ...
    frame #4: ...
    frame #5: ...

How may I interpret this? In particular, I want to know the reason that the program stops upon such output (no specific thread printed)

Thanks!

2

You probably are correct that the thread is blocked acquiring a mutex, but that is most likely not the reason why lldb stopped the process. It’s most likely just a coincidence that the thread was waiting there at the moment when the stop happened.

Stops without a reason are fairly strange, and probably indicate a bug in lldb – normally it should give at least some indication of a reason, even if its not particularly helpful (e.g. SIGSTOP).

The packet logs (log enable gdb-remote packets on the lldb prompt) may give some clues about what’s going on. If you are able to capture/provide those logs from these unexpected stops, I may be able to tell you more.

Inspecting the backtraces of other threads (bt all) could also provide some insight into what triggered this stop.

1 Like
3

Just to clarify the terminology, Processes don’t really have stop reasons. They just stop. Threads have stop reasons. After all, you could stop with one thread having crashed, and another having hit a breakpoint, by the time lldb gets control back. Then lldb has to decide which thread among those that stopped “for a reason” is the one to select. There are some heuristics behind this choice, with a fallback of choosing the first thread in the thread list. That heuristic might have failed somehow. Definitely the output of bt all would be good to see.

2 Likes
4

thanks for pointing out both log enable gdb-remote packets and bt all!