I new in llvm. I just compile google code and got this error.
Stack dump:
0. Program arguments: opt -load /home/vahid/mywork/llvm-2.8/Release/lib/DSWP.so -dswp obj.o -o out.o
1. Running pass 'Function Pass Manager' on module 'obj.o'.
2. Running pass 'Loop Pass Manager' on function '#fun'
3. Running pass '15745 Decoupled Software Pipeline' on basic block '<badref>'
./execute: line 15: 2196 Aborted (core dumped)
opt -load /home/vahid/mywork/llvm-2.8/Release/lib/DSWP.so -dswp obj.o -o out.o
for more information you can see this link: http://code.google.com/p/15745-project-dswp/source/browse/
I used llvm-2.8, clang-2.8, fedora 15
Related
I am a .NET programmer who is starting to dabble into C++. In C# I would put the root function in a try catch, this way I would catch all exceptions, save the stack trace, and this way I would know what caused the exception, significantly reducing the time spent debugging.
But in C++ some stuff(access violation, divide by zero, etc.) are not caught by try catch. How do you deal with them, how do you know which line of code caused the error?
For example let's assume we have a program that has 1 million lines of code. It's running 24/7, has no user-interaction. Once in a month it crashes because of something that is not caught by try catch. How do you find out which line of code caused the crash?
Environment: Windows 10, MSVC.
C++ is meant to be a high performance language and checks are expensive. You can't run at C++ speeds and at the same time have all sorts of checks. It is by design.
Running .Net this way is akin to running C++ in debug mode with sanitizers on. So if you want to run your application with all the information you can, turn on debug mode in your cmake build and add sanitizers, at least undefined and address sanitizers.
For Windows/MSVC it seems that address sanitizers were just added in 2021. You can check the announcement here: https://devblogs.microsoft.com/cppblog/addresssanitizer-asan-for-windows-with-msvc/
For Windows/mingw or Linux/* you can use Gcc and Clang's builtin sanitizers that have largely the same usage/syntax.
To set your build to debug mode:
cd <builddir>
cmake -DCMAKE_BUILD_TYPE=debug <sourcedir>
To enable sanitizers, add this to your compiler command line: -fsanitize=address,undefined
One way to do that is to add it to your cmake build so altogether it becomes:
cmake -DCMAKE_BUILD_TYPE=debug \
-DCMAKE_CXX_FLAGS_DEBUG_INIT="-fsanitize=address,undefined" \
<sourcedir>
Then run your application binary normally as you do. When an issue is found a meaningful message will be printed along with a very informative stack trace.
Alternatively you can set so the sanitizer breaks inside the debugger (gdb) so you can inspect it live but that only works with the undefined sanitizer. To do so, replace
-fsanitize=address,undefined
with
-fsanitize-undefined-trap-on-error -fsanitize-trap=undefined -fsanitize=address
For example, this code has a clear problem:
void doit( int* p ) {
*p = 10;
}
int main() {
int* ptr = nullptr;
doit(ptr);
}
Compile it in the optimized way and you get:
$ g++ -O3 test.cpp -o test
$ ./test
Segmentation fault (core dumped)
Not very informative. You can try to run it inside the debugger but no symbols are there to see.
$ g++ -O3 test.cpp -o test
$ gdb ./test
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2
...
Reading symbols from ./test...
(No debugging symbols found in ./test)
(gdb) r
Starting program: /tmp/test
Program received signal SIGSEGV, Segmentation fault.
0x0000555555555044 in main ()
(gdb)
That's useless so we can turn on debug symbols with
$ g++ -g3 test.cpp -o test
$ gdb ./test
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
...
Reading symbols from ./test...
(gdb) r
Starting program: /tmp/test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
test.cpp:4:5: runtime error: store to null pointer of type 'int'
Program received signal SIGSEGV, Segmentation fault.
0x0000555555555259 in doit (p=0x0) at test.cpp:4
4 *p = 10;
Then you can inspect inside:
(gdb) p p
$1 = (int *) 0x0
Now, turn on sanitizers to get even more messages without the debugger:
$ g++ -O0 -g3 test.cpp -fsanitize=address,undefined -o test
$ ./test
test.cpp:4:5: runtime error: store to null pointer of type 'int'
AddressSanitizer:DEADLYSIGNAL
=================================================================
==931717==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x563b7b66c259 bp 0x7fffd167c240 sp 0x7fffd167c230 T0)
==931717==The signal is caused by a WRITE memory access.
==931717==Hint: address points to the zero page.
#0 0x563b7b66c258 in doit(int*) /tmp/test.cpp:4
#1 0x563b7b66c281 in main /tmp/test.cpp:9
#2 0x7f36164a9082 in __libc_start_main ../csu/libc-start.c:308
#3 0x563b7b66c12d in _start (/tmp/test+0x112d)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /tmp/test.cpp:4 in doit(int*)
==931717==ABORTING
That is much better!
I've been trying to locate where a segmentation fault is in a program using LLDB. I've been going to the Ubuntu shell on repl.it and compiling my code using clang++-7 -pthread -std=c++17 -o main main.cpp -g and the program compiles succesfully. Next, I run lldb main and everything's fine but as soon as I type run I get error: process launch failed: 'A' packet returned an error: 8. I've checked the docs and looked up the error but I can't seem to find anything. Thanks for any sort of help!
The full log:
~/Project$ clang++-7 -pthread -std=c++17 -o main main.cpp -g
~/Project$ lldb main
(lldb) target create "main"
Current executable set to 'main' (x86_64).
(lldb) run
error: process launch failed: 'A' packet returned an error: 8
In case you need the code it's on this Github: https://github.com/KingsleyDockerill/Wirth
For those using Docker, as mentioned here, they need to add --cap-add=SYS_PTRACE --security-opt seccomp=unconfined to their docker run command in order to use lldb.
See also this older answer.
I've only started getting this problem recently, and I have no idea when it started occuring/what causes it.
I have this simple test program here:
#include <iostream>
int main()
{
return 0;
}
but when I try to run it normally, it creates a stackdump.
Stack trace:
Frame Function Args
00CBC498 6101D93A (00000198, 0000EA60, 000000A4, 00CBC508)
00CBC5C8 610E2F3F (00000000, 60FC04E8, 00CBC658, 7794ABEE)
When I try to run it in GDB, however, it just plain fails to do so.
gdb: unknown target exception 0x406d1388 at 0x778edae8
Program received signal ?, Unknown signal.
0x778edae8 in RaiseException ()
from /cygdrive/c/WINDOWS/SYSTEM32/KERNELBASE.dll
(gdb) n
Single stepping until exit from function RaiseException,
which has no line number information.
[Thread 14880.0x11ac exited with code 1080890248]
[Thread 14880.0x3fd8 exited with code 1080890248]
[Thread 14880.0x3b24 exited with code 1080890248]
[Inferior 1 (process 14880) exited with code 010033211610]
This is how my compiler's set up:
g++ -g -std=c++1y -Wall -c main.cpp -o main.o main.cpp compiled...
g++ -g -std=c++1y -Wall -o a main.o Successfully compiled!
Any idea as to what I'm doing wrong here?
The platform I'm using is Windows, and I'm using Cygwin as my development environment.
OF NOTE: I still get the aforementioned GDB error no matter what I have in main.cpp.
ALSO OF NOTE: Here are the additional files in the a.exe executable:
I formerly needed cygboost_filesystem.dll to get boost_filesystem to work, and I need libgcc_s_sjlj-1.dll and libstdc++6 because it won't work without them.
Update gdb to the 7.11.1-1 experimental release version.
Details of GDB bug
I've been trying to compile and run LULESH benchmark
https://codesign.llnl.gov/lulesh.php
https://codesign.llnl.gov/lulesh/lulesh2.0.3.tgz
with gprof but I always get a segmentation fault. I updated these instructions in the Makefile:
CXXFLAGS = -g -pg -O3 -I. -Wall
LDFLAGS = -g -pg -O3
[andrestoga#n01 lulesh2.0.3]$ mpirun -np 8 ./lulesh2.0 -s 16 -p -i 10
--------------------------------------------------------------------------
mpirun noticed that process rank 2 with PID 30557 on node n01 exited on signal 11 (Segmentation fault).
--------------------------------------------------------------------------
In the webpage of gprof says the following:
If you are running the program on a system which supports shared
libraries you may run into problems with the profiling support code in
a shared library being called before that library has been fully
initialised. This is usually detected by the program encountering a
segmentation fault as soon as it is run. The solution is to link
against a static version of the library containing the profiling
support code, which for gcc users can be done via the -static' or
-static-libgcc' command line option. For example:
gcc -g -pg -static-libgcc myprog.c utils.c -o myprog
I added the -static command line option and I also got segmentation fault.
I found a pdf where they profiled LULESH by updating the Makefile by adding the command line option -pg. Although they didn't say the changes they made.
http://periscope.in.tum.de/releases/latest/pdf/PTF_Best_Practices_Guide.pdf
Page 11
Could someone help me out please?
Best,
Make sure all libraries are loaded:
openmpi (which you have done already)
gcc
You can try with parameters that will allow you to identify if the problem is your machine in terms of resources. if the machine does not support such number of processes see how many processes (MPI or not MPI) it supports by looking at the architecture topology. This will allow you to identify what is the correct amount of jobs/processes you can launch into the system.
Very quick run:
mpirun -np 1 ./lulesh2.0 -s 1 -p -i 1
Running problem size 1^3 per domain until completion
Num processors: 1
Num threads: 2
Total number of elements: 1
To run other sizes, use -s <integer>.
To run a fixed number of iterations, use -i <integer>.
To run a more or less balanced region set, use -b <integer>.
To change the relative costs of regions, use -c <integer>.
To print out progress, use -p
To write an output file for VisIt, use -v
See help (-h) for more options
cycle = 1, time = 1.000000e-02, dt=1.000000e-02
Run completed:
Problem size = 1
MPI tasks = 1
Iteration count = 1
Final Origin Energy = 4.333329e+02
Testing Plane 0 of Energy Array on rank 0:
MaxAbsDiff = 0.000000e+00
TotalAbsDiff = 0.000000e+00
MaxRelDiff = 0.000000e+00
Elapsed time = 0.00 (s)
Grind time (us/z/c) = 518 (per dom) ( 518 overall)
FOM = 1.9305019 (z/s)
I have written a websocket++ server on Ubuntu 13.10 and am trying to execute it on Linux Mint 16.
I have installed all dependencies, and the first line under main is a cout which never fires.
This is the compile command:
g++ -o Dgn Dgn.cpp ed25519-donna-master/ed25519.o
-Og -std=c++0x -I ~/Dgn -D_WEBSOCKETPP_CPP11_STL_ -D_WEBSOCKETPP_NO_CPP11_REGEX_
-lboost_regex -lboost_system -L/usr/lib -lssl -lcrypto -pthread -lpqxx
-lboost_thread -ljson_spirit -lgmp -lgmpxx
If I execute with sudo to use restricted ports, it fails immediately without error returning to the command line.
If I execute without sudo, is prints Segmentation Fault and fails immediately to the command line.
The directories in ~/Dgn are present on the new system.
I did a quick, simple test and checked to see if a basic websocket++ example could compile and execute normally, and it was successful.
Both systems are 64-bit. The only difference are the distros, but Linux Mint 16 is based upon Ubuntu 13.10, and all commands to setup were identical.
How can this be compiled so that it can execute on another system?
As a further test, I compiled it on the new system, and it works.
Is it not possible to compile on one system and run on another?
GDB
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7de58da in ?? () from /lib64/ld-linux-x86-64.so.2
The fact that cout line never fires (I assume it has << std::endl) means that the crash happens in a static object constructor. The most straightforward way to debug is to allow core dump (see man limits) and inspect the dump with gdb. So far that's all I can think of. More details will help.