2

There is a multithreaded app running on Linux, CPU architecture is x86_64. I want to be able to obtain stack trace as backtrace() function does. After signal handler returns the app will continue running. This is SIGUSR1 handler.

backtrace() is considered not signal safe and I can’t convince myself it can be used from signal handler in this scenario.

I saw couple comments stating LLVM libunwind is signal safe, though didn’t find such statement e.g. in library docs.

So is it safe to use libunwind from a signal handler? If yes, why?

If not, what are other options?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
ivan_onys
  • 2,282
  • 17
  • 21
  • AFAIK, If you are using `libunwind` only in your handler and you didn't use `SA_NODEFER` you should be ok. Under these assumptions, your handler cannot interrupt itself and it cannot interrupt a function in `libunwind`. – Margaret Bloom Apr 06 '23 at 19:04

1 Answers1

1

So long as you are unwinding locally (i.e. from the process you are acquiring the call stack of), backtrace is signal-safe. From the libunwind's docs:

The manual page for each libunwind routine identifies whether or not it is signal-safe, but as a general rule, any routine that may be needed for local unwinding is signal-safe (e.g., unw_step() for local unwinding is signal-safe). For remote-unwinding, none of the libunwind routines are guaranteed to be signal-safe.

Tanner Firl
  • 80
  • 6