I have built the latest Alljoyn sdk (version 16.04a) on Raspbian and generated the liballjoyn.so and liballjoyn.a without any errors or issues. Scons cmd: scons OS=linux CPU=arm OE_BASE=/usr BINDINGS=cpp BR=on BT=off ICE=off WS=off SERVICES="about" CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf-
So in my program, which is a really simple one and just has several lines to create a busattachment.
When I started debugging, it threw a "Segmentation Fault" in a STL class.
I ran Valgrind to see what actually the problem is, and the result is something about "invalid read size of 4".
Any ideas? Did I miss anything during the building process? Or do I need to do anything with my codes?
Thanks a lot!
this is really a silly one... it ends up with I did not initialize Alljoyn correctly: I missed the AllJoynInit() method.
Related
I am trying to compile a code with crayftn.
I get an error message
/opt/cray/pe/cce/10.0.1/binutils/x86_64/x86_64-pc-linux-gnu/bin/ld: failed to convert GOTPCREL relocation; relink with --no-relax
So it wants the flag --no-relax? OK, I can do that. So I re-link with that flag, and then it tells me
ftn -O3 --no-relax -dynamic -h pic -h omp -o stream_cray stream_mpi.o mysecond.o
ftn-2115 crayftn: ERROR in command line
"-no-relax" is an invalid command-line option.
So it asks for "--no-relax", but then it doesn't understand it. Anyone know of a way out of this conundrum? Or another way of solving the root problem in the first place?
I found this link:
https://bb.cgd.ucar.edu/cesm/threads/failed-to-convert-gotpcrel-relocation-relink-with-no-relax.4494/
PROBLEM:
Hi, I get the following error message for CLM5.0 compilation with
Intel compilers, during the final cesm bld ..ld: failed to convert GOTPCREL relocation; relink with --no-relax
SOLUTION:
Hi, Seems like found a solution to fix the compilation ...Adding of
"-Wl,--no-relax" in LDFLAGS does not solve this problem, but
"-mcmodel medium" in FFLAGS fixes this issue, after searching for
"Relocation truncated to fit" in google search engine, it comes up
with this link which was helpful to solve the issue
"https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/268394"
Best Regards,Prabhakar
See also:
https://community.intel.com/t5/Intel-Fortran-Compiler/relocation-truncated-to-fit/td-p/1146616
This looks like mixing compilers and libraries from different systems
mixed up, either 32bit vs. 64bit or installations for ifort and
mpiifort based on different glibc or something similar.
I'm still curious about your "development environment":
Q: Have you been able to successfully compile, link and run ANY
program with your crayftn? Q: What version of crayftn? 10.0.1? Q: What
platform? Where is x86_64-pc-linux coming from? Just curious...
I am using vim for c++ programming. I have bound the compile command to ctrl+c in vim and I run it in another tmux pane by running ./main.out. My problem is that when my c++ program gives me segmentation fault error, I don't know which line has caused the problem. But when I compiled and ran the program in vscode, it showed me the line that caused the error.
I'm seeking for a way to find out the lines that cause runtime errors like segmentation fault error while running the program's binary file in console.
This is an example output when I do ./main.out:
[1] 24656 segmentation fault (core dumped) ./main.out
When compiling the program, add the -g compiler flag, or even better -ggdb3, which will give you a much prettier output, by adding debugging symbols to the executable. Also, make sure that you compile with the -O0 optimization level.
To actually debug the program, run gdb ./main.out to start the program in a debugging session. If you then run r, gdb will start executing the program, and then stop at the line that gives the segfault.
To figure out how you got to that point, run bt while in the debugging session, and you will get a backtrace, which will show you all the function calls that were made to get to the line of code that crashed.
You can of course do a lot more than this (and you will probably need to, since locating the source of an error is often only the first step). You can use p to print the values of variables, set watchpoints, and many more things. For a while now, gdb even ships with a full fledged python interpreter, so you can even write a python script for your custom debugging needs.
Learning how to use gdb can seem overwhelming at the start, but persevere, and I guarantee the effort will pay off big time :)
Ditto on Adin
Also your code can crash due to a call in which the parameter/s are acceptable but cause the proverbial out of range protection fault from some library somewhere if you don't have those debug versions. If an assembly routine is used inside there, they can do some strange things.
So don't be afraid to add temporary code to help like finding a single call that crashes when 1,000,000 other calls to the same did not.
Is why I like to use a lot of generated randoms if possible to test when you got it fixed.
I am trying to run the autoecho program that uses boost::asio and boost::fiber. I am using the following:
Ubuntu 16
cmake 3.9.1
boost 1_65_0
That program depends on a local copy of round_robin.hpp, yield.hpp and detail/yield.hpp. I have downloaded all of those and the program builds successfully. When I run the code, I get a segmentation fault at the line in main that does:
io_svc->run();
Does anyone know if I am doing something wrong, or if the code has an error in it?
I received an email from Oliver Kowalke #boost:
unfortunately, some fixes did not permission to merged into 1.65 (no permission because too late) - you could use branch develop (github) or you need to wait till 1.66is released.
So, until boost 1.66 is released, this code will not work unless you want to use the develop branch.
I am trying to compile OpenCL kernels on OS X. Everything is ok when there are just a few lines. However, after the code grows over 1.5k lines, clGetProgramBuildInfo with CL_PROGRAM_BUILD_LOG flag returned "Compile Server Error." every time. I googled but found nothing about it. Could anyone help me?
You can learn the meaning of OpenCL error codes by searching in cl.h. In this case, -11 is just what you'd expect, CL_BUILD_PROGRAM_FAILURE. It's certainly curious that the build log is empty. Two questions:
1.) What is the return value from clGetProgramBuildInfo?
2.) What platform are you on? If you are using Apple's OpenCL implementation, you could try setting CL_LOG_ERRORS=stdout in your environment. For example, from Terminal:
$ CL_LOG_ERRORS=stdout ./myprog
It's also pretty easy to set this in Xcode (Edit Scheme -> Arguments -> Environment Variables).
Please find the original answer by #James
This unhelpful error message indicates that there is bug in Apple's compiler. You can inform them of such bugs by using the Apple Bug Reporting System.
I have a C++ project that was built and runs in Visual Studio.
When I try to run it in unix, it gives me
Abort (Core Dumped)
I am using the g++ version 3.2.2
How do i Fix this program ? It needs to run in linux.
First step is to learn how to use gdb or any of the other excellent debuggers for Linux.
That should be able to tell you exactly which source line caused the problem. Then work back from there.
Other than that, we can't really help without seeing that source code. Psychic debugging, whilst useful, is not a highly developed field of endeavour :-)
#All
Thanks a lot for your responses.I really appreciate it
My program worked with g++ 4.2.3. It was aborting with g++ 3.2.2.
The code that gave me the correct output in visual studio was
foundOpen = inStr.find("(");
foundClose = inStr.find(")");
string inGate;
inGate = inStr.substr(++foundOpen,foundClose-foundOpen);
But using g++, I had to make a small change to the substr function.
foundOpen = inStr.find("(");
foundClose = inStr.find(")");
string inGate;
inGate = inStr.substr(++foundOpen,foundClose-foundOpen-1);
I am also a beginner to using linux and don't know how to use gdb. Are there any good tutorials to learn gdb?
I'll take a flying guess: your program uses 'getch()' and you found the function in the library -lcurses or -lncurses and are using that library, but your program crashes as you said.
The trouble is, that function requires a certain amount of setup to work - unlike the similarly named but rather different function that is available on Windows.
Welcome to the real world - different platforms have different functions in the standard APIs; sometimes, two platforms have a function with the same name but different meanings.
Another wild guess: boolean initialization, we got bit by this one. The boolean was initialized automatically using VC++2003 but on Linux it was not (thus either true or false, flip a coin...).
Took a while to debug since in our case it did not crash and was intermittent. I wanted to slap the programmer on the head for not initializing his variable!