4

This question is as in title: Is it possible to produce a memory leak without using any kernel specific means like malloc, new, etc?

What if I will make a linked list inside a function with lot of elements in there, and after it I'll exit from this function without cleaning a list. The list will be created without using any malloc calls, i.e.

struct list_head {
     struct list_head *next, *prev;
}

Can it be guaranteed that all resources will be freed after exiting from this function? So I can freely execute it a million times and nothing will be leaked?

Subject: If you not using any particular malloc or new calls you won't get a heap memory leak. Never. Is that right?

Mikhail Kalashnikov
  • 1,146
  • 1
  • 11
  • 31
  • None of the string in your example are on the stack. For the first it's only the *pointer* that is on the stack, the actual string is somewhere else. The second (`string2`) *would* have been on the stack, if you assigned to it in the declaration, but now you only have a compilation error. – Some programmer dude Sep 24 '13 at 08:51
  • Jist of the question looks like [what-and-where-are-the-stack-and-heap??what is difference??](http://stackoverflow.com/questions/79923/what-and-where-are-the-stack-and-heap).[Where do string literlas go?](http://stackoverflow.com/questions/2589949/c-string-literals-where-do-they-go) – Dayal rai Sep 24 '13 at 08:52
  • As for leaking. Only if you allocate something, but never de-allocate it will you have a leak. Like opening a file but not closing it, or allocating memory with `malloc` or `new` but not freeing it with `free` or `delete`. – Some programmer dude Sep 24 '13 at 08:53
  • 6
    The whole "stack" and "heap" vocabulary is a crutch at best and misleading at worst. Most damningly, it's totally unnecessary for the question at hand. – Kerrek SB Sep 24 '13 at 08:53
  • You're looking at the wrong end of the cow. Rather, ask what constitutes 'freeing memory' or 'memory management'. Because, `list_head` is not a function (so it can never leak) and pointers usually imply dynamic memory allocations. You should ask "who's responsible for freeing this memory and _when_." (And the answer to the question is: yes. Just use `mmap`) – sehe Sep 24 '13 at 08:53
  • [What is a memory leak?](http://stackoverflow.com/questions/3373854/what-is-a-memory-leak) – Suvarna Pattayil Sep 24 '13 at 08:53
  • @KerrekSB I +1ed that. But, in fairness, it is kinda hard to _leak_ stack allocated resources. – sehe Sep 24 '13 at 08:56
  • @sehe: Yes, that's true, but also an almost entirely useless observation :-) It's the kind of observation that you'd only make *after* you've decided to partition the world into stacks and heaps, i.e. after the horse has bolted from the proverbial well. – Kerrek SB Sep 24 '13 at 08:59
  • Write a function to create linked list with lots of elements without allocation. That code will tell you why there won't be any leaks. – Amarghosh Sep 24 '13 at 09:04
  • OK, So the answer is: if you not using any particular malloc or new calls you won't get a heap memory leak. Never. Is that right? – Mikhail Kalashnikov Sep 24 '13 at 09:09
  • Malloc is not implemented in the kernel. Memory allocation is not even something only the kernel can do: Imagine a program declaring in its binary header that it has a heap segment 1GiB large; the kernel will load the binary with just that. Now the program can do its memory management internally on that large block of memory. In fact most malloc/new implementations operate a bit like that: Allocate a large chunk of address space/memory from the kernel, and manage allocations therein internally. – datenwolf Sep 24 '13 at 10:04

5 Answers5

12

A leak is always connected to a resource. A resource is by definition something that you acquire manually, and that you must release manually. Memory is a prime example, but there are other resources, too (file handles, mutex locks, network connections, etc.).

A leak occurs when you acquire a resource, but subsequently lose the handle to the resource so that nobody can release it. A lesser version of a leak is a "still-reachable" kind of situation where you don't release the resource, but you still have the handle and could release it. That's mostly down to laziness, but a leak by contrast is always a programming error.

Since your code never acquires any resources, it also cannot have any leaks.

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
  • "has no resources" could do with more careful phrasing. It certainly _refers_ to resources (so the code "has" resources "going on"). It doesn't (appear to) _own_ resources though. We can't tell for sure, because assigning to the list might (by documentation/definition) bestow ownership of the nodes to the list. – sehe Sep 24 '13 at 08:57
  • @sehe: No part of the OP's code acquires any resources, so I'd call that "having no resources" -- all the data the code uses is provided by the environment. I'll rephrase, though. – Kerrek SB Sep 24 '13 at 09:00
  • It's not a leak unless you're continuously loosing the resource. – James Kanze Sep 24 '13 at 09:55
  • 1
    It's possible to have an automatic memory leak, without explicitly requesting resources - stack pointer corruption, either intentional or not, can result in such situation. – SomeWittyUsername Sep 24 '13 at 09:58
  • 1
    @JamesKanze, a leak is a leak, no matter how often or how big it is. It may not have any cosnequences if it is small or unimportant enough, but it is still a leak by definition, if you loose the connection to it. – Devolus Sep 24 '13 at 09:59
  • @icepack: I'm assuming the program is otherwise correct. If you have UB, then there's little point talking about leaks. – Kerrek SB Sep 24 '13 at 11:11
  • @KerrekSB What's undefined in changing stack pointer? It might be incorrect but that's entirely different matter. – SomeWittyUsername Sep 24 '13 at 11:13
  • 2
    @icepack: can you give an example of what you have in mind, language-intrinsically? (There's no "stack pointer" in C or C++.) – Kerrek SB Sep 24 '13 at 11:13
  • This is pretty common in self-modifying code - I remember having exercises with stack frame manipulations in the early CS courses - it's more straightforward in assembly but I believe with some effort it's achievable in C/C++ as well (disable compiler optimizations, inspect the output assembly, even have inline assembly snippet, etc.). – SomeWittyUsername Sep 24 '13 at 11:24
1

The variables you applied without malloc or new is located at stack space in the memory. So when the function returned, the variable is taken back.

On the other hand, the memory you applied with malloc or new is located at heap space. The system doesn't care whether you release the space or not. In this situation, if you don't use free or delete, memory leak will happen.

YaleCheung
  • 630
  • 3
  • 9
1

Subject: If you not using any particular malloc or new calls you won't get a heap memory leak. Never. Is that right?

That assumption is not entirely correct. The problem is that the operating system itself (or other third party components you have to rely on) can have memory leaks as well. In that case you might not actively call malloc, but call other (operating system) functions which could leak.

So your assumption depends on how strongly you consider such a thing. You can argue that the OS/third party implementation is outside your domain, then this assumption would be correct. If you have a well defined system and your requirements are such that you have to garuantee a certain uptime, something like this may have to be considered as well.

So the answer to this question ...

Is it possible to make memory leak without using malloc?

... is:

Yes, it is possible.

Devolus
  • 21,661
  • 13
  • 66
  • 113
0

malloc() allocates memory from the heap, while space for string and struct literals (string1, string2 and those list_head's) will be reserved at compile time at the stack.

Actually any memory allocated for a program (heap or stack) will be reclaimed by the kernel when the process exits (at *nix system at least).

I would define memory leak as allocating memory on heap and without freeing it when your program exits. This definition actually answers your question.

There are standard functions (like strdup) that will allocate memory on heap, beware of them.

leesei
  • 6,020
  • 2
  • 29
  • 51
0

Another example of a resource that you can allocate and forget to free:

If you're using OpenGL, and you call glGenBuffers() a million times without the corresponding glDeleteBuffers calls, it's extremely likely that you will run out of VRAM and your graphics driver will start leaking to system memory.

I just had this happen. Fortunately, Visual Studio's memory profiler made it pretty easy to find. It showed up as a large number of allocations made by the external process nvoglv32.dll, which is my NVIDIA OpenGL driver.

Dan Bechard
  • 5,104
  • 3
  • 34
  • 51