Hi, I already posted asking about how to use the cuda-gdb debugger in eclipse and emulation mode, but while i don’t find a solution i want to debug somehow.
I read here and here that i can use printf in emulation mode.
I can use printf in cuda functions, but when i put the printf in the kernel i get a segmegtation fault.
So my question is, can i call printf inside a kernel?
Thank you
Thank you. I have asked to be a registered developer, but what I’m developing is just the final project of my computer science studies.
Anyway, this is a new feature and in the links it’s said that printf was the old way of developing, before even cuda-gdb.
So, why can’t i use the simple printf?
Hi,
you can use printf in emulation mode only. For release either use Nexus or cuda-gdb or just print out the values
from the host code (run the kernel, copy data to the host and print the results to see if thats what you expect)
eyal
ok, i thougth the printf wasn’t working. I had it in the first line of the kernel, but it doesn’t take effect because of the segmentation fault. When i commented the rest of the code in the kernel the text is printed.
What i wanted was moving the printf to see when the segmentation fault occurs. But i think I cannot do that while the error is a segmentation fault.
But i have the idea of remove the comments gradually to see wich part of the code is the bad one.
Thank you anyway
If you are getting a seg fault, just compile with debug symbols and run in gdb. Then get the backtrace to find exactly what line of code causes the seg fault. MUCH simpler than randomly commenting and umcommenting code.
Thats exactly what I meant - make sure the kernel still does something otherwise the optimizer will remove the code alltogether.
I find it much faster than going through the debugger - if you comment and than open lines serially you’ll find the offending code
pretty fast.
eyal
when i reach cuda code running with gdb (not cuda-gdb), it’s ok, but i cannot debug inside the kernels with it. I think it’s because it launches a lot of threads.
You can debug inside kernels, but you need to know the C++ mangled name of the kernel (or at least that is how it was in CUDA 2.1 and 2.2, I haven’t need to use it in 2.3 or 3.0beta yet). GDB will switch threads automagically. But you even really don’t even need to do that to find the segfault. Just run the code with no break points and when the segfault happens, you can use backtrace (‘bt’) to print the stack trace which will show you file, function and line number where the error occurred.
Thank you, i was using gdb through eclipse and don’t know if it has backtrace.
When i try in console gdb I got very surprised: I didn’t touch a line in the kernel, but now the kernel doesn’t rise any segmentation fault. It seems to disappear automagically on its own ¿!!?? :). I guess i’ve changed something related with the memory management.
There’s another seg fault in a delete almost at the end of the program, but that’s not a Cuda thing.
Thank you all for the advices.
My problems started when i wanted to debug from eclipse. I guess i should learn how to use gdb instead.