search for: __cxa_finalize

...000001000cf821 in ~IntegerBinOpFunction (this=0x1016e4710) at /Users/talin/Projects/tart/trunk/compiler/lib/Objects/Operators.cpp:56 #13 0x00000001000c1f65 in ~IntegerBinOpFunction (this=0x1016e4710) at /Users/talin/Projects/tart/trunk/compiler/lib/Objects/Operators.cpp:54 #14 0x00007fff830e6374 in __cxa_finalize () #15 0x00007fff830e628c in exit () #16 0x0000000100001a3b in start () I would generally expect this kind of "pure virtual" error to be the result of double-destruction - the first destruction having swizzled the vtable pointer of the object in question. But my debugging of the code sho...

...p<char, llvm::BumpPtrAllocator>::~StringMap() + 74 12 tartc 0x0000000100101224 tart::StringTable::~StringTable() + 24 13 tartc 0x0000000100101905 tart::Module::~Module() + 1609 14 tartc 0x00000001000fd67b __tcf_3 + 27 15 libSystem.B.dylib 0x00007fff830e6374 __cxa_finalize + 203 16 libSystem.B.dylib 0x00007fff830e628c exit + 18 17 tartc 0x000000010000173b start + 59 / On Sat, Oct 15, 2011 at 11:19 PM, Talin <viridia at gmail.com> wrote: > On Sat, Oct 15, 2011 at 9:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> On Sa...

...:227) ==19966== by 0x5D86A39: llvm::PassNameParser::~PassNameParser() (Pass.cpp:237) ==19966== by 0x5D948A5: llvm::cl::list<llvm::PassInfo const*, bool, llvm::PassNameParser>::~list() (CommandLine.h:1010) ==19966== by 0x5D88E61: __tcf_2 (PassManager.cpp:69) ==19966== by 0x660A587: __cxa_finalize (cxa_finalize.c:56) ==19966== by 0x4A8D842: ??? (in /home/mvillmow/Source/stg/opencl/drivers/opencl/dist/linux/debug/lib/x86/libamdoclcl32.so) ==19966== by 0x5E2F85B: ??? (in /home/mvillmow/Source/stg/opencl/drivers/opencl/dist/linux/debug/lib/x86/libamdoclcl32.so) ==19966== ==19966== 12 byte...

...no calls in or out, I get one descriptor per day, maybe of a daily reload or something. I haven't gotten that far in my investigations yet. Since the module isn't compiled with debug info, the best stack trace I can get is: #0 0x4d5544a0 in pipe () from /lib/libc.so.6 #1 0xb69384ce in __cxa_finalize () from /usr/lib/asterisk/modules/codec_g729a.so #2 0xae7fdae4 in ?? () #3 0xae7fcae4 in ?? () #4 0x00001000 in ?? () #5 0x00000000 in ?? () The version of the g279 module is: Digium G.729A Module Version 1.6.2.0_3.1.4 (optimized for generic_32) Just now, on a very low-volume asterisk server...

