On Tue, Sep 6, 2011 at 3:41 AM, Arun Sharma <[email protected]> wrote:
> 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? > Hi Arun, Yes, i built libunwind with ./configure --host=arm-none-linux-gnueabi option only. Should i have "--enable-cxx-exceptions" also? Also does libunwind dependent on any other libraries (i.e.) is it dependent on a debug version of a library? like ld (in Valgrind) or libc? Coz all the libraries running in target are stripped production versions without debug. Should i include libunwind first in LD_LIBRARY_PATH? Right now it's at the end? If libunwind takes over gcc libs, is the order of symbol search in LD_LIBRARY_PATH matters? > > 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. > Hmm yes, but the target device does not have enough filesystem space to hold target version of gdb. Besides, the libraries are symbol stripped version and hence target gdb offers no clue. Thanks. > > -Arun >
_______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
