Then get debugging symbols for all of your libraries and re-run Valgrind,
then report the leak. Iâve had to do it once with Xorg, Iâm sure you guys
can to. Considering that most of what youâre using is libraries, they are
likely bugs not âŚfeatures⌠(i.e. intentional).On Mon, Apr 11, 2011 at 7:52 AM, john skaller <skaller at users.sourceforge.net wrote:
On 11/04/2011, at 3:26 AM, Nikos Chantziaras wrote:
But weâre not talking about a program here, weâre talking about leaky
libraries (since clearly
the OPâs program doesnât leak).
Itâs still the same.
I do not agree. It is legitimate for a program to allocate memory and leave
it
up to the OS to reclaim it on exit.
It is NOT legitimate for a library to do this because the library does not
have the responsibility of deciding the use of the components and
facilities
it supplies.
A library might allocate something that will exist for the whole lifetime
of the program using the library.
Then, we a few special exceptions, that library is bugged and should be
fixed.
Those allocations will be freed too by the OS at program termination.
A real leak is something that should have been freed prior to program
termination.
I can agree with that but only because what this claim
does is delegate the problem to consideration of what "should"
have been freed.
The issue is: âwhoâ makes that decision, and the answer âshouldâ be:
the application, and only the application.
A library which allocates memory must clearly document who is responsible
for making the decision to free it or not, and if so when to do so.
For example , SDL_init() may allocate memory and that
had better be freed by SDL_quit() (or some other specified function).
If some other functions (allocating a display surface for example)
requires the client to release it, or it is safe to call SDL_quit() because
it will do so, then this too must be documented.
IMHO: The root cause of this problem is badly educated programmers using
a bad language (namely C) with a bad library. The problem is greatly
reduced
using constructors and destructors in C++, and even further in languages
with
garbage collectors⌠so there ARE alternatives.
â
john skaller
skaller at users.sourceforge.net
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org