I refer the link which says that if your device has compute capability greater than 2.0 then you can use printf() function in the CUDA kernel. When I tried the same I get the error "calling a host function("printf") from a global function("mat_mul") is not allowed", but when I run same code on eclipse nsight I get the expected output and printf() function get executed. Why such different behaviour for nsight?
The error you refer to:
"calling a host function("printf") from a global function("mat_mul") is not allowed"
arises from compiling the code, not running the code.
So the difference lies in how your are compiling from "nvcc in terminal" vs. how it is set up to compile in nsight.
If you compile in the terminal with the additional architecture switch:
nvcc -arch=sm_20 ...
the error should go away.
Related
I have C++ program that uses boost (Logger mainly). This programs compiles and runs well on Windows and Ubuntu. However, when I try to port it to Linux Yocto on an embedded system (Intel Atom processor), I got illegal instructions error at runtime.
The program itself is built on Ubuntu PC with Intel-i5.
I debugged the issue and it was some AVX instructions from another library (OpenCV). I disabled all AVX and the problem solved but another problem occurred.
It now tells me that (after reading the core dumb using gdb):
Program terminated with signal SIGILL, Illegal instruction.
0x00007fe1aed03ade in boost::gregorian::date::date(boost::gregorian::greg_year,
boost::gregorian::greg_month, boost::gregorian::greg_day) ()
I did not use boost::gregorian::date explicitly
Is it possible that boost::gregorian::date use some optimized insruction?! like SSE or AVX? (seems non-logical)
Any clue about the issue?
P.S. the error occurs at run-time before anything else. Even a cout at the first line of the main function is not executed before I got the error. So, I suspect some static constructor inside boost causes the problem since there is no static constructor at my code.
Edit:
All librires and the program itself are compiled with -march=bonnell -mno-avx -O2
I'm trying to run the example "Scale_Space_Surface_Reconstruction_3" from CGAL library on CodeBlocks IDE on Ubuntu platform, as it would be nice
to have the IDE support for code completion and a more automatic configuration process.
I managed to successfully execute it by compiling it with cmake on the terminal window.
However, on CodeBlocks, after creating a new project and copying the code from the example, I get the following error:
/usr/local/include/CGAL/Scale_Space_Reconstruction_3/Scale_Space_Surface_Reconstruction_Impl_3.h:165:23: error: variable or field 'pca' declared void
Approximation pca( _nn[i]);
By looking inside the code, I found out that this is due to an undefined Macro CGAL_EIGEN3_ENABLED. As my experiment shows, if I define the macro at
pre-processing time, I do not get the same error. That is because, by defining the macro, the type definition Default::Get< wA,void>::type, becomes
Default::Get< wA, Weighted_PCA_approximation_3<Gt>>::type, and the compiler does not complain any more.
Unfortunately, as a deserved prize for messing with things I do not really understand, I get a segmentation fault at runtime.
How should I change the compiler options of codeBlocks to make the compilation succeed, and the executable run successfully?
I have the following include paths:
/usr/local/lib/CGAL/ /usr/local/include /usr/include /usr/include/eigen3.
I also included the following libraries:
libCGAL.so, libCGAL_Core.so, libCGAL_ImageIO.so, libgmp.so, libmpfr.so, libtbb.so, libtbbmalloc.so, libtbbmalloc_proxy.so
I am working on implementing a user level thread library in C++ using setcontext(), makecontext(), getcontext(), and swapcontext() on a Linux system.
I am using a wrapper function to wrap the function the user wants to run as a thread. For example, the user calls newthread(funcPtr), and within the thread library funcPtr is passed to a wrapper function that runs it.
The error occurs differently depending on whether or not I initiate an unused string within the function. If I include the line string s = "a"; the program will run to completion, but gdb reveals that context is switching to somewhere within the string library. Without this line, the program segfaults after leaving the function wrapper.
The gdb output shows the corruption of the parameters to function().
I ran valgrind but did not see anything particularly out of the ordinary in the output, just many "Invalid read of size 4" and "Invalid write of size 4" warnings, usually within the C++ standard map.
You could try also AddressSanitizer for debugging. It can detect stack buffer overflows. Here's how to use it on Linux:
At least gcc 4.8 is needed for AddressSanitizer and libasan must be installed (e.g. on Fedora yum install libasan as root). Compile and link with -g -fsanitize=address and run the generated executable. AddressSanitizer stops and emits information if it detects the first error, no long log files have to be analyzed. Solve the reported problem, compile and run again until AddressSanitizer doesn't stop the program anymore. Unfortunately there might be false positives because you use swapcontext in your program, but it's worth a try. Instrumentation can be turned off for a specific function by adding the attribute no_sanitize_address: extern int func(void) __attribute__((no_sanitize_address));
I recently started using CodeBlocks and began encountering odd runtime errors which I have traced back to printing strings using cout <<. For example, even the following..
#include <string>
#include <iostream>
int main()
{
std::string str;
str = "Hi!";
std::cout << str << std::endl;
return 0;
}
results in an error. It will compile fine (using Borland) but when I run it I get a pop up window saying 'test.exe has stopped working' and in the console I get the message:
Process returned -1073741819 (0xC0000005) execution time : 1.526 s
Press any key to continue.
It compiles and runs fine in MS Visual C++ and with G++ in Ubuntu.. any thoughts would be greatly appreciated!
Cheers,
Weatherwax
My one-off comment ended up helping solve the problem so here it is packaged up as an answer for future users:
This guy had a similar issue and it ended up being a linker issue which he
fixed. The fix is the last post in the thread, although reading the
whole thread could be useful for you.
Long Story short: Borland compiler is a bit dated and annoying to use. Ended up being a linker issue within borland. Better off using a different compiler like GCC/G++ or Visual Studio compiler.
This answer is here to elaborate on the root cause of the issue.
The reason for your crashing program is because the wrong runtime library is being linked. Specifically, your example is compiled as a single threaded object file(the default) but the linking step is using the multithreaded cw32mt.lib runtime -- the "mt" suffix at the end means multithreaded.
The solution is to make sure the runtime your program is compiled to use matches with the runtime you're linking against. A few ways to do this.
Important bcc32 compile switches:
-tW Windows GUI program. WinMain() is expected
-tWC Windows Console program. main() is expected. default.
-tWR Use dynamically linked runtime. Absence implies static runtime linkage.
-tWM Use multithreaded runtime. Absence implies single thread.
Compiling your example program as single threaded like this works:
bcc32 -oexample.obj -c example.cpp
ilink32 -ap example.obj c0x32, example.exe,, cw32.lib import32.lib,,
or you can compile it as multithreaded like this(note the -tWM switch matching up with cw32mt.lib):
bcc32 -tWM -oexample.obj -c example.cpp
ilink32 -ap example.obj c0x32, example.exe,, cw32mt.lib import32.lib,,
A third approach that is easier and less error prone is to not call the linker yourself. Instead, let the compiler drive the linker indirectly(similar to gcc):
bcc32 -tWM -oexample.obj -c example.cpp
bcc32 -tWM example.obj -eexample.exe
For your simple example, it can even be shortened to:
bcc32 -eexample.exe example.cpp
Lastly, you can pass the -tW switch multiple times. For example, this command compiles your example as a console program with multithread support and dynamic runtime linkage:
bcc32 -tWM -tWR -tWC -eexample.exe example.cpp
The produced example.exe executable is much smaller and its import table has an entry for CC3250MT.DLL confirming that the borland runtime is dynamically linked.
We should not assume that a non-functioning program is caused by nonconformity to the standard or a bug in the tool we're using without first investigating user error as a potential cause (even though in this case it's tempting to do so). In the OP's case, the code::block IDE didn't have the right commands setup for the toolchain being used.
I am trying to compile a c++ program in Linux, using the command in the shell
$ g++ -Wall *.cpp -o prog
and for some reason it keeps on giving me a weird error:
g++: Internal error: Bus error (program cc1plus) Please submit a full
bug report. See for
instructions.
I searched the net for this bus error, and it says that it has to do with something about accessing illegal memory.
Can someone maybe clarify things a bit more for me?
This error message is telling you that there's a bug in the g++ compiler itself.
Try to narrow it down by removing bits and pieces of your source file until the problem goes away. You're not trying to fix your program, you're just trying to find the part that is breaking the compiler. Once you've found it, you can either give a better bug description or you can change your code to work around it.
Or just download the latest version of the g++ compiler and hope that it's already fixed.
Your problem is not in your code, is the compiler (g++) that is crashing and producing that Bus Error, it's possible you have an outdated version of such compiler and need to update, or you're lucky and found a real bug in g++.
I would try compiling each source file separately, to check what part of the source code triggers the error.