On Wed, May 21, 2014 at 09:37:35AM +0000, Wangrui (K) wrote:
> -----Original Message-----
> From: Daniel P. Berrange [mailto:berrange@redhat.com]
> Sent: Tuesday, May 20, 2014 5:05 PM
> To: Wangrui (K)
> Cc: libvir-list(a)redhat.com; zhouyimin Zhou(Yimin); Yanqiangjun
> Subject: Re: [PATCH] virlog: Add stack trace log when libvirt receives fatal signal
>
> On Tue, May 20, 2014 at 08:59:37AM +0000, Wangrui (K) wrote:
> > An earlier commit(c0c8c1) Dan removed global log buffer feature entirely
> > because of duplicate log messages. An improvement is introduced. That is
> > dumping stack trace instead of log buffer upon libvirt crash.
>
>
> This is not going to work. virLogStackTraceToFd invokes the
> backtrace/backtrace_symbols_fd functions which are not async
> signal safe. They are also not likely to be reliable to use
> when you have memory corruption triggering the signal.
>
> The 'abrt' program is commonly used on modern Linux distros to
> generate stack traces when processes crash / terminate abnormally.
> abrt has the added benefit that the stack traces it records include
> all function parameters and local variables.
>
Oops.
I didn't realize Async-signal-(un)safe functions in virLogStackTraceToFd.
And it seems that only kernel coredump can be used in this case.
My original purpose is to trace stack on crash/obort and etc without
using kernel.core_pattern (sometimes kernel coredump is not turned on ).
If you use '| /full/path/to/script_that_gets_coredump_on_stdin' for
the kernel.core_pattern, it will work even when ulimit is turned off.
In that script you can throw away all the coredumps you don't want and
capture only those you want and only when you want. You can use
default percent syntax to specify parameters for the script and base
the decision on that.
Martin