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

OpenCL program crashes when kernel is build in clBuildProgram on Windows

Edgardo_Doerner
1,078 Views

Dear all,

I am developing a Monte Carlo code using OpenCL and I have a weird problem when I test my code across different OS. My main developing platform is an iMac Retina 5K, late 2015, with an Intel Core i5 CPU and AMD Radeon R9 M380 GPU, running Xcode 8.0 under OSX 10.11.6 (El Capitan). I also tested successfully my program under GNU/Linux CentOS with the last Intel OpenCL SDK and runtime drivers.

However, when I switch to Windows the program fails to build the program and finally crashes. With a Lenovo Thinkpad Twist, Windows 8.1, VS2015, Intel Parallel Studio XE 2015 and the last Intel OpenCL SDK and drivers when I arrive to the clBuildProgram stage I get the following message:

Number of OpenCL platforms found: 2
[0] Intel(R) OpenCL [Selected]
[1] Experimental OpenCL 2.1 CPU Only Platform

Platform for OpenCL execution: 0
CL_PLATFORM_PROFILE: FULL_PROFILE
CL_PLATFORM_VERSION: OpenCL 1.2
CL_PLATFORM_NAME: Intel(R) OpenCL
CL_PLATFORM_VENDOR: Intel(R) Corporation

Number of allocated OpenCL devices in context: 1
CPU detected
        Device name is        Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz
        Device vendor is Intel(R) Corporation
Context was created successfully
Successfully created command queue for device 0
Preferred work group size for device 0 : 1024
Number of histories for device 0 : 20480
0x00C939AA (0x00000001 0x01231168 0x01231B88 0x00EAF994), main() + 0x206A bytes(
s), C:\Users\Edgardo\documents\visual studio 2015\Projects\ocl_mc\ocl_mc\ocl_mai
n.c, line 652 + 0x42 byte(s)
0x00CA277E (0x2092C01A 0x00C91032 0x00C91032 0x7EF1F000), invoke_main() + 0x1E b
ytes(s), f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl, line 64 + 0x1B
byte(s)
0x00CA25CA (0x00EAF9A4 0x00CA2798 0x00EAF9B8 0x75FE7C04), __scrt_common_main_seh
() + 0x15A bytes(s), f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl, lin
e 255 + 0x5 byte(s)
0x00CA245D (0x00EAF9B8 0x75FE7C04 0x7EF1F000 0x75FE7BE0), __scrt_common_main() +
 0xD bytes(s), f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl, line 300
0x00CA2798 (0x7EF1F000 0x75FE7BE0 0x56524FEF 0x00EAFA00), mainCRTStartup() + 0x8
 bytes(s), f:\dd\vctools\crt\vcstartup\src\startup\exe_main.cpp, line 17
0x75FE7C04 (0x7EF1F000 0x576B038D 0x00000000 0x00000000), BaseThreadInitThunk()
+ 0x24 bytes(s)
0x7729AB8F (0xFFFFFFFF 0x77280009 0x00000000 0x00000000), RtlInitializeException
Chain() + 0x8F bytes(s)
0x7729AB5A (0x00C91032 0x7EF1F000 0x00000000 0x00000000), RtlInitializeException
Chain() + 0x5A bytes(s)

 

We have tested the program with other platforms with the same result. The kernel compiles and executes without issues under OSX and GNU/Linux, the latter with the Intel OpenCL SDK and runtime drivers, but as we switch to a Windows environment we obtain the above message. Any clues with this?, thanks for your help!!

PD: strangely, if I write from scratch the kernel using VS the error vanishes. That is my last resort (writing the entire kernel again for Windows), but I would like to know why this error happens and of course how to avoid it.

0 Kudos
5 Replies
Jeffrey_M_Intel1
Employee
1,078 Views

Thanks for your report.  Just to clarify, are you targeting CPU or GPU? 

0 Kudos
Edgardo_Doerner
1,078 Views

Hi Jeffrey, I am targeting both CPU and GPU, for the Lenovo Twist it is an Intel HD 4000. 

