cudaGLMapBufferObject causes exception cudaError_enum at memory location

Hello all. I have been modifying the sobel filter project from the sdk to work on short data instead of unsigned char data.
I am able to draw an image on the screen. However the fourth time that the display function executes, if I try to step over the following call:

CUDA_SAFE_CALL(cudaGLMapBufferObject((void**)&data, pbuffer));

I get the following error:

cudaError_enum at memory location

Can someone give point me to some additional information on this?

A search of the forums didn’t turn up much. I am not using any shared memory.

Thanks

The pbuffer is set up as follows.

typedef short Pixel;

glGenBuffers(1, &pbuffer);
glBindBuffer(GL_PIXEL_UNPACK_BUFFER, pbuffer);
glBufferData(GL_PIXEL_UNPACK_BUFFER, 
                sizeof(Pixel) * imWidth * imHeight, 
                pixels, GL_STREAM_DRAW);

glGetBufferParameteriv(GL_PIXEL_UNPACK_BUFFER, GL_BUFFER_SIZE, &bsize); 
if (bsize != (sizeof(Pixel) * imWidth * imHeight)) {
    printf("Buffer object (%d) has incorrect size (%d).\n", pbuffer, bsize);
    exit(-1);
}

I modified the cudaGLMapBufferObject call as follows.
error = cudaGLMapBufferObject((void**)&data, pbuffer);
assert(data != NULL);

What I notice is that it returns an error value of 10205. This call works fine 3 times but fails on the 4th call.

How can I find more information on this error code?

Here is the documentation from the Programming_Guide_1_1.pdf

maps the buffer object of ID bufferObj into the address space of CUDA and returns in *devPtr the base pointer of the resulting mapping.

There is no discussion of how or why the call might fail.

find in files reveals

/DEVICE_BUILTIN/
enum cudaError
{
cudaSuccess = 0,
cudaErrorMissingConfiguration,
cudaErrorMemoryAllocation,
cudaErrorInitializationError,
cudaErrorLaunchFailure,
cudaErrorPriorLaunchFailure,
cudaErrorLaunchTimeout,
cudaErrorLaunchOutOfResources,
cudaErrorInvalidDeviceFunction,
cudaErrorInvalidConfiguration,
cudaErrorInvalidDevice,
cudaErrorInvalidValue,
cudaErrorInvalidPitchValue,
cudaErrorInvalidSymbol,
cudaErrorMapBufferObjectFailed,
cudaErrorUnmapBufferObjectFailed,
cudaErrorInvalidHostPointer,
cudaErrorInvalidDevicePointer,
cudaErrorInvalidTexture,
cudaErrorInvalidTextureBinding,
cudaErrorInvalidChannelDescriptor,
cudaErrorInvalidMemcpyDirection,
cudaErrorAddressOfConstant,
cudaErrorTextureFetchFailed,
cudaErrorTextureNotBound,
cudaErrorSynchronizationError,
cudaErrorInvalidFilterSetting,
cudaErrorInvalidNormSetting,
cudaErrorMixedDeviceExecution,
cudaErrorCudartUnloading,
cudaErrorUnknown,
cudaErrorNotYetImplemented,
cudaErrorMemoryValueTooLarge,
cudaErrorInvalidResourceHandle,
cudaErrorNotReady,
cudaErrorStartupFailure = 0x7f,
cudaErrorApiFailureBase = 10000
};

So 10205 is not defined in the enum. It is greater than the last value of 10000. What does that mean? I have an undefined error.

This thread http://forums.nvidia.com/index.php?showtopic=51706 had a similar issue (undefined error enum via opengl integration calls) but it was triggered in a very differnt way. Maybe there is something there that will help you, maybe not.

Thanks for the link. I did come across the thread you linked and it did help in my debugging effort. This thread led me to capture the error code and grep the headers to find the enum. I see that program was generating the old 10208 error code.

I any case I found a .ppt somewhere via google. I tried the following modification and it is working better. (Now I am getting an exception in the cleanup funciton when I exit the program via the escape key. I will have to debug this as well.)

This works better for me:

CUDA_SAFE_CALL(cudaGLRegisterBufferObject(pbuffer));
error = cudaGLMapBufferObject((void**)&data, pbuffer);
assert(data != NULL);
Call CUDA Kernel Here
cudaGLUnmapBufferObject(pbuffer);
CUDA_SAFE_CALL(cudaGLUnregisterBufferObject(pbuffer));

This registers and unregisters the pbuffer with every call to display.

randgraham :
Yes you have to register/unregister the buffer before/after the mapping and processing of the PBO.
But I never got the error you mentioned (10205), probably because I was havign the registering code in place.

But have you tried to create more than one PBO at a time? That was where I was getting the 10208 error.

Also, you mention that the error is an ‘old error’. Does that mean you know how to solve it? If so, I would appreciate if you could tell me how to solve it. I have not been able to.
paulius, who was helping me out had told me to check out the multi-threaded glew. I have not tried that yet and have it listed on my white board as a to-do. As soon as I am done with this new thing…
For now, removing the CUDA_SAFE_CALL macro lets me run the program w/o a crash. But I want to get rid of that problem in a better way.

If you try the multi-threaded glew or some other way that solves it , please let me know. Thanks.

I have not gotten the 10208 error. Referring to it as “the old 10208 error” was a bit of humor that didn’t translate well into a forum post. Basically the numbers 10205 and 10208 are meaningless. We know that they are greater than the largest defined enum value. We also know that they are not assigned to any enum value. I can only guess what they mean. The documentation on error handling is limited. What could possibly be causing these errors? How should they be handled?

I have not tried to create more than one PBO.

Let us know how the multi threaded glew investigation turns out. I wouldn’t be surprised if two host threads are trying to access a shared resource on the device. Some kind of mutex might be needed to prevent this. I wouldn’t be surprised if there were some mutex code in the cudaGLRegisterBufferObject library calls. But I am still puzzled why my code was failing on the 4th call.

When propagating driver API error codes, the CUDA runtime (CUDART) adds 10000 (cudaErrorApiFailureBase) to them. So 10205 and 10208 correspond to the driver API error codes CUDA_ERROR_MAP_FAILED and CUDA_ERROR_ALREADY_MAPPED, respectively. MAP_FAILED can happen when the OpenGL driver has resized or relocated the buffer. If you take the time to develop a targeted repro case that causes that error return, please file a bug and we will investigate.

ALREADY_MAPPED happens when you try to map a buffer that has already been mapped; this could be caused by incorrect app code, or app code that isn’t handling an error condition gracefully. But this also could be caused by a driver bug. If you eliminate other possible explanations for the problem, please file a bug.