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
Staff

Re: Valgrind complaining about uninitialized values coming from libamdocl64.so

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

0 Likes
jonhoo
Journeyman III

Re: Valgrind complaining about uninitialized values coming from libamdocl64.so

I appreciate that you'll look into it.

Has any progress been made on this?

0 Likes
pinform
Staff
Staff

Re: Valgrind complaining about uninitialized values coming from libamdocl64.so

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

0 Likes
ravkum
Staff
Staff

Re: Valgrind complaining about uninitialized values coming from libamdocl64.so

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
jonhoo
Journeyman III

Re: Valgrind complaining about uninitialized values coming from libamdocl64.so

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
pinform
Staff
Staff

Re: Valgrind complaining about uninitialized values coming from libamdocl64.so

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