Re: [PATCH] Do not print backtraces on fatal glibc errors

[Mao Han <han_mao at c-sky dot com>]

On Thu, Aug 15, 2019 at 10:00:21PM +0200, Florian Weimer wrote:
> If the process is in a bad state, we used to print backtraces in
> many cases.  This is problematic because doing so could involve
> a lot of work, like loading libgcc_s using the dynamic linker,
> and this could itself be targeted by exploit writers.  For example,
> if the crashing process was forked from a long-lived process, the
> addresses in the error message could be used to bypass ASLR.
> 
> This commit completes the removal of backtrace printing from glibc.
> With the prevalence of external crash handlers, this functionality
> does not appear to be particular useful.  The crash handler may also
> destroy useful information for debugging if coredumps are enabled.

Thanks for this simplification. Dose the previous code(without this
cleanup) intentionally designed to be optimized not to print the
backtrace? My colleague says that the optimization for enum is generic
to all the arch, I've tried to verified that on x86(compiled with
gcc 9.0) and got similar optimization. Our customer complained about
the crash backtrace printing difference between C-SKY and x86. Now I
can tell them it is removed for security and reliability with this
patch. :)
You'v said that this backtrace printing is not particular useful. So
how should I suggest our customer to debug their user program(memory
corruption/segmentation fault)? Coredump, hook the crash handlers by
themself or some other method? I normally do not use tools other
than gdb and don't know much about these.

Thanks,
Mao Han