The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.


SDL Forum Index
SDL
Simple Directmedia Layer Forums
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:
Quote:
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?
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:
Quote:
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

_______________________________________________
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:
Quote:
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:
Quote:

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


_______________________________________________
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:
Quote:
[...]
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?

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
Quote:
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:
Quote:
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:
Quote:

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


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Fake memory leaks?
Forest Hale
Guest

On 04/09/2011 02:01 PM, Nikos Chantziaras wrote:
Quote:
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.

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

Quote:
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.

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:

Quote:
There are some leaks in the C library,

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:

Quote:
On 04/09/2011 11:08 PM, Grigory Javadyan wrote:
Quote:
[...]
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?

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.


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:
Quote:

On 10/04/2011, at 7:01 AM, Nikos Chantziaras wrote:

Quote:
On 04/09/2011 11:08 PM, Grigory Javadyan wrote:
Quote:
[...]
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?

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.


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. 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:

Quote:
Quote:

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.

Quote:
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.


Quote:
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





_______________________________________________
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? Smile

On Mon, Apr 11, 2011 at 5:52 PM, john skaller
wrote:
Quote:

On 11/04/2011, at 3:26 AM, Nikos Chantziaras wrote:
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

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Fake memory leaks?
Jonny D


Joined: 12 Sep 2009
Posts: 932
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:
Quote:
Sorry for off-topic, but what is your opinion of C being a "bad"
language based on? Smile

On Mon, Apr 11, 2011 at 5:52 PM, john skaller
wrote:
Quote:

On 11/04/2011, at 3:26 AM, Nikos Chantziaras wrote:
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

_______________________________________________
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?
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?



Quote:
----- Original Message ----
From: Grigory Javadyan
Subject: Re: [SDL] Fake memory leaks?

Sorry for off-topic, but what is your opinion of C being a "bad"
language based on? Smile

On Mon, Apr 11, 2011 at 5:52 PM, john skaller
wrote:
Quote:

On 11/04/2011, at 3:26 AM, Nikos Chantziaras wrote:
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.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Fake memory leaks?
woohoo


Joined: 15 Mar 2011
Posts: 16
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 Very Happy.


11 ËצÔ. 2011, × 17:59, Mason Wheeler ÎÁÐÉÓÁÌ(Á):

Quote:
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?



Quote:
----- Original Message ----
From: Grigory Javadyan
Subject: Re: [SDL] Fake memory leaks?

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:
Quote:

On 11/04/2011, at 3:26 AM, Nikos Chantziaras wrote:
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.

_______________________________________________
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

Please take the holy war off list.

Thanks! Smile

2011/4/11 Gordiychuck Oleg
Quote:
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 Very Happy.


11 квіт. 2011, в 17:59, Mason Wheeler написал(а):


Quote:
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?



Quote:
----- Original Message ----
From: Grigory Javadyan
Subject: Re: [SDL] Fake memory leaks?

Sorry for off-topic, but what is your opinion of C being a "bad"
language based on? Smile

On Mon, Apr 11, 2011 at 5:52 PM, john skaller
wrote:
Quote:

On 11/04/2011, at 3:26 AM, Nikos Chantziaras wrote:
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.

_______________________________________________
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?
john skaller
Guest

On 12/04/2011, at 12:39 AM, Grigory Javadyan wrote:

Quote:
Sorry for off-topic, but what is your opinion of C being a "bad"
language based on? Smile

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? Smile

--
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:

Quote:
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 languages are hard for noobs.. C is unique in that its hard for experts too Smile


--
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:

Quote:
Please take the holy war off list.

Thanks! Smile

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 Smile


--
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:
Quote:
On 12/04/2011, at 1:22 AM, Gordiychuck Oleg wrote:
Quote:
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 languages are hard for noobs.. C is unique in that its hard for experts
too Smile

FWIW, I agree with the first part, but not the second part. It is clear though
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. Wink

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:
Quote:

On 11/04/2011, at 3:26 AM, Nikos Chantziaras wrote:

Quote:
Quote:

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.

Quote:
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.


Quote:
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





_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org