On Sat, Oct 15, 2011 at 9:49 PM, Chandler Carruth <chandlerc at google.com>wrote:> 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 a >> statically-initialized object. (More precisely, it's blowing up in a >> BumpPtrAllocator, which is used by a StringMap, which is in turn a member of >> a statically initialized object.) >> >> Anyone know what might have changed recently that would cause this? >> > > It would help a lot to see the actual backtrace etc. ;] >Sure thing (although I'm not sure that this will tell you all that much): #0 0x00007fff878d8fbb in __cxa_pure_virtual () #1 0x0000000100f3f166 in llvm::BumpPtrAllocator::DeallocateSlabs (this=0x1016e48a8, Slab=0x103889e00) at /Users/talin/Projects/llvm/lib/Support/Allocator.cpp:71 #2 0x0000000100f3f0b9 in llvm::BumpPtrAllocator::~BumpPtrAllocator (this=0x1016e48a8) at /Users/talin/Projects/llvm/lib/Support/Allocator.cpp:29 #3 0x0000000100f3f095 in llvm::BumpPtrAllocator::~BumpPtrAllocator (this=0x1016e48a8) at /Users/talin/Projects/llvm/lib/Support/Allocator.cpp:28 #4 0x00000001000aeb3a in llvm::StringMap<llvm::SmallVector<tart::Defn*, 4u>, llvm::BumpPtrAllocator>::~StringMap (this=0x1016e4890) at StringMap.h:406 #5 0x00000001000aeaa5 in llvm::StringMap<llvm::SmallVector<tart::Defn*, 4u>, llvm::BumpPtrAllocator>::~StringMap (this=0x1016e4890) at StringMap.h:403 #6 0x00000001000aea7c in tart::SymbolTable::~SymbolTable (this=0x1016e4888) at SymbolTable.h:34 #7 0x00000001000aea45 in tart::OrderedSymbolTable::~OrderedSymbolTable (this=0x1016e4888) at SymbolTable.h:74 #8 0x00000001000aea15 in tart::OrderedSymbolTable::~OrderedSymbolTable (this=0x1016e4888) at SymbolTable.h:74 #9 0x00000001000ae809 in tart::IterableScope::~IterableScope (this=0x1016e4880) at Scope.h:76 #10 0x00000001001e22d5 in tart::IterableScope::~IterableScope (this=0x1016e4880) at Scope.h:76 #11 0x00000001001e2267 in tart::FunctionDefn::~FunctionDefn (this=0x1016e4710) at FunctionDefn.h:103 #12 0x00000001000cf821 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 shows no evidence of this. So I'm not sure what's going on. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111015/ad0adc5e/attachment.html>
Interestingly, I also get a similar error in a different executable (my unittest): pure virtual method called terminate called without an active exception 0 tartc 0x00000001010a8265 PrintStackTrace(void*) + 53 1 tartc 0x00000001010a88cc SignalHandler(int) + 364 2 libSystem.B.dylib 0x00007fff831341ba _sigtramp + 26 3 libSystem.B.dylib 0x7261742e65637365 _sigtramp + 3796906437 4 libstdc++.6.dylib 0x00007fff878da5d2 __tcf_0 + 0 5 libstdc++.6.dylib 0x00007fff878d8ae1 __cxxabiv1::__terminate(void (*)()) + 11 6 libstdc++.6.dylib 0x00007fff878d8b16 __cxxabiv1::__unexpected(void (*)()) + 0 7 libstdc++.6.dylib 0x00007fff878d8fd6 std::bad_cast::what() const + 0 8 tartc 0x000000010106ad46 llvm::BumpPtrAllocator::DeallocateSlabs(llvm::MemSlab*) + 166 9 tartc 0x000000010106ac99 llvm::BumpPtrAllocator::~BumpPtrAllocator() + 25 10 tartc 0x000000010106ac75 llvm::BumpPtrAllocator::~BumpPtrAllocator() + 21 11 tartc 0x00000001000388b6 llvm::StringMap<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 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 a >>> statically-initialized object. (More precisely, it's blowing up in a >>> BumpPtrAllocator, which is used by a StringMap, which is in turn a member of >>> a statically initialized object.) >>> >>> Anyone know what might have changed recently that would cause this? >>> >> >> It would help a lot to see the actual backtrace etc. ;] >> > > Sure thing (although I'm not sure that this will tell you all that much): > > #0 0x00007fff878d8fbb in __cxa_pure_virtual () > #1 0x0000000100f3f166 in llvm::BumpPtrAllocator::DeallocateSlabs > (this=0x1016e48a8, Slab=0x103889e00) at > /Users/talin/Projects/llvm/lib/Support/Allocator.cpp:71 > #2 0x0000000100f3f0b9 in llvm::BumpPtrAllocator::~BumpPtrAllocator > (this=0x1016e48a8) at > /Users/talin/Projects/llvm/lib/Support/Allocator.cpp:29 > #3 0x0000000100f3f095 in llvm::BumpPtrAllocator::~BumpPtrAllocator > (this=0x1016e48a8) at > /Users/talin/Projects/llvm/lib/Support/Allocator.cpp:28 > #4 0x00000001000aeb3a in llvm::StringMap<llvm::SmallVector<tart::Defn*, > 4u>, llvm::BumpPtrAllocator>::~StringMap (this=0x1016e4890) at > StringMap.h:406 > #5 0x00000001000aeaa5 in llvm::StringMap<llvm::SmallVector<tart::Defn*, > 4u>, llvm::BumpPtrAllocator>::~StringMap (this=0x1016e4890) at > StringMap.h:403 > #6 0x00000001000aea7c in tart::SymbolTable::~SymbolTable > (this=0x1016e4888) at SymbolTable.h:34 > #7 0x00000001000aea45 in tart::OrderedSymbolTable::~OrderedSymbolTable > (this=0x1016e4888) at SymbolTable.h:74 > #8 0x00000001000aea15 in tart::OrderedSymbolTable::~OrderedSymbolTable > (this=0x1016e4888) at SymbolTable.h:74 > #9 0x00000001000ae809 in tart::IterableScope::~IterableScope > (this=0x1016e4880) at Scope.h:76 > #10 0x00000001001e22d5 in tart::IterableScope::~IterableScope > (this=0x1016e4880) at Scope.h:76 > #11 0x00000001001e2267 in tart::FunctionDefn::~FunctionDefn > (this=0x1016e4710) at FunctionDefn.h:103 > #12 0x00000001000cf821 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 shows no > evidence of this. So I'm not sure what's going on. > > -- > -- Talin >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111016/353cd448/attachment.html>
Only seems to happen when I use BumpPointerAllocator in conjunction with StringMap. If I use the default malloc allocator, the problem goes away. On Sun, Oct 16, 2011 at 12:07 AM, Talin <viridia at gmail.com> wrote:> Interestingly, I also get a similar error in a different executable (my > unittest): > > pure virtual method called > terminate called without an active exception > 0 tartc 0x00000001010a8265 PrintStackTrace(void*) + 53 > 1 tartc 0x00000001010a88cc SignalHandler(int) + 364 > 2 libSystem.B.dylib 0x00007fff831341ba _sigtramp + 26 > 3 libSystem.B.dylib 0x7261742e65637365 _sigtramp + 3796906437 > 4 libstdc++.6.dylib 0x00007fff878da5d2 __tcf_0 + 0 > 5 libstdc++.6.dylib 0x00007fff878d8ae1 __cxxabiv1::__terminate(void (*)()) > + 11 > 6 libstdc++.6.dylib 0x00007fff878d8b16 __cxxabiv1::__unexpected(void > (*)()) + 0 > 7 libstdc++.6.dylib 0x00007fff878d8fd6 std::bad_cast::what() const + 0 > 8 tartc 0x000000010106ad46 > llvm::BumpPtrAllocator::DeallocateSlabs(llvm::MemSlab*) + 166 > 9 tartc 0x000000010106ac99 > llvm::BumpPtrAllocator::~BumpPtrAllocator() + 25 > 10 tartc 0x000000010106ac75 > llvm::BumpPtrAllocator::~BumpPtrAllocator() + 21 > 11 tartc 0x00000001000388b6 llvm::StringMap<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 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 a >>>> statically-initialized object. (More precisely, it's blowing up in a >>>> BumpPtrAllocator, which is used by a StringMap, which is in turn a member of >>>> a statically initialized object.) >>>> >>>> Anyone know what might have changed recently that would cause this? >>>> >>> >>> It would help a lot to see the actual backtrace etc. ;] >>> >> >> Sure thing (although I'm not sure that this will tell you all that much): >> >> #0 0x00007fff878d8fbb in __cxa_pure_virtual () >> #1 0x0000000100f3f166 in llvm::BumpPtrAllocator::DeallocateSlabs >> (this=0x1016e48a8, Slab=0x103889e00) at >> /Users/talin/Projects/llvm/lib/Support/Allocator.cpp:71 >> #2 0x0000000100f3f0b9 in llvm::BumpPtrAllocator::~BumpPtrAllocator >> (this=0x1016e48a8) at >> /Users/talin/Projects/llvm/lib/Support/Allocator.cpp:29 >> #3 0x0000000100f3f095 in llvm::BumpPtrAllocator::~BumpPtrAllocator >> (this=0x1016e48a8) at >> /Users/talin/Projects/llvm/lib/Support/Allocator.cpp:28 >> #4 0x00000001000aeb3a in llvm::StringMap<llvm::SmallVector<tart::Defn*, >> 4u>, llvm::BumpPtrAllocator>::~StringMap (this=0x1016e4890) at >> StringMap.h:406 >> #5 0x00000001000aeaa5 in llvm::StringMap<llvm::SmallVector<tart::Defn*, >> 4u>, llvm::BumpPtrAllocator>::~StringMap (this=0x1016e4890) at >> StringMap.h:403 >> #6 0x00000001000aea7c in tart::SymbolTable::~SymbolTable >> (this=0x1016e4888) at SymbolTable.h:34 >> #7 0x00000001000aea45 in tart::OrderedSymbolTable::~OrderedSymbolTable >> (this=0x1016e4888) at SymbolTable.h:74 >> #8 0x00000001000aea15 in tart::OrderedSymbolTable::~OrderedSymbolTable >> (this=0x1016e4888) at SymbolTable.h:74 >> #9 0x00000001000ae809 in tart::IterableScope::~IterableScope >> (this=0x1016e4880) at Scope.h:76 >> #10 0x00000001001e22d5 in tart::IterableScope::~IterableScope >> (this=0x1016e4880) at Scope.h:76 >> #11 0x00000001001e2267 in tart::FunctionDefn::~FunctionDefn >> (this=0x1016e4710) at FunctionDefn.h:103 >> #12 0x00000001000cf821 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 shows >> no evidence of this. So I'm not sure what's going on. >> >> -- >> -- Talin >> > > > > -- > -- Talin >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111016/e04b6598/attachment.html>