How to use backtrace() safely in signal handler.

[Florian Weimer]

* Paul Guo:

>  > But https://sourceware.org/ml/libc-alpha/2015-02/msg00659.html
>  > <https://sourceware.org/ml/libc-alpha/2015-02/msg00659.html>says
>  > backtrace() trigger malloc() only when dynamically loading libgcc. Does
>  > that mean if libgcc was preloaded in the application we do not need to
>  > worry about that?
>
>  This no longer applies to current glibc for a whole bunch of reasons.
>
> OK. Do you mean with current glibc, if a program is calling malloc()
> and gets a signal, and if the signal handler calls backtrace(),
> backtrace() won't be safe?

The thread you referenced was not about that.

Whether the scenario you describe depends on a lot of circumstances.  It
can be made safe, but in general, it is not.

> OK. Can I summarize like this after reading replies for questions 2 & 3 & 4:
>
> If the application is preloading some libraries, then if it gets a
> signal and then backtrace() in the signal handler won't not
> safe. Other signal unsafe issues include 1) reentrance of backtrace()
> due to various possible locks or even data corruption. 2) the "heap"
> issue(If I understand correctly. See reply above), In other cases
> backtrace() is ok as a signal handler?

If you want to be compatible with future glibc versions, you cannot
assume that certain uses of backtrace are async-signal-safe.

>  If this is just for a crash reporter, you really need to move this
>  out-of-process because in-process crash handlers will always be prone to
>  deadlocks and can obscure the actual source of the crash.
>
>  
> What is the usual "out-of-process" practice?
>   /proc/sys/kernel/core_pattern + abrt kind of configuration (take rhel/centos distribution as an example)?

Yes, or analyzing plain old coredumps.

The kernel coredump hooks have the advantage that they can produce a
backtrace even without writing the core to disk.

Thanks,
Florian