Re: Using libdw to get symbol names inside signal handler

Re: Using libdw to get symbol names inside signal handler

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 1467 bytes --]

Hi,

On Fri, 2016-04-01 at 11:38 +0000, marko(a)kevac.org wrote:
> I would like to user libunwind and libdw to get backtrace and symbol names
> for backtrace from inside SIGSEGV signal handler.
> 
> I understand that libdw does not have documentation at all, so I am looking
> for help here.

It does have documentation, but it is indeed not as full as we would
like. Please take a look at libdw.h and libdwfl.h

> Is it good decision to use libunwind and libdw for getting backtrace from
> inside signal handler?
> Is libdw async signal safe?

You don't need libunwind for unwinding, you can use the
dwfl_frame_thread calls part of libdw described in libdwfl.h for that.
libdwfl is not designed to be signal safe and it wasn't originally
designed as an in-process unwinder. But people have used it for that.
You might want to take a look at the work of Ben Gamari done a couple of
months back on this mailinglist in a thread with the subject "Using dwfl
to enumerate frames of current thread".

If you really need an in-process unwinder then I would recommend you
take a look at the libbacktrace from the GCC project:
https://gcc.gnu.org/viewcvs/gcc/trunk/libbacktrace/

If you just want to get a good backtrace when you get a SIGSEGV or other
fatal signal it makes sense to just call eu-stack -P TID on yourself.
fork and exec are signal safe. And then you don't have to try to deal
with a possibly corrupt program.

Cheers,

Mark

Re: Using libdw to get symbol names inside signal handler

[marko]

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

On Fri, Apr 1, 2016 at 4:34 PM Mark Wielaard <mjw@redhat.com> wrote:

>
> It does have documentation, but it is indeed not as full as we would
> like. Please take a look at libdw.h and libdwfl.h
>

For someone who is familiar with ELF innards maybe, but for someone who
just wants backtrace and symbol names not so much :-)


> If you really need an in-process unwinder then I would recommend you
> take a look at the libbacktrace from the GCC project:
> https://gcc.gnu.org/viewcvs/gcc/trunk/libbacktrace/


I really do. Not only for logging after segmentation fault, but also for
watchdog feature: print stack trace if program stuck somewhere and could
not rewind SIGALRM timeout in time.

I have found standalone fork of libbacktrace (
https://github.com/ErwanLegrand/libbacktrace
<https://github.com/ErwanLegrand/libbacktrace_>) and will try it. Thank
you.


> If you just want to get a good backtrace when you get a SIGSEGV or other
> fatal signal it makes sense to just call eu-stack -P TID on yourself.
> fork and exec are signal safe. And then you don't have to try to deal
> with a possibly corrupt program.
>

It would be fine for SIGSEGV case, but not for watchdog (SIGALRM) case.

Thanks again for rapid answer!

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1963 bytes --]

Using libdw to get symbol names inside signal handler

[marko]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

Hello.

I would like to user libunwind and libdw to get backtrace and symbol names
for backtrace from inside SIGSEGV signal handler.

I understand that libdw does not have documentation at all, so I am looking
for help here.

Is it good decision to use libunwind and libdw for getting backtrace from
inside signal handler?
Is libdw async signal safe?
Can you give me an example, please?

Thanks!

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 533 bytes --]