cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

Paolo88
Journeyman III

Memory leaks during clGetPlatformIDs call

found a memory leak. Is it my fault?

Hi to everyone.

I'm here because I'm having some proble with my code.

I'm running my code over a Linux Ubuntu 9.04 with OpenCL SDK 2.01.

The problem is that I found some memory leaks when I do the call clGetPlatformIDs.

 

Here is a working example:#include
#include


using namespace std;

 

int main(){

cl_platform_id id;
cl_uint numberOfPlatform;

cl_int err = clGetPlatformIDs(1, &id, &numberOfPlatform);

if(err != CL_SUCCESS){
cout << "Error!!!" << endl;
}

cout << "Found: "
<< numberOfPlatform
<< " platforms."
<< endl;

return 0;
}

 

The output is:

Found: 1 platforms.

 

but if I run this code with valgrind I found 3699 bytes totally lost!!!

 

valgrind ./a.out
==4918== Memcheck, a memory error detector
==4918== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==4918== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==4918== Command: ./a.out
==4918==
Found: 1 platforms.
==4918==
==4918== HEAP SUMMARY:
==4918== in use at exit: 15,669 bytes in 173 blocks
==4918== total heap usage: 2,044 allocs, 1,871 frees, 1,454,721 bytes allocated
==4918==
==4918== LEAK SUMMARY:
==4918== definitely lost: 3,699 bytes in 10 blocks
==4918== indirectly lost: 0 bytes in 0 blocks
==4918== possibly lost: 403 bytes in 2 blocks
==4918== still reachable: 11,567 bytes in 161 blocks
==4918== suppressed: 0 bytes in 0 blocks
==4918== Rerun with --leak-check=full to see details of leaked memory
==4918==
==4918== For counts of detected and suppressed errors, rerun with: -v
==4918== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 77 from 15)

 

Has anyone encountered this situation before?

Is it my fault or what?

On the OpenCL specification I didn't see any kind of "clReleasePlatform" or something like that.

I would like to know your opinion about this issue.

 

Thanks in advance to anyone.

 

Paolo

#include <iostream> #include <CL/cl.h> using namespace std; int main(){ cl_platform_id id; cl_uint numberOfPlatform; cl_int err = clGetPlatformIDs(1, &id, &numberOfPlatform); if(err != CL_SUCCESS){ cout << "Error!!!" << endl; } cout << "Found: " << numberOfPlatform << " platforms." << endl; return 0; }

0 Likes
4 Replies
Paolo88
Journeyman III

I have seen that some people have already read this topic.

You are not replying because I'm doing something wrong or because you don't know the answer? I would like to know if this code gives you the same problem as mine.

Any help is more than appreciated.

 

Bye

0 Likes

You're not doing anything wrong as far as I can tell, but the Valgrind faq says:

4.1.     My program uses the C++ STL and string classes. Valgrind reports 'still reachable' memory leaks involving these classes at the exit of the program, but there should be none.

First of all: relax, it's probably not a bug, but a feature. Many implementations of the C++ standard libraries use their own memory pool allocators. Memory for quite a number of destructed objects is not immediately freed and given back to the OS, but kept in the pool(s) for later re-use. The fact that the pools are not freed at the exit of the program cause Valgrind to report this memory as still reachable. The behaviour not to free pools at the exit could be called a bug of the library though.

I suppose the question is if it adds up if you call clGetPlatformIDs a million times or so, and if the leak happens even if you don't call it. If it doesn't, accumulate it's probably a variant of the above issue - whereever the leak originates.

 

0 Likes

Thank you, I didn't know about that!
As a matter of fact, some time ago I had that problem with the STL and I didn't know that it was an "implemantation problem" (if we want to call it like that  )

However, it partially replies to my answer because part of the data are still reachable but almost 4KB (it's a lot!) are definitely lost.

As far as I know, "definitely lost" means that a data is totally lost, as the following example:

 

#include <iostream>

int main(){

    int *pointer = new int[100];

    return 0;

}

 

and, most of the time, it is incorrect.

 

I would like to know if the OpenCL memory leak is an error, as it seems or if I have to take it as it is.

 

Thank you again for everything.

 

Paolo

0 Likes

Memory leak issues are being looked into by developers.

0 Likes