cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

jonhoo
Journeyman III

Valgrind complaining about uninitialized values coming from libamdocl64.so

I'm building an application using OpenCL, and while running Valgrind I am seeing a bunch of warnings about various problems inside libamdocl64. I'm not so worried about them as I see many other people mentioning them too. What does worry me, however, is that Valgrind is detecting uninitialized values in data after I do

size_t sz = /* size I'm expecting the output to be */
data = malloc(sz);
clEnqueueReadBuffer(queue, data_buf, CL_TRUE, 0, sz, data, 0, NULL, NULL);

where

data_buf = clCreateBuffer(context, CL_MEM_READ_WRITE | CL_MEM_HOST_READ_ONLY, /* same size as above */, NULL, NULL);

and data_buf is passed as a global argument to my kernel.

Specifically, I am getting several warnings like this when using some of the values in data (not all curiously enough):

==3176== Conditional jump or move depends on uninitialised value(s)
==3176==    by 0x4057CA: ocl_main(void*) (ocl.cpp:102)
==3176==    by 0x5A630A1: start_thread (in /usr/lib/libpthread-2.18.so)
==3176==    by 0x5D5E49C: clone (in /usr/lib/libc-2.18.so)
==3176==  Uninitialised value was created by a client request
==3176==    at 0xB4B9930: subioMemCpuAccess(IODrvConnHandleTypeRec*, IODrvMemHandleTypeRec*, long long, long long, bool) (in /usr/lib/libamdocl64.so)
==3176==    by 0xB4B1456: ioMemCpuAccess(void*, void*, long long, long long, _AtiDriverModule, IOMemoryUsageEnum, bool) (in /usr/lib/libamdocl64.so)
==3176==    by 0xB2C907F: gsl::MemoryObject::map(gsl::gsSubCtx*, gslMapAccessTypeEnum, gslGPUMaskRec, bool, bool) (in /usr/lib/libamdocl64.so)
==3176==    by 0xB25E667: CALGSLDevice::resMapRemote(void*&, unsigned long&, gsl::MemObject*, gslMapAccessTypeEnum) const (in /usr/lib/libamdocl64.so)
==3176==    by 0xB24A36C: gpu::Resource::map(gpu::VirtualGPU*, unsigned int, unsigned int, unsigned int) (in /usr/lib/libamdocl64.so)
==3176==    by 0xB24A470: gpu::Resource::hostRead(gpu::VirtualGPU*, void*, amd::Coord3D const&, amd::Coord3D const&, unsigned long, unsigned long) (in /usr/lib/libamdocl64.so)
==3176==    by 0xB211FA9: gpu::DmaBlitManager::readMemoryStaged(gpu::Resource&, void*, gpu::Resource&, unsigned long, unsigned long&, unsigned long&, unsigned long) const (in /usr/lib/libamdocl64.so)
==3176==    by 0xB2143DA: gpu::DmaBlitManager::readBuffer(gpu::Memory&, void*, amd::Coord3D const&, amd::Coord3D const&, bool) const (in /usr/lib/libamdocl64.so)
==3176==    by 0xB215A17: gpu::KernelBlitManager::readBuffer(gpu::Memory&, void*, amd::Coord3D const&, amd::Coord3D const&, bool) const (in /usr/lib/libamdocl64.so)
==3176==    by 0xB2521BC: gpu::VirtualGPU::submitReadMemory(amd::ReadMemoryCommand&) (in /usr/lib/libamdocl64.so)
==3176==    by 0xB1E491F: amd::CommandQueue::loop(device::VirtualDevice*) (in /usr/lib/libamdocl64.so)
==3176==    by 0xB1E518D: amd::CommandQueue::Thread::run(void*) (in /usr/lib/libamdocl64.so)

I'm also getting Value8 warnings when trying to read any of the values. Because this data is then propagated throughout my application, I also get several more errors as a result of this one further down the line.

I might very well be doing something completely silly that is causing this behavior, but I cannot figure out what that might be. Has anyone seen a similar issue anywhere?

I find it particularly strange that Valgrind says the uninitialized value was created inside the OpenCL library when I'm the one malloc'ing it?

System information:

Arch Linux x64 w/Linux 3.12

Catalyst 13.152.4

FirePro v4900

Cheers,

Jon

0 Likes
6 Replies
pinform
Staff

I have reported this issue to the development team.  The team is working on it.

0 Likes

I appreciate that you'll look into it.

Has any progress been made on this?

0 Likes

I haven't received an update. I will keep you posted.

0 Likes
ravkum
Staff

Hi Jon,

There is no error in the code snippet that you have posted. Do you get desired result if you run your application outside valgrind? A simple test scenario can be writing 1s on the data_buf in the kernel and after the clEnqueueReadBuffer call with CL_TRUE in the host, check the buffer.

The clCreateBuffer call is allocating data in the device memory. I think valgrind is talking about this memory allocation and not the data that you mallocd.

Regards,

Ravi

0 Likes

Hi Ravi,

Ah, perhaps I didn't explain myself correctly. The code is working perfectly fine as far as I can tell, also under Valgrind. That is not my concern. My concern is that I am getting a ton of warnings from Valgrind from within the AMD OpenCL library, which may obscure other, deeper errors. Ideally, the library should give no Valgrind errors when run with a correct application.

0 Likes

Hi Jon,

Check the AMD Knowledge base KB73 posting at: http://developer.amd.com/resources/documentation-articles/knowledge-base/?ID=19

The information in that posting suggests that those errors are false alarms and can be ignored.

--Prasad