Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

Adept I

Garbage at end of build log



I'm really wondering if no one else is seeing this as I've read no reports about it yet: I'm always seeing garbage at the end of a build log. It looks like


C:\Users\SEBAST~1\AppData\Local\Temp\ error: bad argument

type to opencl image op: expected write_only image type

write_imagef(output, pos, pixel);


1 error detected in the compilation of "C:\Users\SEBAST~1\AppData\Local\Temp\".





As I'm not seeing any garbage for other OpenCL drivers with the same code I doubt there's a bug in my code (I'm using the Khronos C++ wrapper).

Is anyone else having garbage at the end of the build log?

10 Replies
Journeyman III

Couldn't you please post your build-log printing code? I guess there can be issue with CRLF -> LF conversion, because you have exactly 4 garbage characters which corresponds with 4 lines of the log.

This is the code I'm using (I haven't said it explicitly yet, but I'm on Windows, by the way):

cl::STRING_CLASS log=g_program->getBuildInfo(devices);
printf("[%s] Error: Device %d build log:\n%s",getName(),d,log.c_str());

I already debugged into the C++ wrapper and saw that the buffer returned by the underlying call to clGetProgramBuildInfo() already contains garbage at the end.

I believe this is because the buffer size returned by

::size_t required;
cl_int err = clGetProgramBuildInfo(CL_PROGRAM_BUILD_LOG, 0, NULL, &required);

is too big, probably because it counts newlines as \r\n (two chars) instead of just \n (one char). So I think you're right, pulec, the number of garbage chars I'm seeing much matches the numer of valid lines in the build log.


Have you considered reporting the bug if it's annoying for you? I mean "officially". Because I believe that some other (Windows) users may also suffer from this bug, although they do not report it. Although not serious, it is still a bug (supposedly). Unfortunately (?), I cannot replicate the it because of other platform.
Or maybe some responsible reads the forum.

pulec & sschuberth,

Thank you very much for poining this bug. This has been reported to the AMD developer team.



Thanks Himanshu. What's the preferred way of reporting (OpenCL) bugs? Is it by posting in this forum, or by sending an email to developer relations, or to the stream computing address?

Or does AMD also have a registered developer program with a bug tracker?


I have this strange characters at the end of my build log too!


When the build log is not empty, e.g. I have some warnings in it, I always get (heaps of) special characters at the end of the log. I find this pretty disturbing since this behaviour usually indicates problemes with memory allocation.

I didn't have this in SDK 2.2. It's new since SDK 2.3


Originally posted by: FrodoTheGiant

I didn't have this in SDK 2.2. It's new since SDK 2.3

IIRC, I had this with every SDK since 2.1. But anyway, the bug will hopefully be fixed in the next release now that it is reported.



You can choose any of the method. We try to attend to every Forum post and every testcase sent to

I would suggest to use Forums in case the bug is not specific to you as more people get to know about that. But if you see problems in your source code and are not sure what the issue might be, better to use


Maybe related to this bug: Similar characters are appearing at the beginning of an #include 'd file. I'll see if I can whip up a test case, but until this is fixed I have to prepend the strings of the included files in host code.  


Edit: it seems to be your (AMD/ATi) string loading code. Try opening this file in Wordpad or VS2010:

you'll see it begins with #ifndef BINNING_CL

Now when I try to #include this file from another file or load it in the stream Kernel analyzer it begins with: ï»¿#ifndef BINNING_CL which promptly derails the compiler.


Journeyman III

same in KernelAnalyzer 1.11.1172 / SDK 2.6. trash seems to appear when there are warnings from the compiler.