Hello. I’m very new to CUDA programming and have been attempting to debug my first substantial code. I want to use the “-G” option to nvcc to generate a debugging binary, but always get this message when attempting to do so:
nvcc -G -g cudainput.cu
gcc: /opt/nvidia/cuda/bin/ptxvars.cu: No such file or directory
gcc: warning: ‘-x c++’ after last input file has no effect
gcc: no input files
The same errors are present whether or not i also add -deviceemu to the compiler options. I’m running the 64-bit version of openSUSE 10.3, and /opt/nvidia/cuda is the cuda installation directory. I’ve tried looking through the documentation and searching this forum for why this problem occurs, but to no avail so far. Any help will be appreciated.
I have not experienced this error yet. However, as the hardware debugger is not available, yet the -G does not get you anything. Try whether it works if you leave that out. AFAIK currently the only way to debug is “-g --deviceemu”.
It does work if -G is left out, e.g. “nvcc -g --deviceemu”, but this is insufficient to figure out what is going wrong in my code at runtime. Running the device compiled binary yields this message during the third kernel invocation (while running using an emulated device results in no such error):
error: unspecified launch failure
I was under the impression from browsing this forum that -G -g would allow me to debug while using the device, but that seems to be incorrect. This is, as I have found while reading the forums, essentially a segmentation fault, but I need to know which thread is having the problem and why. Since the code runs fine under emulation, I’m at a loss.
If anyone has run into a similar error, I would be interested in hearing about it, and how to resolve/work around it. I’m going to try a few more things with my code, then may post my problems in a separate thread (since they would be code issues instead of debug issues).
I did this, and valgrind didn’t issue any complaints. Is there any cuda function to generate a more detailed error message? For instance, which thread/block is the culprit? Or is there just a total kernel failure?
Ok. Found the problem. In another thread, someone replied that using long int is a terrible idea, something I was doing in an argument passed t. After realizing i didn’t need a long int (I was porting some old code) and replacing it with a standard int, the error disappeared.
Hehe, I think I may have expressed it a bit too strong. But there seem to be a lot of novice C programmers around, and for those I think using “long” can only cause a lot of pain.
Also it makes it hard to read the code others post, because its behaviour depends on whether they are using Windows or Linux and whether they use 32 or 64 bit code (things a lot of people forget to mention :P ).