cudaMemcpy after error in kernel


I have a CUDA program in which I’m calling a kernel after which I’m transferring some results back to CPU memory. My host side code looks like the following:

insertionTest<<<grid, block>>>(in, n, hashTable.getPtr(), numKeysGPU.getPtr(), iterations.getPtr());



        cudaError_t res = cudaGetLastError();

	std::cout << cudaGetErrorString(res) << std::endl;


        int itersCPU[2];


	std::cout << itersCPU[0] << " " << itersCPU[1] << std::endl;

When the kernel errors out (I’m getting an “unknown error”), itersCPU seems to only have zeros. However, things work fine when there is no error in the kernel. Is this expected behaviour? I expected to get back the last value written into “iterations” before the kernel failed.

Any help is much appreciated. Thanks in advance!

Do you know where in the kernel you are crashing? Obviously if it crashes before anything is written to “iterations” you won’t be getting much in the way of output. I’ve never gotten an “unknown error” with the Runtime API, but in the Driver API (at least in my experience) getting a “CUDA_ERROR_UNKNOWN” implies your kernel didn’t manage to run (in my case because some of my kernel configuration parameters weren’t valid).

Thanks for the quick response!

The code which writes into “iterations” is the first line of the kernel. So it should have run before the kernel crashes (I know that the code writing iterations is not causing the crash.) I also just noticed that the subsequent cudaMemcpy is returning an error (which also happens to be “unknown error”). I thought cudaGetLastError supposed to clear the error state when it is called. Am I doing something else that is wrong?

It might sound crazy, but your kernel might never even execute. There are a lot of things that go on under the hood to set up a kernel call, and it’s possible that one of those could be failing. If you posted more of the code relevant to the setup for your kernel call I might be able to give you a more enlightening/accurate answer (no guarantees though)