what if i want to get the othe threads' stack

[NikoLXQ]

SDK have this api sentry_value_new_stacktrace( void **ips, size_t len). when the ips is null, it will get current thread stack. but what if i want to get the othe threads' stack. how can i make it ？

[supervacuus]

Hi @NikoLXQ! On which OS are you trying to do this?

The general answer: sentry_value_new_stacktrace() internally uses OS APIs that capture only the stack trace from the calling thread. This is because tracing the stack from another thread is not safe since that thread continues to run. Suspending and resuming threads are typically application-level responsibilities.

In the crash case, our backends use OS-level debug capabilities to suspend all threads before snapshotting their stacks which can have racy consequences because it stops threads in uncoordinated moments. This is considered acceptable when the application is going to crash anyway, but a big issue in normal operation.

[NikoLXQ]

Hi @supervacuus . Thanks for your answer, I'm planning to do this on android. The reason is that I want to monitor our sdk main thread at the native level to see if it is stuck. Once we find a stuck situation, we want to get the stack of other threads to get a full picture of what other threads are doing to cause the main thread to get stuck. I know this is an unsafe behavior and requires to fork child process ptrace stack. But there doesn't seem to be any other way to do it.

[supervacuus]

I understand. There is really no way around heavy-handed thread suspension or sending signals to threads where the signal handler generates the stack trace (which you can try to collect from each signal handler and send as a single event). The latter is safe since each thread is blocked for each handler, but there is no guarantee that the threads will handle the signals at the exact same moment (although thread suspension via ptrace is also not a clock-cycle accurate operation ;-) ).

The topic of monitoring blocked threads and providing an overview of the process (and all its threads) is a recurring inquiry. Some of our users intentionally crash the process to generate a minidump when one of the essential threads is stuck, but this is not an option on Android yet (it could be if you targetted Android-R and above: #743 (comment) which would allow you to programmatically retrieve tombstones after crashes). Others use operating system primitives that require privileged execution (like eBPF). What I am trying to say: we are always very interested in the solutions our users find (even if it turns out to bypass the Native SDK entirely).