On Sun, Sep 27, 2009 at 11:08 PM, Haiping Zhao <[email protected]> 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 _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
