4 Replies Latest reply on Jan 23, 2010 9:39 AM by genaganna

    Unusual OpenCL application termination on Windows 7

    dwootton

      I have the SDK 2.0 installed on a Windows 7 machine and running a program compiled in Visual Studio 2008. I've run into a problem where I run the application and get a popup dialog with a message 'This application has requested the Runtime to terminate it in an unusual way. Please contact the support team for more information.'

      If I run the program using the Visual Studio debugger, the debugger does not get control even if I tell it to break on all exceptions. Is there some way to get the debugger to get control in this case?

      I think I did figure out why the program is doing this for this particular problem. I set breakpoints on calls to clCreateBuffer.

      I allocated 0x03000000, 0x01800000, 0x03000000, 0x01800000 bytes, in that order. At the second allocation of 0x01800000 bytes, I got the crash.

      If I allocate smaller blocks of memory in the same sequence I don't get a crash.

      I have a 4650 GPU with 512MB memory, so the second allocation of 0x01800000 bytes exceeds the capacity of the card.

      Shouldn't the OpenCL runtime return CL_OUT_OF_HOST_MEMORY in this case rather than crashing the program?

        • Unusual OpenCL application termination on Windows 7
          genaganna

          dwootton,

                    Could you please post your code to reproduce the crash problem?  Are you handling error codes properly?  Please also specify Driver version you are using.

            • Unusual OpenCL application termination on Windows 7
              nou

              it crash on linux too. output of code. when i use CPU context it work. when i use GPU only or GPU with CPU it crashed as below.

              first buffer 0
              second buffer 0
              /home/ocl/openclmainline/runtime/src/device/gpu/gpudevice.cpp:754: guarantee(!"We don't have enough video memory!")
              Aborted

              with CPU context i can alocate four 1GB buffers without crash. although global memory of CPU is reported 3GB and i have 4GB of RAM. i think that alocating buffers should be limited only with amount of RAM (plus swap thus virtual memory) not with amount of device memory. and enqueuekernel should return CL_MEM_OBJECT_ALLOCATION_FAILURE or CL_OUT_OF_RESOURCES if buffers needed for run that kernel does not fit in device memory.

              buff[0] = clCreateBuffer(context, CL_MEM_READ_ONLY, 128*1024*1024, NULL, &err_code); cout << "first buffer " << err_code << endl; if(err_code != CL_SUCCESS)return 0; buff[1] = clCreateBuffer(context, CL_MEM_READ_ONLY, 128*1024*1024, NULL, &err_code); cout << "first buffer " << err_code << endl; if(err_code != CL_SUCCESS)return 0; buff[2] = clCreateBuffer(context, CL_MEM_READ_ONLY, 128*1024*1024, NULL, &err_code); cout << "third buffer " << err_code << endl; if(err_code != CL_SUCCESS)return 0;

                • Unusual OpenCL application termination on Windows 7
                  dwootton

                  The attached program will cause the error. This program runs in console mode, so I do see the message
                  C:\openclmainline\runtime\src\device\gpu\gpudevice.cpp:754: guarantee(!"We don't have enough video memory!") on the failing allocation.

                  My original program is a Windows GUI program so I don't see any message. In both the console and GUI modes I get the same abort popup and no opportunity to stop in the debugger.

                  In both cases, I am checking return codes, so the out of memory condition is the first error in the program.

                  The graphics card driver version is 8.682.2.0 12/14/2009 on 64 bit Windows 7 with the test program running in 32 bit mode.

                  #include <CL/cl.h> #include <assert.h> #include <stdio.h> #define ALLOC_SIZE 20000000 class TaskParallel { public: TaskParallel(void); ~TaskParallel(void); void runTest(); }; TaskParallel::TaskParallel(void) { } TaskParallel::~TaskParallel(void) { } void TaskParallel::runTest() { cl_int status; cl_platform_id platform; cl_device_id device; cl_context_properties properties[4]; cl_context context; cl_mem image; char *cp; status = clGetPlatformIDs(1, &platform, NULL); assert(status == CL_SUCCESS); status = clGetDeviceIDs(platform, CL_DEVICE_TYPE_GPU, 1, &device, NULL); assert(status == CL_SUCCESS); properties[0] = CL_CONTEXT_PLATFORM; properties[1] = (cl_context_properties) platform; properties[2] = 0; properties[3] = 0; context = clCreateContext(properties, 1, &device, NULL, NULL, &status); assert (status == CL_SUCCESS); cp = new char[ALLOC_SIZE]; for (int i = 0; i < 100; i++) { printf("Allocating %d bytes\n", ALLOC_SIZE); image = clCreateBuffer(context, CL_MEM_READ_WRITE | CL_MEM_COPY_HOST_PTR, ALLOC_SIZE, cp, &status); assert (status == CL_SUCCESS); } } int main(int argc, char *argv[]) { TaskParallel testCase; testCase.runTest(); printf("Done\n"); }

                    • Unusual OpenCL application termination on Windows 7
                      genaganna

                       

                      Originally posted by: dwootton The attached program will cause the error. This program runs in console mode, so I do see the message C:\openclmainline\runtime\src\device\gpu\gpudevice.cpp:754: guarantee(!"We don't have enough video memory!") on the failing allocation.

                       

                      My original program is a Windows GUI program so I don't see any message. In both the console and GUI modes I get the same abort popup and no opportunity to stop in the debugger.

                       

                      In both cases, I am checking return codes, so the out of memory condition is the first error in the program.

                       

                      The graphics card driver version is 8.682.2.0 12/14/2009 on 64 bit Windows 7 with the test program running in 32 bit mode.

                       

                      Dwootton,

                                   Thank you for reporting this.  This issue have been identified internally and fixed.