I have included helper_cuda.h and I am using the checkCudaErrors macro on every CUDA call in my code. I have forced an error through the following code:
checkCudaErrors(cudaMalloc(&GPUCameraData, sizeof(float) /*<-- Should be HCameraData */ ));
checkCudaErrors(cudaMemcpy(GPUCameraData, CPUCameraData, sizeof(HCameraData)
, cudaMemcpyHostToDevice));
The application simply exits with error code 1, as it should, but no information is printed. If I break on the first line and step into the second line, I see that _cudaGetErrorEnum() in helper_cuda.h does return "cudaErrorInvalidValue", but no information is printed in the output.
The development environment I use is Visual Studio 2013 and I have tested this both in Debug and Release mode.
Note: I have the same issue with OpenGL and glGetError. It seems as if any fprintf(stderr, ...); calls from code that is not directly inside my own file structure will not print anything.
The reason might be that you are creating some other type of application than default C++ application(regrading CUDA and OpenGL in your case) i.e. are you compiling this code to a library to be used in another project which is not c++, or some kind of linking issues(which type of project do you have...need information!). I had the same problem when i compiled cuda code to Matlab-Mex file which would print with the command "mexPrintf" not "fprintf" used inside "checkCudaErrors". You might test changing the print command inside helper_cuda.h from fprintf to a command which DOES print info incase you call it from your program.
Related
I am running gdb 10.1.90.20210103-git and gcc/g++ 10.2.1 20210110 on x86-64 Debian 11. My IDE is Codelite, which uses the manual rather than the machine interface to gdb, and enables me to type commands directly to gdb, and see the response (potentially copying the response to the clipboard). This when the inferior is paused after hitting a breakpoiunt, via the gdb console, which is in Codelite's Debugger > Output pane.
I was able to use the instructions at: https://sourceware.org/gdb/current/onlinedocs/gdb#Compiling-and-Injecting-Code "Compiling and injecting code in GDB" to compile simple C code and make it run in the environment of the halted inferior. For instance: compile code blah++; increments a local variable int in the inferior, which I can see via the Locals or Watch panes.
The compile file command worked fine as long as I specified the absolute path of the source file.
I was unable to see console output (to the inferior's or gdb's console) for a simple printf() statement: `printf("xxx");' because the code would not compile if there was such a line
Despite using set debug compile and set debug compile-cplus-types and checking these are set with the show versions of these, I get no error messages or acknowledgements regarding whatever I try to compile.
The blah variable is an integer, which is accessible through C code and so gcc. The ability to increment this was the only indication that my code had compiled and run.
I could not get any responses to set/show compile gcc so I am presumably compiling with gcc. I did give the command set compile gcc /usr/bin/x86_64-linux-gnu-cpp-10, but there was still no response from show compile gcc or any change in the C-only behaviour.
I could not compile the file if it contained a C++ line which incremented a data member of a class object in an vector of such objects. Nor could I compile my code if it contained C++ code such as: #include <fstream> and/or std::fstream oFile;.
The gdb documentation mentioned above is general, but does have C examples.
Is it possible to compile C++ code under gdb, injecting it into the environment of the paused inferior, with any version of gdb and gcc?
I am keen to use this C++ code injection facility, if it exists, for dumping the contents of large, complex, data structures to files and and to modify some elements of same to aid debugging.
Summary: GDB's C++ compilation and injection system does not work for me, and it is reported to be buggy or non-functional. I only tested this compile command with single lines of C code, but it worked fine for these. I was able to run my function, which writes a text dump file containing the values of a vector of class objects' data members, while the inferior was paused after a breakpoint, by including it in a source file and calling it with GDB's print or call commands, giving it the required input argument of the name of the vector to dump.
I haven't tried using GDB on its own, but at present I have no reason to believe that Codelite is interfering with my ability to communicate with GDB via Codelite's "Debugger > Output" console.
I wrote to the GDB Developer list and received what I assume is a well informed reply. I was told that in my respondent's experience "the C++ plugin isn't very functional. It seems to have some bugs and crash pretty frequently as well. Also, it seems like nobody is actively working on it." This is consistent with my experience to date.
Perhaps later versions of GDB would work better. However, there has been minimal change to the library https://github.com/gcc-mirror/gcc/commits/master/libcc1/libcp1.cc since 2017, and I could find no indication of new work on C++ compilation and injection in https://www.sourceware.org/gdb/news/ since the announcement of its introduction:
GDB 8.3.1 was released on 2019-09-20, with: "Experimental support for compilation and injection of C++ source code into the inferior (requires GCC 7.1 or higher, built with libcp1.so)."
It is possible that my problem is related to not having this library. I do have the C equivalent: /usr/lib/x86_64-linux-gnu/libcc1.so.o. I could find no such library in a Debian package. It is possible I could get this going by compiling the latest GCC/G++ and GDB, but that is pretty daunting, involving installing later standard libraries than my current Debian installation has, while making those and the newer G++ and GDB available for Codelite sessions, but not interfering with other software on machine which needs the older compilation system.
The respondent suggested that instead of compiling and injecting fresh code in the middle of a debugging session, I could write it as a library, and run it by using the compile command, on a purely C piece of code which would call it. However, for my purposes, the function needs to be passed one or more C++ constructs, and any code which called a C++ function would be C++ code and so, presumably, not be compiled by GDB.
For my immediate purpose of doing text dumps of large vectors of class objects' data members, I was able to succeed by writing such a function in an existing source file, which also contains the functions I am debugging. Then I could call it with GDB's print or call commands. I imagine this would work if the debugging function was in any other linked source file, or in a linked library. (Perhaps there is a way of writing such a library, compiling and linking it while the inferior is halted.)
I was able to run this, from a debugging session in which the inferior was halted somewhere, with either the print or call command followed by the name of the function, with the name of the vector in brackets. There must be no semicolon. I found the print command better, since GDB would report the return value, which was "void". My function used C++ constructs such as "<<" to write to the text file.
A call within my dump function of the C function system("pwd") resulted in the current directory being output on the inferior's terminal window. Likewise: print system("pwd"). print system("mc") dutifully ran Midnight Commander in the inferior's terminal window.
I altered the function to return a string, which GDB reported in the GDB "Debugger > Output" console. I added a line: std::cout << "xyz"; - but nothing appeared on either the inferior's terminal window or in the GDB console.
My attempts to use the compile command to call my dump function in exactly the same way produced no results, with or without a trailing semicolon.
I found thatprint and call work with C and C++ code while `compile" only works with C code.
I tried print vvv[6].mmm for data members which were integers, floats, and strings and GDB returned their values correctly. Adding a ++ at the end caused it to return the original integer value, but the value itself was incremented.
When I tried print with a compound line of code, with a semicolon between the two logical lines, with and without one at the end, there was no response.
The GDB Developers list is not the place for support requests, but I did not know a better way to find out about the status of this facility.
I have compiled a mex file using MATLAB. I am having trouble since every time I try to run the code, MATLAB crushes.
I have tried using feval() function with a mexhost in order to separate the processes and debug, following this guide. When I am executing using feval(mh,'functionName',input), all I am getting is:
Invalid C++ MEX-file 'test_c'
However, when I am executing using feval(mh,functionName,input) I am getting an nrhs of size 0.
I have followed throw with this guide and used the DependancyWalker utility to get the following result:
A lot of the DLLs are missing. Even the basic LIBMEX.DLL can't be found. Am I doing something wrong here? How do I debug?
Probably some of MATLAB's folders aren't in your system path variable (%PATH% on Windows).
I am using an old Fortran code and I have running it using g77-3.3 in an old OS. Since this version of the compiler no longer comes with most Linux distributions I tried using gfortran (4.9.2), and I am facing this small problem.
This codes uses temporary files. It writes to this file and then at a certain point it changes the status of the file to scratch, like in the following example:
PROGRAM testopenfile
IMPLICIT NONE
WRITE(8,*)'fdsasfd'
OPEN(8,STATUS='SCRATCH')
CLOSE(8)
END PROGRAM
This piece of code works with the g77 compiler, but when I run it with gfortran I get the message:
At line 4 of file testopenfile.f (unit = 8, file = 'fort.8')
Fortran runtime error: Cannot change STATUS paramter in OPEN statement.
Has this way of setting temporary files changed in gfortran? Am I doing something wrong? Could this be a bug in this version of gfortran?
If you write to unit 8 before opening the file, you are in fact writing to a file called fort.8, see here. Apparently, this file is still open at unit 8 when you try to attach the scratch file to it.
You can solve this by opening the scratch file before writing to the unit:
PROGRAM testopenfile
IMPLICIT NONE
OPEN(8,STATUS='SCRATCH')
WRITE(8,*)'fdsasfd'
CLOSE(8)
END PROGRAM
or by using a different unit.
Chapter C.6.3 ("OPEN statement (9.5.6)") in the Fortran 2008 Standard treats this case and has an example which looks just like your code. It states that this "example is invalid because it attempts to change the value of the STATUS= specifier."
If you want to delete the file on closing, you can also do
PROGRAM testopenfile
IMPLICIT NONE
WRITE(8,*)'fdsasfd'
CLOSE(8,status='DELETE')
END PROGRAM
I have recently started coding with C++ and I have come across a little source of error which I think requires knowledge about computers that I don't have.
When I write a simple code (in Visual Studio Express 2013), let's say a "Hello World!" example, I Build and Start Without Debugging successfuly.
Then, when I edit my code to print the sum of two numbers for example, I get an error when I try to Build. I get this error:
Error 1 error LNK1168: cannot open c:\users\name\documents\visual
studio 2013\Projects\ConsoleApplication4\Debug\ConsoleApplication4.exe
for writing
But if I wait for a bit and then re-attempt to Build, everything is fine.
I have also noticed this when I use g++ in the standard cmd module; if I try to complile a code under the same name (for the .exe file) I get an Access Denied error, but if I wait a bit I am allowed to do it.
My instincts tell me that the computer still has the .exe file running for a bit after I execute it, and it is not allowing me to overwrite it.
It's because the process is still running and therefore the file is in use and write-locked. It takes Windows a few tempo beats to clean everything up after you've terminated.
I already asked this question in the nvidia forum but never got an answer link.
Every time I try to step into a kernel I get a similar error message to this:
__device_stub__Z10bitreversePj (__par0=0x110000) at
/tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c:10
10 /tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c: No such file or directory.
in /tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c
I tried to follow the instructions of the cuda-gdb walkthrough by the error stays.
Has somebody a tip what could cause this behaviour?
The "device stub" for bitreverse(unsigned int*) (whatever that is) was compiled with debug info, and it was located in /tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c (which was likely machine-generated).
The "No such file" error is telling you that that file is not (or no longer) present on your system, but this is not an error; GDB just can't show you the source.
This should not prevent you from stepping further, or from setting breakpoints in other functions and continuing.
I was able to solve this problem by using -keep flag on the nvcc compiler. This specifies that the compiler should keep all intermediate files created during the compilation, including the stub.c files created by cudafe that are needed for the debugger to step through kernel functions. Otherwise the intermediate files seem to get deleted by default at the end of the compilation and the debugger will not be able to find them. You can specify a directory for the intermediate files as well, and will need to point your debugger (cuda-gdb, nsight, etc) to this location.
I think I had such problem once, but can't really remember what was it caused with. Do you use textures in your kernel? In that case you couldn't debug it.