0 Kudos
Edgardo_Doerner
1,078 Views
After some research (and good luck) I found the problem and it was related on how my program reads the OpenCL kernel source file (*.cl).

In order to read it I used the following code:

cl_int ocl_error;

	/* Read each source file (*.cl) and store the contents into a temporary
	datastore */
	printf(" Reading source files : \n");
	for (size_t i = 0; i < num_files; i++) {
		printf(" [%lu] %s\n", i + 1, files);
		FILE* file = fopen(files, "r");
		if (file == NULL) {
			perror("Couldn't read the program file");
			exit(1);
		}
		fseek(file, 0, SEEK_END);
		sizes = ftell(file);
		rewind(file); /* reset the file pointer so that 'fread' reads from the
					  front */
		buffer = (char*)malloc(sizes + 1);
		buffer[sizes] = '\0';
		fread(buffer, sizeof(char), sizes, file);
		fclose(file);
	}

	printf(" Files read successfully \n");

The problem was in the reading mode user in the function "fopen()". If I use the "text mode" only the source file is not correctly read and some weird characters appears at the end of the file (like ÍÍÍ...), and finally clBuildProgram fails. I changed the reading mode to binary (argument "rb" in fopen()) and now the source file is correctly read and the program builds without problem.

However, it is quite strange that the clBuildProgram() build log gives a so strange output. I use the following code to read the output log from the routine:

cl_int ocl_error;
	char *ocl_programLog;
	size_t ocl_logSize;

	printf(" Building program with options : [%s]\n", options);
	ocl_error = clBuildProgram(*program, 0, 0, options, NULL, NULL);
	if (ocl_error != CL_SUCCESS) {
		/* Error whilst building the program, dump log */
		clGetProgramBuildInfo(*program, 0,
			CL_PROGRAM_BUILD_LOG, 0, NULL, &ocl_logSize);
		ocl_programLog = (char*)malloc(ocl_logSize + 1);
		ocl_programLog[ocl_logSize] = '\0';
		clGetProgramBuildInfo(*program, 0,
			CL_PROGRAM_BUILD_LOG, ocl_logSize + 1,
			ocl_programLog, NULL);
		printf("\n=== ERROR ===\n\n%s\n=============\n", ocl_programLog);
		exit(1);
	}
	printf(" Program was built successfully\n");

Am I doing the log reading correctly?. Thanks for your help!.

 

0 Kudos
Tamer_Assad
Innovator
1,078 Views

Hi Edgardo,

 

If the program has no problem, "clBuildProgram()" must return "CL_SUCCESS", and in the code you provided, the block

 if(ocl_error != CL_SUCCESS ){.....}

is never entered, if "clBuildProgram()" returned "CL_SUCCESS".

 

Now, the strange output, it is just the string type/ character set, on Visual Studio, your project setting might be set UNICODE. If so, you can simply use the following code:

int ilen = strlen(ocl_programLog);
wchar_t *tempwstr = new wchar_t[ilen];
size_t r = 0;
mbstowcs_s(&r, tempwstr, ilen, ocl_programLog, _TRUNCATE);    // multibyte (char*) to widechar (wchar_t*)
// now tempwstr holds a readable version of your ocl_programLog

 

Best regards,

Tamer Assad

0 Kudos
Tamer_Assad
Innovator
1,078 Views

Hi Edgardo,

 

If the program has no problem, "clBuildProgram()" must return "CL_SUCCESS", and in the code you provided, the block

if(ocl_error != CL_SUCCESS ){.....}

is never entered, if "clBuildProgram()" returned "CL_SUCCESS".

 

Now, the strange output, it is just the string type/ character set, on Visual Studio, your project setting might be set UNICODE. If so, you can simply use the following code:

int ilen = strlen(ocl_programLog);
wchar_t *tempwstr = new wchar_t[ilen]; 
size_t r = 0; 
mbstowcs_s(&r, tempwstr, ilen, ocl_programLog, _TRUNCATE);    // multibyte (char*) to widechar (wchar_t*) 
// now tempwstr holds a readable version of your ocl_programLog 

 

Best regards,

Tamer Assad

0 Kudos
Reply