...ser() (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.s...

...uot;../lib/talloc/talloc.c:2251") at ../lib/talloc/talloc.c:851* *#4 0xb7bb3742 in _talloc_free (ptr=0x8060db8, location=0xb7bb54c7 "../lib/talloc/talloc.c:2251") at ../lib/talloc/talloc.c:1371* *#5 0xb7bb4d82 in talloc_autofree () at ../lib/talloc/talloc.c:2251* *#6 0xb7e865e8 in __cxa_finalize () from /lib/i386-linux-gnu/libc.so.6* *#7 0xb7bb1a43 in __do_global_dtors_aux () from /usr/local/samba/lib/private/libtalloc.so.2* #8 0xb7ff4e52 in ?? () from /lib/ld-linux.so.2 #9 0xb7ff5947 in ?? () from /lib/ld-linux.so.2 #10 0xb7e53cc4 in ?? () from /lib/i386-linux-gnu/libdl.so.2 #11 0xb7fe...

Hi, Not sure whether this matches your use case, but the Orc-based JIT used in LLI appears to be using `llvm::orc::LocalCXXRuntimeOverrides` (http://llvm.org/doxygen/classllvm_1_1orc_1_1LocalCXXRuntimeOverrides.html) to override `__cxa_atexit`: https://github.com/llvm-mirror/llvm/blob/release_50/tools/lli/OrcLazyJIT.h#L74

...0x00007f7ef040ae3a in ___lwp_park60 () from /usr/libexec/ld.elf_so #1 0x00007f7ef0402728 in _rtld_exclusive_enter (mask=mask at entry=0x7f7fff9017e0) at /usr/src/libexec/ld.elf_so/rtld.c:1679 #2 0x00007f7ef040339b in _rtld_exit () at /usr/src/libexec/ld.elf_so/rtld.c:375 #3 0x000077ea83cdfdc2 in __cxa_finalize (dso=dso at entry=0x0) at /usr/src/lib/libc/stdlib/atexit.c:215 #4 0x000077ea83cdfab3 in exit (status=19) at /usr/src/lib/libc/stdlib/exit.c:60 #5 0x0000000000414fe1 in ?? () #6 0x000000000041bc19 in ?? () #7 <signal handler called> #8 0x00007f7ef0405cd2 in _rtld_find_symdef (flags=1, de...

Rick Sullivan <ricks at carbondesignsystems.com> writes: [snip] > The problem is this. For some simulations, the LLVM shared library > seems to take a segfault on exit. It runs correctly, but when the > simulator finishes, it crashes on exit. [snip] > > Does anybody have any ideas as to why this might be happening? Can you run the application under gdb and obtain a

On Sat, Oct 15, 2011 at 9:20 PM, Talin <viridia at gmail.com> wrote: > I recently updated my version of LLVM from revision 140108 to 142082, and > several things broke, most of which were easily fixed. However, I'm now > getting a "pure virtual method called" exception (__cxa_pure_virtual) which > I wasn't getting before. This is happening in the destructor of

I recently updated my version of LLVM from revision 140108 to 142082, and several things broke, most of which were easily fixed. However, I'm now getting a "pure virtual method called" exception (__cxa_pure_virtual) which I wasn't getting before. This is happening in the destructor of a statically-initialized object. (More precisely, it's blowing up in a BumpPtrAllocator,

We're using the LLVM 3.3 AArch64 disassembler in the following way. We have built LLVM 3.3 on Linux as a shared library; and have a main program that dynamically loads shared objects (.so libraries). The program is a simulator (though that shouldn't be relevant to this question), and the shared objects it loads are electronic components that participate in the simulation. If the electronic

Hi All, I'm still actively researching this problem (reading R-ext manual), but I hoped that I might be able to get some additional insight from the list given that I'm fairly new at writing R extension code. Problem: I have some fairly simple code (.Call interface) that makes a call to another shared library, which, in turn, calls routines in an HDF5 shared library. The good news

...w _Jv_RegisterClasses 0000000000208008 d __CTOR_END__ 0000000000208000 d __CTOR_LIST__ 0000000000208018 d __DTOR_END__ 0000000000208010 d __DTOR_LIST__ 0000000000007e58 r __FRAME_END__ 0000000000208020 d __JCR_END__ 0000000000208020 d __JCR_LIST__ 000000000020aee0 A __bss_start w __cxa_finalize@@GLIBC_2.2.5 0000000000006e20 t __do_global_ctors_aux 0000000000003890 t __do_global_dtors_aux 0000000000208680 d __dso_handle w __gmon_start__ U __stack_chk_fail@@GLIBC_2.4 U __strdup@@GLIBC_2.2.5 000000000020aee0 A _edata 000000000020aef0 A _end...

...w _Jv_RegisterClasses 0000000000208008 d __CTOR_END__ 0000000000208000 d __CTOR_LIST__ 0000000000208018 d __DTOR_END__ 0000000000208010 d __DTOR_LIST__ 0000000000007e58 r __FRAME_END__ 0000000000208020 d __JCR_END__ 0000000000208020 d __JCR_LIST__ 000000000020aee0 A __bss_start w __cxa_finalize@@GLIBC_2.2.5 0000000000006e20 t __do_global_ctors_aux 0000000000003890 t __do_global_dtors_aux 0000000000208680 d __dso_handle w __gmon_start__ U __stack_chk_fail@@GLIBC_2.4 U __strdup@@GLIBC_2.2.5 000000000020aee0 A _edata 000000000020aef0 A _end...

This is a followup to the discussion that started in D28791. To provide the context, we need a way to provide __dso_handle in Fuchsia. __dso_handle symbol is mandated by C++ ABI with a value which is an address in one of the object's segments, and as such this symbol has to be included statically and cannot be a part of a shared library. Different systems provide it differently: 1. On

Hi R-devel, I'm trying to get R 3.2.1 working on Haiku (an open source OS inspired by BeOS, not Linux based) on i586. With a few small changes to library paths and ifdefs I am able to get a seemingly working R binary. The build process stops with the 'tools' package. The last lines from make are below. Does anyone have any tips? I'm rather new to debugging at this low level. Are

...00000 DF *UND* 00000000000001be Base _ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEi 0000000000000000 DF *UND* 0000000000000029 GLIBC_2.2.5 strcspn 0000000000000000 DF *UND* 000000000000001a GLIBC_2.2.5 timegm 0000000000000000 w DF *UND* 00000000000001e8 GLIBC_2.2.5 __cxa_finalize 0000000000000000 DF *UND* 0000000000000196 Base _ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEj 0000000000000000 DF *UND* 0000000000000079 Base _ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEPKcm 0000000000000000 DF *UND* 0000000000000056...

Hello, I update my building scripts to build LLVM 4.0 RC1 (with clang, lldb, libc++, libc++abi, lld) on CentOS 6 and I got a lot of undefined symbols during linking LLDB. I'm using clang-3.9 and this configuration: -DLLVM_TARGETS_TO_BUILD="X86" -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++