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

Valgrind reports error with Linux shared library

A_Z_
Beginner
493 Views
Hello all, I modified the BitonicSort program to run on Linux. While the program worked correctly, it would crash when exiting so I used Valgrind to debug. I have since switched to using the C++ bindings but these problems exist in both cases. The first problem is while creating a cl::Context object I get messages about an uninitialized value being used in the function below. Fortunately the debug info was left in. std::vector<:DEVICE> devices; devices.push_back(thisDevice); thisContext = cl::Context(devices,context_properties,NULL,NULL,&result); if(result != CL_SUCCESS) { printf("ERROR: cl::Context() failed with %d\n",result); return -1; } printf("INFO: cl::Context() created\n"); ==2875== Conditional jump or move depends on uninitialised value(s) ==2875== at 0x6F6B2A2: Intel::OpenCL::DeviceBackend::Utils::CPUDetect::CPUDetect() (in /usr/lib64/OpenCL/vendors/intel/libOclCpuBackEnd.so) ==2875== by 0x6F6B3FF: global constructors keyed to CPUDetect.cpp (in /usr/lib64/OpenCL/vendors/intel/libOclCpuBackEnd.so) ==2875== by 0x76C1DF5: ??? (in /usr/lib64/OpenCL/vendors/intel/libOclCpuBackEnd.so) ==2875== by 0x6F18602: ??? (in /usr/lib64/OpenCL/vendors/intel/libOclCpuBackEnd.so) ==2875== Uninitialised value was created by a stack allocation ==2875== at 0x6F6B260: Intel::OpenCL::DeviceBackend::Utils::CPUDetect::CPUDetect() (in /usr/lib64/OpenCL/vendors/intel/libOclCpuBackEnd.so) The second set of errors reports the following while running cl::Program::build(). program.build(devices,NULL,NULL,NULL); ==2889== Conditional jump or move depends on uninitialised value(s) ==2889== at 0x4A091A9: __GI_strlen (mc_replace_strmem.c:404) ==2889== by 0x307A6853E5: strdup (in /usr/lib64/libc-2.15.so) ==2889== by 0x57C24B2: Intel::OpenCL::Utils::CPUDetect::GetCPUInfo() (in /usr/lib64/OpenCL/vendors/intel/libclang_compiler.so) ==2889== by 0x57C2903: Intel::OpenCL::Utils::CPUDetect::GetInstance() (in /usr/lib64/OpenCL/vendors/intel/libclang_compiler.so) ==2889== by 0x57BD078: Intel::OpenCL::ClangFE::CompileTask::PrepareArgumentList(std::list<:STRING> >&, std::list<:STRING> >&, char const*) (in /usr/lib64/OpenCL/vendors/intel/libclang_compiler.so) ==2889== by 0x57BF059: Intel::OpenCL::ClangFE::CompileTask::Execute() (in /usr/lib64/OpenCL/vendors/intel/libclang_compiler.so) ==2889== by 0x3B1F20F689: Intel::OpenCL::TaskExecutor::execute_command(Intel::OpenCL::TaskExecutor::ITaskBase*) (in /usr/lib64/OpenCL/vendors/intel/libtask_executor.so) ==2889== by 0x3B1F213810: Intel::OpenCL::TaskExecutor::in_order_executor_task::execute() (in /usr/lib64/OpenCL/vendors/intel/libtask_executor.so) ==2889== by 0x3B1F6204FB: tbb::internal::custom_scheduler<:INTERNAL::INTELSCHEDULERTRAITS>::local_wait_for_all(tbb::task&, tbb::task*) (custom_scheduler.h:441) ==2889== by 0x3B1F61D7D8: tbb::internal::arena::process(tbb::internal::generic_scheduler&) (arena.cpp:91) ==2889== by 0x3B1F61BC8A: tbb::internal::market::process(rml::job&) (market.cpp:385) ==2889== by 0x3B1F6192F6: tbb::internal::rml::private_worker::run() (private_server.cpp:255) ==2889== Uninitialised value was created by a stack allocation ==2889== at 0x307A2148E5: _dl_runtime_resolve (in /usr/lib64/ld-2.15.so)
0 Kudos
2 Replies
Yuri_K_Intel
Employee
493 Views
Hi! Could you please attach a reproducer for this issue (modified BitonicSort, as well as makefile or compilation flags). Thanks, Yuri
0 Kudos
A_Z_
Beginner
493 Views
Compiled with 'clang++ -g -lOpenCL main.cpp' Run with 'valgrind ./a.out' I posted a cleaned-up single-file version. For me this crashes on exit, but doesn't when run through valgrind. Lines 136 and 167 have the function calls of interest. Algorithm otherwise executes correctly on a Core 2 Duo(P8400). Running on Fedora 17 clang version 3.3 (trunk 171050), although it happens with gcc as well
0 Kudos
Reply