[LLVMdev] Problem Using libLLVM-3.3.so

[Óscar Fuentes]

Rick Sullivan <ricks at carbondesignsystems.com> writes:

> I've also tried running simulations without using libLLVM-3.3.so, but
> instead statically linking the required LLVM .a libraries into the
> component shared objects. This is not an idea solution, because it
> effectively bundles LLVM into each component, more than doubling the
> size of each component on disk. However, this also produces a crash
> with a more meaningful stack trace. Whether this is related to the
> failures I'm seeing with the LLVM shared object - I don't know. Here
> is the valgrind report:
>
>       ==15093== Jump to the invalid address stated on the next line
>       ==15093==    at 0x0: ???
>       ==15093==    by 0x285C2321: llvm::cl::parser<(anonymous namespace)::DefaultOnOff>::~parser() (CommandLine.h:629)
>       ==15093==    by 0x285C23D9: llvm::cl::opt<(anonymous namespace)::DefaultOnOff, false, llvm::cl::parser<(anonymous namespace)::DefaultOnOff>::~opt() (CommandLine.h:1
>       ==15093==    by 0x285A3BD1: __tcf_5 (DwarfDebug.cpp:85)
>       ==15093==    by 0x441867: __cxa_finalize (in /lib/tls/libc-2.3.4.so)
>       ==15093==    by 0x282212F2: (within libCORTEXA9MP.mx_DBG.so)
>       ==15093==    by 0x28EEBB05: (within libCORTEXA9MP.mx_DBG.so)
>       ==15093==    by 0x518C41: _dl_close (in /lib/tls/libc-2.3.4.so)
>       ==15093==    by 0x56DD59: dlclose_doit (in /lib/libdl-2.3.4.so)
>       ==15093==    by 0x40966D: _dl_catch_error (in /lib/ld-2.3.4.so)
>       ==15093==    by 0x56E2BA: _dlerror_run (in /lib/libdl-2.3.4.so)
>       ==15093==    by 0x56DD89: dlclose (in /lib/libdl-2.3.4.so)

It is crashing while destroying a static instance of cl::opt. The `this'
pointer is null. I'll say memory corruption. Does Valgrind report
something about that? LLVM has a lot of shared state. If you load
several shared libraries, each containing its own copy of LLVM, and they
interact one with each other, bad things may happen.

Also, check that you are initializing LLVM on a sane way, and that you
are terminating it the right way too (make sure that the LLVM objects
you destroy are owned by you, and those that you don't are owned by
LLVM.) Try to bisect the problematic area by removing functionality from
your code.

If you can replicate the crash by loading just one shared library that
uses LLVM plus the valgrind report contains nothing about memory
corruption, file a bug report.