OpenCL* for CPU
Ask questions and share information on Intel® SDK for OpenCL™ Applications and OpenCL™ implementations for Intel® CPU.
Announcements
This forum covers OpenCL* for CPU only. OpenCL* for GPU questions can be asked in the GPU Compute Software forum. Intel® FPGA SDK for OpenCL™ questions can be ask in the FPGA Intel® High Level Design forum.
1718 Discussions

Debugger problems... OclSocketError...

Polar01
Beginner
1,210 Views
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
0 Kudos
21 Replies
Eli_Bendersky__Intel
1,138 Views
Hi Polar01,

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

Thanks
0 Kudos
Polar01
Beginner
1,138 Views
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 !
0 Kudos
Eli_Bendersky__Intel
1,138 Views
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.
0 Kudos
Polar01
Beginner
1,138 Views
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 !
0 Kudos
Yuri_K_Intel
Employee
1,138 Views
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
0 Kudos
Polar01
Beginner
1,138 Views
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.
0 Kudos
Yuri_K_Intel
Employee
1,138 Views
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.
0 Kudos
Polar01
Beginner
1,138 Views
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 !
0 Kudos
Polar01
Beginner
1,138 Views
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
0 Kudos
Yuri_K_Intel
Employee
1,138 Views
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.
0 Kudos
Polar01
Beginner
1,138 Views
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
0 Kudos
Yuri_K_Intel
Employee
1,138 Views
If you perform steps 1..10 with your application in which step the behaviour becomes different?
0 Kudos
Polar01
Beginner
1,138 Views
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 !
0 Kudos
Polar01
Beginner
1,138 Views
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 !
0 Kudos
Eli_Bendersky__Intel
1,138 Views
Without a minimal reproducer, it will be very hard for us to help you.
0 Kudos
Polar01
Beginner
1,138 Views
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
0 Kudos
Polar01
Beginner
1,138 Views
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
0 Kudos
Polar01
Beginner
1,138 Views
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..
0 Kudos
Polar01
Beginner
1,138 Views
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 ?
0 Kudos
Raghupathi_M_Intel
1,068 Views
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.

Thanks,
Raghu
0 Kudos
Reply