I'm coding a program and at some point during execution it crashes and print this stack-trace:
pure virtual method called
terminate called without an active exception
0 prog 0x08f04a98
1 prog 0x08f05147
2 0xb7802400 __kernel_sigreturn + 0
3 libc.so.6 0xb758fbb2 abort + 386
4 libstdc++.so.6 0xb778653f __gnu_cxx::__verbose_terminate_handler() + 335
5 libstdc++.so.6 0xb7784405
6 libstdc++.so.6 0xb7784442
7 libstdc++.so.6 0xb77850f5
8 prog 0x08f2cb1f proj::raw_ostream::write(char const*, unsigned int) + 159
9 prog 0x081df8fe
10 prog 0x081d079b
11 prog 0x08e8ac02 proj::Value::~Value() + 130
12 prog 0x082749ad
13 prog 0x08e1cd62 proj::Tiny::~Tiny() + 178
14 prog 0x08e1fc86 proj::Alloca::~Alloca() + 38
15 prog 0x08e252ac proj::Alloca::~Alloca() + 44
16 prog 0x088e9bbc
17 prog 0x088e9b64
18 prog 0x08d3782e
19 prog 0x08d36a46
20 prog 0x08d34e95 proj::Medium::~Medium() + 485
21 prog 0x08d34c9c proj::Medium::~Medium() + 44
22 prog 0x08d3753c
23 prog 0x08d36da4
24 prog 0x08d350ed proj::Medium::eraseFromParent() + 109
25 prog 0x08dc780d proj::Big::dropAllReferences() + 253
26 prog 0x08e530b9 proj::Module::dropAllReferences() + 137
27 prog 0x08e52ea0 proj::Module::~Module() + 64
28 prog 0x08c602cb proj::Engine::~Engine() + 155
29 prog 0x08743e00 proj::Controller::~Controller() + 192
30 prog 0x08743d2c proj::Controller::~Controller() + 44
31 prog 0x081cdee9
32 libc.so.6 0xb75912df
33 libc.so.6 0xb759134f
34 libc.so.6 0xb7578cae __libc_start_main + 238
35 prog 0x081cc501
What is the address on the third column? I guess they are function address but are they? seems that some virtual function is being called at somepoint, how do I know what virtual function is being called?
The third column is the program counter recorded on the stack so it will be a code address.
You need to look at whether you are calling pure virtuals within your destructors; most likely proj::Value::~Value() is calling a virtual that is pure in proj::Value.
Yes, they are function addresses. If you have the corresponding core file for that dump, and you had compiled with debugging symbols, you can load the core and executable in gdb, and use the command list *<address>. It will show you the line of code corresponding to that address.
Without seeing any code, I would guess write on raw_ostream is a virtual method.
The third column is the actual memory address that is being executed on the function stack (should be equal to the fourth column, which gives you the offset from the beginning of the named function).
The function stack is shown growing up: lines shown earlier are nested deeper in the call stack. In other way: your main is near the bottom of the list
The virtual function is called from proj::Value::~Value(), which calls proj::raw_ostream::write(char const*, unsigned int), which causes the exception
Related
Ok so, im supposed to define a variable HASH_TABLE_SIZE at link time, so I would put that in my makefile.
my Makefile is as follows:
1 CC = g++
2 CFLAGS = -c -g -std=c++11 -Wall -W -Werror -pedantic -D HASH_TABLE_SIZE=10
3 LDFLAGS = -lrt
4
5 myhash : main.o hash.o hash_function.o
6 $(CC) $(LDFLAGS) main.o hash.o hash_function.o -o myhash
7
8 main.o : main.cpp hash.h
9 $(CC) $(LDFLAGS) main.cpp
10
11 hash.o : hash.cpp hash.h
12 $(CC) $(LDFLAGS) hash.cpp
13
14 hash_function.o : hash_function.cpp hash.h
15 $(CC) $(LDFLAGS) hash_function.cpp
16
17 clean :
18 rm *.o myhash
my Makefile seems correct to me, and I am putting -D HASH_TABLE_SIZE=10.
However, when I do make, I get this error:
In file included from main.cpp:3:0:
hash.h:24:27: error: 'HASH_TABLE_SIZE' was not declared in this scope
list<string> hashTable[HASH_TABLE_SIZE];
my Hash.h file is as follows:
1 /* This assignment originated at UC Riverside. The hash table size
2 should be defined at link time. Use -D HASH_TABLE_SIZE=X */
3
4 #ifndef __HASH_H
5 #define __HASH_H
6
7 #include <string>
8 #include <list>
9
10 using namespace std;
11
12 class Hash {
13
14 public:
15 Hash();
16 void remove(string word);
17 void print();
18 void processFile(string fileName);
19 bool search(string word);
20 void output(string fileName);
21 void printStats();
22
23 private:
24 list<string> hashTable[HASH_TABLE_SIZE];
25 int collisions;
26 int longestList;
27 double avgLength;
28
29 private:
30 int hf(string ins);
31 double newAvgListLen;
32
33 // put additional variables/functions below
34 // do not change anything above!
35
36 };
37
38 #endif
Why is this happening? Any help would be greatly appreciated.
The quick solution
You are not using CFLAGS in your recipes so it is having no effect.
It should work if you change lines 8 to 15 to:
8 main.o : main.cpp hash.h
9 $(CC) $(CFLAGS) main.cpp
10
11 hash.o : hash.cpp hash.h
12 $(CC) $(CFLAGS) hash.cpp
13
14 hash_function.o : hash_function.cpp hash.h
15 $(CC) $(CFLAGS) hash_function.cpp
Some extra details
-D is a compile time flag not a link time option.
CFLAGS is conventionally used to pass compile time flags to the compiler for a C program.
Normally CXXFLAGS would be used for a C++ program such as this and CXX to specify the C++ compiler. Make doesn't really mind though but it can make it easier to follow when conventions are used.
LDFLAGS is normally used for passing link time flags like -lrt so it only makes sense to use that on line 6, not in the compiling steps.
I'm trying a very simple example with LLVM/clang and seem to fail.
I try the following:
clang++ -emit-llvm -c -x c++ -o main.bc -isystem include/ main.cc
clang++ -emit-llvm -c -x c++ -o test_class.bc -isystem include/ test_class.cc
llvm-link main.bc test_class.bc -o all.bc
lli all.bc
However, 4. fails (segfaults) with:
0 libLLVM-3.3.so 0x0000003b890f9e52 llvm::sys::PrintStackTrace(_IO_FILE*) + 34
1 libLLVM-3.3.so 0x0000003b890f9cb9
2 libpthread.so.0 0x0000003b8520efa0
3 libLLVM-3.3.so 0x0000003b89982790 llvm::MachineJumpTableInfo::getEntrySize(llvm::DataLayout const&) const + 0
4 libLLVM-3.3.so 0x0000003b894bfb23
5 libLLVM-3.3.so 0x0000003b894c8dc3
6 libLLVM-3.3.so 0x0000003b8981b27f
7 libLLVM-3.3.so 0x0000003b8969d2d6 llvm::FPPassManager::runOnFunction(llvm::Function&) + 422
8 libLLVM-3.3.so 0x0000003b8969d3f6 llvm::FunctionPassManagerImpl::run(llvm::Function&) + 102
9 libLLVM-3.3.so 0x0000003b8969d4cb llvm::FunctionPassManager::run(llvm::Function&) + 91
10 libLLVM-3.3.so 0x0000003b894b3264 llvm::JIT::jitTheFunction(llvm::Function*, llvm::MutexGuard const&) + 36
11 libLLVM-3.3.so 0x0000003b894b394f llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 15
12 libLLVM-3.3.so 0x0000003b894b3b7e llvm::JIT::getPointerToFunction(llvm::Function*) + 254
13 libLLVM-3.3.so 0x0000003b894c6649
14 libLLVM-3.3.so 0x0000003b894c909c
15 libLLVM-3.3.so 0x0000003b8981b27f
16 libLLVM-3.3.so 0x0000003b8969d2d6 llvm::FPPassManager::runOnFunction(llvm::Function&) + 422
17 libLLVM-3.3.so 0x0000003b8969d3f6 llvm::FunctionPassManagerImpl::run(llvm::Function&) + 102
18 libLLVM-3.3.so 0x0000003b8969d4cb llvm::FunctionPassManager::run(llvm::Function&) + 91
19 libLLVM-3.3.so 0x0000003b894b3264 llvm::JIT::jitTheFunction(llvm::Function*, llvm::MutexGuard const&) + 36
20 libLLVM-3.3.so 0x0000003b894b394f llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 15
21 libLLVM-3.3.so 0x0000003b894b3b7e llvm::JIT::getPointerToFunction(llvm::Function*) + 254
22 lli 0x00000000004073cf main + 2527
23 libc.so.6 0x0000003b84621b75 __libc_start_main + 245
24 lli 0x000000000040a271
Stack dump:
0. Program arguments: lli all.bc
1. Running pass 'X86 Machine Code Emitter' on function '#main'
2. Running pass 'X86 Machine Code Emitter' on function '#_ZN10test_classC2ESs'
[1] 15327 segmentation fault (core dumped) lli all.bc
Do I have a fundamental missunderstanding on how this is supposed to work? My ultimate goal is to do the compilation
part using the libclang API, but for now understanding what I do wrong here would be awesome! Thanks!
I attached the source code for the example below:
include/test_class.h:
#ifndef __TEST_CLASS_H__
#define __TEST_CLASS_H__
#include <string>
#include <iostream>
struct test_class
{
test_class(std::string foo);
~test_class();
std::string foo;
};
#endif
test_class.cc:
#include <test_class.h>
test_class::test_class(std::string foo) : foo(foo)
{
std::cout << foo << std::endl;
}
test_class::~test_class(void)
{
}
main.cc:
#include <cstdlib>
#include <string>
#include <iostream>
#include <test_class.h>
int main(int argc, char** argv)
{
test_class test("foo");
return EXIT_SUCCESS;
}
In test_class you refer to std::string. I guess, calls to related functions are marked external if you have a look into the IR (eg: llvm-dis < all.bc).
If you compile to "normal" executable code, these calls are resolved by the linker.
Since you link manually with llvm-link you will have to provide IR-code for the C++ libraries, otherwise execution might fail.
I want to generate bitcode file (.bc) as it is written in documentation:
hello.c
#include <stdio.h>
int main() {
printf("hello world\n");
return 0;
}
then
% clang -O3 -emit-llvm hello.c -c -o hello.bc
and
% lli hello.bc
to run the code, but I have weird output:
lli: Attributes.cpp:367: static llvm::AttrListPtr llvm::AttrListPtr::get(llvm::LLVMContext &, ArrayRef<llvm::AttributeWithIndex>): Assertion `Attrs[i].Attrs.hasAttributes() && "Pointless attribute!"' failed.
0 lli 0x0000000000c944ff
1 lli 0x0000000000c94a79
2 libpthread.so.0 0x00007fbf12a88060
3 libc.so.6 0x00007fbf11d663e5 gsignal + 53
4 libc.so.6 0x00007fbf11d69b4b abort + 379
5 libc.so.6 0x00007fbf11d5ed8d __assert_fail + 221
6 lli 0x0000000000b8b285 llvm::AttrListPtr::get(llvm::LLVMContext&, llvm::ArrayRef<llvm::AttributeWithIndex>) + 517
7 lli 0x000000000051f14e llvm::BitcodeReader::ParseAttributeBlock() + 494
8 lli 0x00000000005249f1 llvm::BitcodeReader::ParseModule(bool) + 497
9 lli 0x0000000000526617 llvm::BitcodeReader::ParseBitcodeInto(llvm::Module*) + 359
10 lli 0x000000000052eae9 llvm::getLazyBitcodeModule(llvm::MemoryBuffer*, llvm::LLVMContext&, std::string*) + 569
11 lli 0x000000000052ee3f llvm::ParseBitcodeFile(llvm::MemoryBuffer*, llvm::LLVMContext&, std::string*) + 15
12 lli 0x00000000004ea29a llvm::ParseIR(llvm::MemoryBuffer*, llvm::SMDiagnostic&, llvm::LLVMContext&) + 170
13 lli 0x00000000004e7078 llvm::ParseIRFile(std::string const&, llvm::SMDiagnostic&, llvm::LLVMContext&) + 536
14 lli 0x00000000004e3a58 main + 312
15 libc.so.6 0x00007fbf11d5130d __libc_start_main + 237
16 lli 0x00000000004e1f49
Stack dump:
0. Program arguments: lli hello.bc
Aborted
What is the problem. Why it does not work?
That is likely a problem with your particular LLVM/Clang version. Have you compiled it from source with assertions enabled? You just need to get a newer build with that bug fixed. (See http://llvm.org/bugs/show_bug.cgi?id=15786 for a similar assertion failure report with older version.)
FWIW - that program works fine on my local SVN build (clang version 3.4 (trunk 182672)).
While trying to compile an LLVM IR, like this
llc main.ll -o main.s && g++ main.s -O3 -o main -pthread
I get the following error. The same thing compiles on my Ubuntu 10 system, but in the CentOS I get the following error. Any idea what is going on here and why LLVM is going mad? And lastly, how to solve this?
llc: /home/schism/llvm/include/llvm/ADT/IntervalMap.h:606: unsigned int llvm::IntervalMapImpl::LeafNode< <template-parameter-1-1>, <template-parameter-1-2>, <anonymous>, <template-parameter-1-4> >::insertFrom(unsigned int&, unsigned int, KeyT, KeyT, ValT) [with KeyT = llvm::SlotIndex, ValT = unsigned int, unsigned int N = 9u, Traits = llvm::IntervalMapInfo<llvm::SlotIndex>]: Assertion `!Traits::stopLess(b, a) && "Invalid interval"' failed.
0 llc 0x0000000000d5009f
1 llc 0x0000000000d50db7
2 libpthread.so.0 0x0000003cfde0ebe0
3 libc.so.6 0x0000003cfce30285 gsignal + 53
4 libc.so.6 0x0000003cfce31d30 abort + 272
5 libc.so.6 0x0000003cfce29706 __assert_fail + 246
6 llc 0x000000000093624c llvm::IntervalMapImpl::LeafNode<llvm::SlotIndex, unsigned int, 9u, llvm::IntervalMapInfo<llvm::SlotIndex> >::insertFrom(unsigned int&, unsigned int, llvm::SlotIndex, llvm::SlotIndex, unsigned int) + 716
7 llc 0x0000000000936a00
8 llc 0x0000000000929898 llvm::SplitEditor::useIntv(llvm::SlotIndex, llvm::SlotIndex) + 88
9 llc 0x000000000092f369 llvm::SplitEditor::splitRegInBlock(llvm::SplitAnalysis::BlockInfo const&, unsigned int, llvm::SlotIndex) + 1513
10 llc 0x00000000008c20ea
11 llc 0x00000000008c3c78
12 llc 0x00000000008c90d1
13 llc 0x00000000008c95ab
14 llc 0x0000000000a06c84 llvm::RegAllocBase::allocatePhysRegs() + 324
15 llc 0x00000000008c4edc
16 llc 0x0000000000880005 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 53
17 llc 0x0000000000ce4c66 llvm::FPPassManager::runOnFunction(llvm::Function&) + 646
18 llc 0x0000000000ce4cfd llvm::FPPassManager::runOnModule(llvm::Module&) + 45
19 llc 0x0000000000ce641c llvm::MPPassManager::runOnModule(llvm::Module&) + 556
20 llc 0x0000000000ce657e llvm::PassManagerImpl::run(llvm::Module&) + 174
21 llc 0x0000000000ce66dd llvm::PassManager::run(llvm::Module&) + 13
22 llc 0x00000000004d0f1b main + 5451
23 libc.so.6 0x0000003cfce1d994 __libc_start_main + 244
24 llc 0x00000000004ce8e9
Stack dump:
0. Program arguments: llc main.ll -o main.s
1. Running pass 'Function Pass Manager' on module 'main.ll'.
2. Running pass 'Greedy Register Allocator' on function '#_Z7InitSimPKcj'
Aborted
Looks like LLVM is miscompiled by your system compiler. See http://llvm.org/docs/GettingStarted.html#brokengcc for a list of known broken compilers.
The solution is simple - use other version of the compiler (gcc in your case) to compile LLVM.
There's a similar problem to this floating around here somewhere. Answer was to check the versions of gcc and llvm. Turned out one was 32 bit the other 64 bit. ymmv.
I'm trying to build a project using OpenCV with alchemy. My idea was to isolate the parts I need from OpenCV (v.2.2), compile them with alchemy g++ and link with my code statically. So here's what I do:
First I compile needed opencv sources one by one (I need core, imgproc and some others):
alc-on; for src in *.cpp ; do g++ -I../../include -DOSX -c -Wall -O3 -o ${PWD##*/}_`basename $src .cpp`.o $src ; done ; mv -v *.o ~/dev/cut/obj/
Then I try to build this simple test of Flash—OpenCV interaction and link it against all .o's I have built as above:
#include <opencv/cv.h>
#include "AS3.h"
void testCV()
{
cv::Mat a(3,3,CV_8UC1,cv::Scalar(1.0));
cv::Mat b(3,3,CV_8UC1,cv::Scalar(2.0));
cv::Mat c;
c=a+b;
}
static AS3_Val test(void* self, AS3_Val args)
{
testCV();
return 0;
}
int main()
{
AS3_Val testMethod = AS3_Function(NULL,test);
AS3_Val result = AS3_Object("test: AS3ValType",testMethod);
AS3_Release(testMethod);
AS3_LibInit(result);
return 0;
}
Next, assuming I have the source and all needed .o's in the same folder, I try to compile them as swc:
g++ -I../include -Wall -O3 -DOSX -swc test_cv.cpp *.o -o cvtest.swc
(Note: creating a library archive with 'ar rc' and 'ranlib' and linking against it has the same effect)
And at this point, I get the following error report from alchemy tools (I guess it's llvm):
Assertion failed: (TLI.isTypeLegal(VT) && "Intrinsic uses a non-legal type?"), function visitTargetIntrinsic, file /Volumes/data/dev/FlaCC/llvm-2.1/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp, line 2465.
0 llc 0x00636dfe _ZNSt8_Rb_treeIN4llvm3sys4PathES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE13insert_uniqueERKS2_ + 6078
1 llc 0x006373a2 _ZNSt8_Rb_treeIN4llvm3sys4PathES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE13insert_uniqueERKS2_ + 7522
2 libSystem.B.dylib 0x9125e05b _sigtramp + 43
3 ??? 0xffffffff 0x0 + 4294967295
4 libSystem.B.dylib 0x912eb5a5 raise + 26
5 libSystem.B.dylib 0x913016e4 abort + 93
6 libSystem.B.dylib 0x912ee20f __assert_rtn + 252
7 llc 0x003f3e2a _ZN4llvm11StoreSDNodeD1Ev + 90026
8 llc 0x003f5256 _ZN4llvm11StoreSDNodeD1Ev + 95190
9 llc 0x003f817c _ZN4llvm11StoreSDNodeD1Ev + 107260
10 llc 0x0040bc68 _ZN4llvm11StoreSDNodeD1Ev + 187880
11 llc 0x0040d3f2 _ZN4llvm11StoreSDNodeD1Ev + 193906
12 llc 0x0040f92e _ZN4llvm11StoreSDNodeD1Ev + 203438
13 llc 0x005d1926 _ZN4llvm12FunctionPassD1Ev + 20998
14 llc 0x005d1f3a _ZN4llvm12FunctionPassD1Ev + 22554
15 llc 0x005d20c5 _ZN4llvm12FunctionPassD1Ev + 22949
16 llc 0x00002e44 0x0 + 11844
17 llc 0x00001f36 0x0 + 7990
18 ??? 0x00000006 0x0 + 6
I found out that the problem comes from the file matop.o (matop.cpp from OpenCV core module), but I cannot throw it out of linking because it results in undefined sym error at runtime in flash (it cannot find cv::add, if I'm not mistaken).
Can anyone suggest any way to identify the real problem and any (even dirty hacking — style) workaround for it?
My thread on the problem and workarounds at adobe alchemy forums: http://forums.adobe.com/message/3891743#3891743
Dirty hack workaround: remove defined section from top of OpenCV2.0 core arithm.cpp between
#if CV_SSE2
...
#else
and leave only the else-section. This would work for the example above.
Other parts of OpenCV might need more mindbogglingly exquisite hacking.