topic Debugger problems... OclSocketError... in OpenCL* for CPU

Debugger problems... OclSocketError...

Polar01 — Fri, 06 Jul 2012 08:19:45 GMT

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

Debugger problems... OclSocketError...

Eli_Bendersky__Intel — Sun, 08 Jul 2012 05:12:27 GMT

Hi Polar01,

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

Thanks

Debugger problems... OclSocketError...

Polar01 — Tue, 17 Jul 2012 13:29:41 GMT

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.cl

2 - I have add the kernel.cl file in my VS2010 solution

3 - I put a breakpoint in kernel.cl

4 - I restart the application (it will regenerate the same kernel.cl 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 !

Debugger problems... OclSocketError...

Eli_Bendersky__Intel — Wed, 18 Jul 2012 04:50:07 GMT

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.

Debugger problems... OclSocketError...

Polar01 — Wed, 18 Jul 2012 14:09:04 GMT

Thanks,

It is what I do :

I have try with :

"-g -s c:\kernel.cl"

"-g -p c:\kernel.cl"

But none work ! Visual studio does not stop in my code !

Debugger problems... OclSocketError...

Yuri_K_Intel — Fri, 20 Jul 2012 12:56:36 GMT

Hello,

You should use "-g -s c:\\path\\to\\your\\kernel.cl" 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\\kernel.cl"".

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

Thanks,
Yuri

Debugger problems... OclSocketError...

Polar01 — Mon, 23 Jul 2012 14:19:53 GMT

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\\kernel__ProductionRenderer.cl"";

Also, I got the following exception :

First-chance exception at 0x000007fefdd6cacd in spectralStudio.exe: Microsoft C++ exception: OclSocketError at memory location 0x0c0efa78.

Debugger problems... OclSocketError...

Yuri_K_Intel — Tue, 24 Jul 2012 09:36:12 GMT

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\\ToneMapping.cl", 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 ToneMapping.cl, line 60 in process 'icldbgsrv.exe'".
10. Continue debugging (F5) - kernel breakpoint should be hit.

Debugger problems... OclSocketError...

Polar01 — Tue, 24 Jul 2012 12:16:10 GMT

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 !

Debugger problems... OclSocketError...

Polar01 — Fri, 27 Jul 2012 09:14:29 GMT

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

Debugger problems... OclSocketError...

Yuri_K_Intel — Fri, 27 Jul 2012 13:51:45 GMT

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.

Debugger problems... OclSocketError...

Polar01 — Mon, 06 Aug 2012 09:25:06 GMT

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

Debugger problems... OclSocketError...

Yuri_K_Intel — Mon, 06 Aug 2012 14:20:47 GMT

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

Debugger problems... OclSocketError...

Polar01 — Thu, 09 Aug 2012 12:05:20 GMT

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 !

Debugger problems... OclSocketError...

Polar01 — Thu, 09 Aug 2012 12:33:47 GMT

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 !

Debugger problems... OclSocketError...

Eli_Bendersky__Intel — Thu, 09 Aug 2012 12:37:48 GMT

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

Debugger problems... OclSocketError...

Polar01 — Thu, 09 Aug 2012 12:49:32 GMT

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

Debugger problems... OclSocketError...

Polar01 — Fri, 10 Aug 2012 09:44:23 GMT

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 ?

Thanks

Debugger problems... OclSocketError...

Polar01 — Fri, 10 Aug 2012 09:50:38 GMT

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..

Debugger problems... OclSocketError...

Polar01 — Tue, 14 Aug 2012 14:36:49 GMT

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 ?