Re: [Libunwind-devel] Crash inside _ULx86_64_step

[Arun Sharma]

On Sun, Sep 27, 2009 at 11:08 PM, Haiping Zhao <address@hidden> wrote:

> What is the “n” in UNW_DEBUG_LEVEL=n that you recommend? Does it write to
> its own log file or stderr?
>

It writes to stderr. I'd start with n=1:

 UNW_DEBUG_LEVEL=1 ./Ltest-bt 2>&1 | grep _ULx86_64_step
 >_ULx86_64_step: (cursor=0x7fff5647b390, ip=0x0000000000400d92)
 >_ULx86_64_step: (cursor=0x7fff5647b390, ip=0x0000000000401a64)
 >_ULx86_64_step: (cursor=0x7fff5647b390, ip=0x0000000000401ab8)
 >_ULx86_64_step: (cursor=0x7fff5647b390, ip=0x00007f394d8db1c4)
 >_ULx86_64_step: (cursor=0x7fff5647b390, ip=0x0000000000400cb9)

and compare to gdb's stacktrace. Where the two deviate, I'd like to
see output with n=31.

> Also, we are running a multi-threaded application. Is that okay with
> libunwind? We also do some bfd operations to execute something similar to
> what addr2line does, so we can generate full stacktraces with filename and
> line numbers. This is done potentially at the same time from another thread
> when libunwind’s backtrace() is being called. Is that okay? I did spend some
> time to eliminate those bfd calls, while debugging this problem, but there
> is a chance I might have missed one or two places. If you tell me that’s not
> supported, I can completely disable those bfd calls to see whether the crash
> happens again.

Yeah - multi-threaded programs and calls to other libraries at the
same time should be ok.

The main open problem we have with libunwind is the interaction with
dl_iterate_phdr() in glibc.

 -Arun