Invalid command queue / access violation

For the perfectly correct kernel (written by nVidia), I’m getting the “invalid command queue” error while waiting kernel to finish. The same code run on CPU returns “access violation writing at location”. I’ve located the error:

__kernel void foo(__global const uint4* keysIn, __local uint* sMem, ...)
{
...
uint globalId = get_global_id(0);
uint4 key = keysIn[globalId];
...
key.x = sMem[...];
key.y = sMem[...];
key.z = sMem[...];
key.w = sMem[...];
...
}

And yes, the indexes that access local memory are checked to be in bounds. So, why would there be an error while trying to write to a simple private variable (on CPU)? Why would it make command queue go invalid (on GPU)?
Reference count of command queue before enqueueing kernel is fine, 1.

What OpenCL implementations are you using?

Getting an INVALID_COMMAND_QUEUE error is indicative of… well… passing an invalid command queue to the function. What function is returning that error? Did you make sure the command queue is properly initialized?

The “access violation writing at location” error could well be caused by the same reason. How did you determine that the error is caused by writing into the private variable “key”?

Generally when you have a problem like this you want to simplify your kernel and your app as much as possible while keeping the bug. Can you reproduce the bug with a 5-line kernel? Can you post that simplified kernel in this forum? Same thing with the app.

I would highly recommend checking the error variables for all of your OpenCL calls prior to that point. It sounds like your queue is empty.

I had an issue similar to this once that I thought was being caused by the command queue stepping out of bounds. It turns out I had changed the name of a kernel slightly in my .cl file and did not maintain that change on the C++ host side, so when I attempted to add the kernel, it failed. Because I wasn’t checking the error code, it was a silent failure that occurred about 2000 lines of code later.

Additionally, check the build log to make sure your kernel is being compiled correctly. My boss had an issue with a typo in their kernel that caused a compilation failure, which was easily checked by looking at the build log and the error code returned.

For example, you could use the following c++ code when after you build your OpenCL program


if(errorcode != CL_SUCCESS)
{
char* build_log;
size_t log_size;
clGetProgramBuildInfo(Program,Device,CL_PROGRAM_BUILD_LOG,0,NULL, &log_size);
build_log = new char[log_size+1];
clGetProgramBuildInfo(Program,Device,CL_PROGRAM_BUILD_LOG, log_size, build_log, NULL);
build_log[log_size] = '\0';
cout << build_log << endl;
delete [] build_log;
}

This isn’t necessarily the case. The command queue may be invalidated by the failure of an asynchronous command which was previously enqueued to a valid queue.

One common cause is an out-of-bounds memory operation. For debugging only, place Finishes around suspect commands to isolate which is causing the issue.

This isn’t necessarily the case. The command queue may be invalidated by the failure of an asynchronous command which was previously enqueued to a valid queue.

I must have missed that in the spec. Can you point me at the section where this is defined? A search for “invalid” and “INVALID_COMMAND_QUEUE” didn’t find anything relevant.

Thanks for the ideas guys. Build goes completely successful. I always Finish after each OpenCL action, for debugging purposes. david.garcia, as others read correctly, queue goes invalid while running, not at enqueue. Also changing kernel name didn’t help. Just btw, I found a thread on this forum with the same question as mine, not solved.

As soon as I locate any weird thing, I’ll post it, so we can get to the bottom of it.

According to page 141 of spec 1.1rev36:

If the execution of a command is terminated, the command-queue associated with this terminated command, and the associated context (and all other command-queues in this context) may no longer be available. The behavior of OpenCL API calls that use this context (and command-queues associated with this context) are now considered to be implementation- defined. The user registered callback function specified when context is created can be used to report appropriate error information.

Thanks, Andrew.

I have a very similar problem, I get an Invalid command queue error when I try to put a value in an array in the global memory. If I comment this line, the kernel works very well! I checked that the array is initialized at the host before passing it to the kernel and that the index is inbound, it fails even if I try to put a value at the zero index… any ideas? :frowning:

I could find a small tip, I tried putting conditions on all the indexes that might cause out of bounds error or cause an infinite loop, the error disappeared so far :slight_smile: