Fake memory leaks? |
Grigory Javadyan
Guest
|
Hi,
This probably is a stupid question, but please bear with me, I'm relatively new to SDL... I have this very basic program that just initializes SDL and then quits it without doing anything. The code looks like this: #include <SDL/SDL.h> int main(int argc, char** argv){ SDL_Init(SDL_INIT_VIDEO); SDL_Surface* screen = SDL_SetVideoMode(640, 480, 16, SDL_HWSURFACE); SDL_Quit(); return 0; } Yet, when I run this program through Valgrind, it reports a memory leak: ==2554== LEAK SUMMARY: ==2554== definitely lost: 440 bytes in 8 blocks ==2554== indirectly lost: 352 bytes in 8 blocks ==2554== possibly lost: 0 bytes in 0 blocks ==2554== still reachable: 58,942 bytes in 884 blocks ==2554== suppressed: 0 bytes in 0 blocks My question is, what is the cause of this? Is this a real leak? Maybe Valgrind is reporting something wrong? Or are there some buffers allocated within the library that deliberately don't get free()'d? If yes, what is the motivation of this? I'd like to hear a library developer's opinion on this issue. Thanks! _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Fake memory leaks? |
Tobias Leich
Guest
|
Hi, maybe try calling SDL_FreeSurface after SDL_Quit...
-----Ursprüngliche Nachricht----- Von: [mailto:] Im Auftrag von Grigory Javadyan Gesendet: Samstag, 9. April 2011 22:09 An: Betreff: [SDL] Fake memory leaks? Hi, This probably is a stupid question, but please bear with me, I'm relatively new to SDL... I have this very basic program that just initializes SDL and then quits it without doing anything. The code looks like this: #include <SDL/SDL.h> int main(int argc, char** argv){ SDL_Init(SDL_INIT_VIDEO); SDL_Surface* screen = SDL_SetVideoMode(640, 480, 16, SDL_HWSURFACE); SDL_Quit(); return 0; } Yet, when I run this program through Valgrind, it reports a memory leak: ==2554== LEAK SUMMARY: ==2554== definitely lost: 440 bytes in 8 blocks ==2554== indirectly lost: 352 bytes in 8 blocks ==2554== possibly lost: 0 bytes in 0 blocks ==2554== still reachable: 58,942 bytes in 884 blocks ==2554== suppressed: 0 bytes in 0 blocks My question is, what is the cause of this? Is this a real leak? Maybe Valgrind is reporting something wrong? Or are there some buffers allocated within the library that deliberately don't get free()'d? If yes, what is the motivation of this? I'd like to hear a library developer's opinion on this issue. Thanks! _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Fake memory leaks? |
Sam Lantinga
Guest
|
There are some leaks in the C library, some leaks in the X11 libraries, and if this is SDL 1.3, there might be some newly introduced leaks.
Can you tell where things were allocated? On Sat, Apr 9, 2011 at 1:08 PM, Grigory Javadyan wrote:
|
|||||||||||||
|
Fake memory leaks? |
Grigory Javadyan
Guest
|
AFAIK, you don't need to call SDL_FreeSurface on the video surface,
since SDL_Quit does it... Anyway, I tried that too and it did not help. On Sun, Apr 10, 2011 at 1:25 AM, Tobias Leich wrote:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Fake memory leaks? |
Grigory Javadyan
Guest
|
I'm using SDL version 1.2 patchlevel 14 if that matters. I've run
valgrind with --leak-check=full and saw that some of the unattended allocations apparently happen within Xlib. Maybe the problem is there. On Sun, Apr 10, 2011 at 1:29 AM, Sam Lantinga wrote:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Fake memory leaks? |
Nikos Chantziaras
Guest
|
On 04/09/2011 11:08 PM, Grigory Javadyan wrote:
This is very common. That doesn't make it OK, of course, but it is common nonetheless. The reason is that many developers don't bother checking if everything is deallocated at the end of a program, since that's not really necessary; when the program ends, the operating system will free all its memory. Best thing you can do is bugger the packagers of your Linux distribution about it, so that they can add this leak to the default valgrind suppression list. The suppression lists shipped by distros are *huge*, exactly because this kind of thing is very common. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Fake memory leaks? |
Jean-François Sévère
Guest
|
Use valgrind's result with caution, as most of what it reports is harmless. I've never seen a case where "still reachable" blocks are a problem, they usually are deallocated after the valgrind log.
Also most of the time you can't make sense of it without an understanding of the API. A leak originating in X11 may be caused by a driver, X11, or by SDL who forgot to free a struct returned by an xlib method, or by you who forgot to free something returned by a method. Check the documentation of the libraries you use, but don't worry about it too much. What's most important to fix in valgrind are leaks that originate in your code (the top line of the stack is in your code). As for other errors, if they bother you, you can create a custom suppression file to hide them, especially if they clutter your result : http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress 2011/4/9 Grigory Javadyan
|
|||||||||||||||||
|
Fake memory leaks? |
Forest Hale
Guest
|
On 04/09/2011 02:01 PM, Nikos Chantziaras wrote:
As an anecdote, I should mention that on some operating systems, one can not expect the OS to clean up after an exiting application. AmigaOS verions 1.x-3.x (not sure about 4.x) are one such case, where only free memory is tracked, and programs share a single memory space and allocation system, this lead to an amazing level of paranoid debugging and careful program design. -- LordHavoc Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces Co-designer of Nexuiz - http://alientrap.org/nexuiz "War does not prove who is right, it proves who is left." - Unknown "Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass "A game is a series of interesting choices." - Sid Meier _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Fake memory leaks? |
Ryan C. Gordon
Guest
|
Yeah, Xlib has some small allocations it fails to free (it's not a bug in SDL, last time I checked). It's been that way for years, unfortunately, but it's only a few bytes for something that probably is meant to live as long as your process in most cases anyhow. --ryan. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Fake memory leaks? |
john skaller
Guest
|
On 10/04/2011, at 6:29 AM, Sam Lantinga wrote:
Really? Do you know where? I ran some code with Valgrind on my system which uses C and a garbage collector (to check the GC) and at the end of the program Valgrind reported zero leaks. -- john skaller _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Fake memory leaks? |
john skaller
Guest
|
On 10/04/2011, at 7:01 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). -- john skaller _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Fake memory leaks? |
Nikos Chantziaras
Guest
|
On 04/10/2011 08:32 AM, john skaller wrote:
It's still the same. A library might allocate something that will exist for the whole lifetime of the program using the library. 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. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||
|
Fake memory leaks? |
john skaller
Guest
|
On 11/04/2011, at 3:26 AM, Nikos Chantziaras wrote:
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.
Then, we a few special exceptions, that library is bugged and should be fixed.
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 _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||
|
Fake memory leaks? |
Grigory Javadyan
Guest
|
Sorry for off-topic, but what is your opinion of C being a "bad"
language based on? On Mon, Apr 11, 2011 at 5:52 PM, john skaller wrote:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Fake memory leaks? |
Jonny D
|
Move that to the game programmer mailing list or private, perhaps?
Jonny D On Mon, Apr 11, 2011 at 10:39 AM, Grigory Javadyan wrote:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Fake memory leaks? |
Mason Wheeler
Guest
|
Experience? Let's see, just off the top of my head:
Security holes. Worst string type ever, with the possible exception of Erlang's. Array/pointer confusion. Security holes. No boolean type/everything is a boolean, leading to... Assignment can return a result, leading to... Ugly "Yoda conditionals" (if 5 == variable) as a "best practice". Security holes. Duplicate logical/bitwise versions of all boolean operators (necessary because everything is a boolean). No exception support, making convoluted goto spaghetti necessary for proper error handling. Complicated, unintuitive syntax. Weird variable declaration. (What does "int* a, b;" declare? Not what you'd intuitively expect...) Oh, and did I mention it's directly responsible for billions of dollars lost due to the exploitation of all the SECURITY HOLES inherent in the C language?
_______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Fake memory leaks? |
woohoo
|
Definetely C is hard language. But it is only for noobs and for that who doesn't understand what he is going to do. All you said before is just "difference" or i may say even a "feature" of C, that you should understand when you're going to use it. C is synonym of such words as stability, portability and speed. This was proven by years of work applications such as linux kernel's, ffmpeg and etc.
I love holywars . 11 ËצÔ. 2011, × 17:59, Mason Wheeler ÎÁÐÉÓÁÌ(Á):
_______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||
|
Fake memory leaks? |
Sam Lantinga
Guest
|
Please take the holy war off list.
Thanks! 2011/4/11 Gordiychuck Oleg
|
|||||||||||||||||||
|
Fake memory leaks? |
john skaller
Guest
|
On 12/04/2011, at 12:39 AM, Grigory Javadyan wrote:
30 years of computer science and experience with other languages. including 10 years as a member of ISO/IEC SC22/WG21 (C++ committee) and a couple on the C committee. Please try Haskell or Ocaml to understand. Even C++ is superior and has the advantage of retaining compatibility with C libraries without dramas. in fact, experience with extending C to C++ shows just how bad C really is (particularly generalising by templates): it gets just about *everything* wrong that you could possible get wrong: automatic conversions, casts, unsafe dereference and array operations, ridiculously weak type system without polymorphism, unsafe linkage, exceptionally hard to optimise due to bad semantics (cf Fortran and "restrict" added to C99 to try to fix this), lack of sum types, lack of anonymous product types, lack of closures, lack of control inversion (control exchange primitive) absurdly difficult type syntax .. do I have to go on? Unsafe and non-reentrant libraries, static/global variables .. macros, non-platform independent code, .. Is there anything at all C did right? It's not entirely off topic in that whilst SDL library is C, you don't have to write C to use it. C++ binds seamlessly, Felix binds almost seamlessly, and there are many other languages with SDL bindings. On the topic of control inversion (lightweight threads) Felix has channels and cooperative threads ideally suited for games; basically every actor can have its own thread and be in control of its actions (a control master) without a performance penalty. Go also has channels though I've never tried it. The language comes with some SDL demos using this technique. So far it works but is still a bit clumsy to use. The model is akin to using chips and wiring them together. The wiring is still difficult but the chips (actors) can be programmed independently. In a similar way to a functions only actors have state. Like an object. Only, with ordinary objects you have to use callbacks which makes object methods slaves: actors are just like threads (they're masters) but control exchange is done by reading/writing channels instead of pre-emptively. So there are alternatives to C, although C is of course more mature .. or is that just more polite than senile? -- john skaller _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Fake memory leaks? |
john skaller
Guest
|
On 12/04/2011, at 1:22 AM, Gordiychuck Oleg wrote:
All languages are hard for noobs.. C is unique in that its hard for experts too -- john skaller _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Fake memory leaks? |
john skaller
Guest
|
On 12/04/2011, at 1:36 AM, Sam Lantinga wrote:
It's not a holy war. That suggests the matter is entirely one of personal feelings and irrational choice. Language design is a matter of computer science mixed with some human psychology. If we argue that one sort algorithm is faster than another, it isn't a matter of opinion. The performance can be calculated with complexity theory and it can be measure by experiment. This applies to languages too. But its your list so I'll shut up now -- john skaller _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Fake memory leaks? |
Jeff Post
Guest
|
On Tuesday 12 April 2011 07:08, john skaller wrote:
that C in the hands of non-experts can be dangerous. But that's true of C++ also. This is why, despite employers' desire to hire only young people, they should hire a few "old pros" to ride herd on the cats. Jeff _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Fake memory leaks? |
Patrick Baggett
Guest
|
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 wrote:
|
|||||||||||||||||||||
|