Debugger problems... OclSocketError...

Debugger problems... OclSocketError...

Hi,I'm trying to debug my OpenCL kernel (on CPU) with the debugging utility in VS2010 but I got a OCLSocketError message !I work in local and have no local firewall !I have also try to change th IP port... but it is the same ! Anyway I have no firewall so I don't understand why it does not work !The result is that when I put a break point in my .cl file, the application lock but never go the the .cl file breakpoints !Any help ?Thanks

22 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi Polar01,

Could you please provide the full error log/printout you're getting in this case?


Sure (sorry for the delay),I have retry, here is what I do :1 - I generate (on the fly) the kernel source code and save it in kernel.cl2 - I have add the file in my VS2010 solution3 - I put a breakpoint in kernel.cl4 - I restart the application (it will regenerate the same file)5 - The application run, but does not stop !In visual studio, the breakpoint is disabled and if I move my mouse over it I got the message :"The breakpoint will not currently hit. No symbols have been loaded for this document"I have try to change the TCP port (use a non-default one), it is the same !

So there no longer is an issue with a socket error?

For the debugger to stop on the kernel as expected, you must pass the full path to the file MS Visual Studio knows about to clBuildProgram with the "-p" flag (and of course set "-g" too). Even if you actually generate the file on the fly, the full path passed to clBuildProgram must match the full path of the file you open with Visual Studion and put a breakpoint on.

Thanks,It is what I do :I have try with :"-g -s c:\""-g -p c:\"But none work ! Visual studio does not stop in my code !


You should use "-g -s c:\\path\\to\\your\\" as build options string for the clBuildProgram. Pay attention to double backslashes. You also need to enclose the path by escaped quotes if it contains spaces: "-g -s "c:\\path\\with spaces\\"".

Please, attach a small reproducer if the issue is not resolved.


Thanks,But it does not work too !What I have noticed is that I can't set the breakpoints in the .cl file, except if I put my build options in a static char*, this way :static char* KERNELPATH = " -g -s "E:\\spectral\\spectralLight\\Kernels_Generated\\"";Also, I got the following exception :First-chance exception at 0x000007fefdd6cacd in spectralStudio.exe: Microsoft C++ exception: OclSocketError at memory location 0x0c0efa78.

Could you please try the following steps. I also suggest to perform them with some simple OpenCL application/sample first.
1. Make sure that you have only 1 instance of Visual Studio open.
2. Check that OpenCL debugger is enabled in the "Tools->Intel SDK for OpenCL - Debugger" dialog.
3. Check the work-items value in the same dialog with respect to kernel execution. This is important in case the kernel runs with some offset and with the default work-items value (0,0,0) the debugger will not stop at the kernel breakpoint.
4. Make sure that you are working with Intel OpenCL platform and you select CPU device.
5. Add necessary build parameters to clBuildProgram like so:
clBuildProgram(g_program, 0, NULL, "-g -s c:\\work\\ToneMapping\\", NULL, NULL);
6. Make sure that the kernel source file you open in Visual Studio is the same file/text you pass to clCreateProgramWithSource function.
7. Put a breakpoint at host code right before (or at) clCreateContext function call. Put another breakpoint at kernel function code. Make sure that you put the breakpoint at the same kernel function that will be called/enqueued later.
8. Run the debugging session (F5). The debugger stops near clCreateContext. At this point the kernel breakpoint should be shown as not active (The breakpoint will not currently be hit...).
9. Step over the clCreateContext function call. At this point the kernel breakpoint should become active, showing something like "At, line 60 in process 'icldbgsrv.exe'".
10. Continue debugging (F5) - kernel breakpoint should be hit.

Thanks,I have download the tone-mapping sample and do exactly what you propose. I got the exact same behavior than you described !So, I do exactly the same with my project !I have also try to add my kernel code to the tone-mapping kernel, and it works !What can cause this problem ? I use the C++ interface to create my clContext, Queue etc... just for information !

Do you have an idea of the problem ? Why the sample work but not my application !?Can it be related to the OpenCL C++ API ? or the way I create my context ?Thanks

It definitely cannot be related to C++ interface, it should work fine.
Regarding other possible reasons it's quite hard to say without the code. If you share a small reproducer I will try to look into it.

I understand,Unfortunately it is difficult because the software is really big... the kernels are generated dynamically etc...So, doing a small reproducer is difficult...Also, the samples are working but not my application... something make the difference, but what !!!!Thx

If you perform steps 1..10 with your application in which step the behaviour becomes different?

I have discover something,In the same .cl file there are 2 kernels, a small one and a big one. I can debug the small one !But the not the big one !

I have found something else.When I debug the first kernel, then continue ... I enter into the other kernel !Then I go step by step and it crash after the initialization of the 4th parameter !What is strange is that without debugging, the kernel work (on both Intel and NVidia).I have also check for alignement and if both memory buffer are correctly created, I found no problem !

Without a minimal reproducer, it will be very hard for us to help you.

I understand, but I have try without success !Something else, it will be fine if we can put a breakpoint and it stop on any work-item (and not a specific one) !By example, some case happend is rare cases but I still need to debug them... when happening !Also, it will be fine that the debugger stop at the right line when a access-violation occur (if no corruption occur of course), when possible !Thanks

I continue to debug and found that I can enter into the kernel, in the method initialization but when I step over the parameter 'pixmapsBuffer' it throw an exception in the output.
Pixmap buffer is declared this way :
typedef struct __attribute__((packed)) { float x, y, z; } RGBMap;__global __read_only RGBMap* pixmapsBuffer;

Pixmap buffer is allocated this way :static int NULLBUFF = 0;_clBuffer_Pixmaps = new CLMemory(*_context, CL_MEM_READ_ONLY | CL_MEM_USE_HOST_PTR, 1, &NULLBUFF);

Notice that the buffer size is 1 (1 byte), simply because I don't use it ! But use a 'RGBMap*', can it be the problem ?


It seems related because when I put something in the pixmap buffer, it does not stop at this argument.But I'm still unable to enter into my kernel (maybe some other buffers have a size=1 too, I have to check).
BTW, the exception is :First-chance exception at 0x000007fefd6acacd in spectralStudio.exe: Microsoft C++ exception: OclSocketError at memory location 0x0de1fa78..

Do you think that we can expect more robust (more detailed description) when the OpenCL debugger crash !Because now, it seems to be hard to find the reason of the problem.Anyway, I have retest and it seems that if I don't setup some buffer with some valid data... I cannot trace step by step each parameter.Now, I still have no idea how to enter and debug my main kernel :-(Can you help please ?

Hi Polar01,

As your were previously told, it is very difficult to help you debug without a reproducer. You can try another option.

You mentioned that you were able to debug the sample and not your kernel, right? Can you capture your dynamically generated kernel, plug it into the sample app (replace the .cl file in the sample with your kernel that is causing the problem) and set the appropriate kernel args and see if you are able to debug it. If are running into the crash provide us the sample with your kernel and we will be able to help.


Hi Raghu,It is a good idea but unfortunately it is not so simple. Because I use a lot of different buffers that are initialized based on 'scene' file. There are a lot of settings !In fact, I have several kernels in the same .cl file, I can debug somes but not the main one !I think that the best I can do, is to give you access to my repository (SVN), help you to compile and launch the application... this way you will have the real reproducer. I can help you through skype by example to compile, install and use it... even debug if you want ?Honnestly, I don't see any other way to do !BTW, I understand it is not easy for you to debug without a small example !

Leave a Comment

Please sign in to add a comment. Not a member? Join today