On Mon, Sep 5, 2011 at 9:30 AM, Shan Shan <[email protected]> wrote: > Even without me calling any of the unwind apis (as mentioned in step 7), the > app crashes. So pretty much this happens only when linking with -lunwind. It > runs for a minute or so and it crashes. Within that minute, there were ~20K > alloc/frees happened coz of constructors.
If you don't make any calls to libunwind APIs and yet experience crashes by merely linking with it, my guess is that you're overriding some of the libgcc APIs (eg: c++ exception handling or backtrace() or something else). The namespace collision between some of the gcc internal libs and libunwind is by design, because on some platforms (eg: ia64), libunwind is the default implementation. Could you confirm that you're not running configure with --enable-cxx-exceptions? > Great. Did you use LD_PRELOAD trick? It is so appealing because of it's ease > of instrumentation. That's why i am not giving up yet to get the backtrace. > The target is a small device with nand based filesystem and cannot hold huge > data. Hence i send it to host for post processing. > Any advice/tips would be really great :-). Appreciate your help This is exactly how open source versions of google-perftools work. It supports LD_PRELOAD as well. I'd try compiling with --enable-debug and running with UNW_DEBUG_LEVEL=1 (or 15) and try to load symbols from shared libs in gdb, so we get a better sense of what's going wrong. Sometimes if gdb has trouble unwinding because of missing unwind symbols, libunwind will likely have the same problem. -Arun _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
