1
int main()
{
    char *a = malloc(1024);
    return 0;
}

Does the program above have a memory leak? Please provide as complete and technical answer as it is possible.

kaspersky
  • 3,959
  • 4
  • 33
  • 50
  • 2
    Depends who you ask... Some people don't consider this a leak. – jrok Mar 13 '13 at 12:31
  • @Inisheer, I'm not asking if the memory is freed :) I'm asking if this a memory leak or not. – kaspersky Mar 13 '13 at 12:33
  • @gg.kaspersky Memory not freed is a leak. In this case, it appears you are curious if the memory leak persists after the application quits. – Inisheer Mar 13 '13 at 12:37
  • @Inisheer, according to some sources, a leak is considered the situation when you can't access allocated memory anymore. – kaspersky Mar 13 '13 at 12:39
  • @gg.kaspersky Correct. So, if perhaps the char* is still allocated after the application exits, then maybe it would be considered a leak. However, in the link I posted, it goes into detail about how memory is freed (in most cases) when an application exits. I see where you are coming from, but the examples are related. – Inisheer Mar 13 '13 at 12:41
  • Sounds like a homework question to me! – Neil Mar 13 '13 at 13:11

4 Answers4

4

Simple answer is yes. The OS is doing the tidying up for you

EDIT

For the benefit of gg.kaspersky.

When the program gets to the end you should have tidied up the heap. It says that you have considered all the allocations and provided the release of those resources (this can be said to be true for open files or other OS resources).

Is this complicated enough for you?

BTW - It is good manners when visiting a home (OS) you leave it in the same state as you arrived.

Ed Heal
  • 59,252
  • 17
  • 87
  • 127
4

The program itself has a leak. Whether the operating system cleans this up or not is a different matter. I suppose it's better to ask 'could this program potentially cause a problem on any system?' and the answer is absolutely yes.

The C standard nowhere says that memory allocated with malloc will be freed at program termination, either normal or abnormal. Compare that to open files, which are guaranteed to be closed for you by the C implementation if the program terminates normally.

teppic
  • 8,039
  • 2
  • 24
  • 37
  • I think this is the most clear answer (and correct). – kaspersky Mar 13 '13 at 13:29
  • @gg.kaspersky: it's easy to demonstrate with `valgrind`, which simulates (to an extent) a computer and operating system that doesn't clean up after programs. It'll report that it's permanently lost 1,024 bytes from running your program. – teppic Mar 13 '13 at 13:45
1

I wouldn't consider that a memory leak. The memory is still accessible through a variable that is still in scope when you exit.

Freeing all memory you allocated at the end of a program is just being unnecessarily pedantic and makes you spend time doing something that the operating system will do for you much more efficiently.

Edit (technical details):

With some implementations of malloc doing unnecessary freeing of memory at the end of a program can be horribly inefficient. All malloc implementations that keep their accounting information inline (through boundary tags or a similar mechanism) will touch most, if not all, pages that you have allocated. Normally this isn't a problem besides dirtying cache lines and TLB entries that are being thrown away, but couple this with a program that used enough memory to start using swap and you end up swapping in a lot of memory just to free it. The operating system can do this much more efficiently when you exit (by just marking the swap slots as free).

If you have a malloc implementation that returns memory to the operating system, freeing the memory will cause the operating system to unmap the memory which in turn requires expensive TLB operations if you're on a multiprocessor system. On exit the invalidation can be done much more efficiently (either by doing a full TLB flush or invalidating the TLB tag).

Art
  • 19,807
  • 1
  • 34
  • 60
  • 2
    That's a matter of opinion (in my opinion...). If your application is converted into a library in the future (which often happens), you'll now have to go through and figure out all the places where stuff needs clearing up. So you may as well do it in the first place. – Oliver Charlesworth Mar 13 '13 at 12:39
  • Consider if the allocated memory contains references to OS resources (e.g. file descriptor to a socket etc). This would tell me that if you have not unallocated the memory containing that descriptor it tells me that the programmer has not closed down the socket i.e. the client/server is still hanging. – Ed Heal Mar 13 '13 at 12:46
  • @OliCharlesworth, am I getting it right, that, ignoring the "good coding practice" stuff, the program (running on a modern linux os), wouldn't cause any problems? – kaspersky Mar 13 '13 at 12:49
  • "With some implementations of malloc doing unnecessary freeing of memory at the end of a program can be horribly inefficient" - A reference to why you say this is true? – Ed Heal Mar 13 '13 at 12:49
  • @OliCharlesworth Sure. But I'm answering the question being asked, not a hypothetical one. I've been able to practically cut down the execution time of a program by several minutes by removing the pedantic freeing of memory at the end of it. Also, having worked with the memory management on an OS level, including the exit path of processes, I know how much cheaper it is to just nuke the whole thing in the operating system rather than doing it from userland. – Art Mar 13 '13 at 12:51
  • @gg.kaspersky - Modern OS in terms of memory management should not be a problem. But take heed to my comment above. – Ed Heal Mar 13 '13 at 12:51
  • @EdHeal That paragraph partially refers to the work Paul Henning Kamp did when designing the [FreeBSD malloc](http://phk.freebsd.dk/pubs/malloc.pdf). Last time I looked, many popular mallocs, including the one in glibc, still used inline boundary tags. Also, it refers to my experience, as limited as it may be. – Art Mar 13 '13 at 12:54
1

Your question is incomplete... and as such the best answer you can get is "it depends".

From a program scope, yes, you have a memory leak. That much should be obvious. From a system scope the answer is it depends on which operating system you're running on.

In general if you're programming on a main stream device (Win7/MacOSX/Linux desktop/laptop computer, iOS/Android device, etc) you're pretty safe. I can't think of any main stream modern operating systems which would not be able to clean up after you.

However, if you're working on some older or embedded systems, you will leak memory here. I've seen memory leaks on a uCLinux platform (an OS specifically designed for hardware which does not have an MMU[Memory Management Unit]).

Dynamic memory is generally considered dangerous, which is why it's not legal to use it on some RTOSs. If you know the scope of deployment of your application throughout the lifetime of its use, you're fine to code like this... but the odds are you don't, and you shouldn't make assumptions about what the OS will do. Always clean up your own mess.

Mike
  • 47,263
  • 29
  • 113
  • 177
  • I agree that my question is incomplete, it misses the definition of what a memory leak is. – kaspersky Mar 13 '13 at 12:53
  • @gg.kaspersky - Yes, but more to the point, what's the OS? I think it's a safe assumption that a memory leak is "an inaccessible range of RAM addresses only recovered by a power cycle of the system", and (as per my answer) some OSs can catch/free that before it causes problems, some can't. – Mike Mar 13 '13 at 13:03