Is it due to basic misunderstandings of how memory is dynamically allocated and deallocated on the programmer's part? Is it due to complacency?
+12
A:
No. It's due to the sheer amount of accounting it takes to keep track of every memory allocation. Who is responsible for allocating the memory? Who is responsible for freeing it? Ensuring that you use the same API to allocate and free the memory, etc... Ensuring you catch every possible program flow and clean up in every situation(for example, ensure you clean up after you catch an error or exception). The list goes on...
Jesse Weigert
2010-01-27 03:33:51
+1 Well said, this is a _hard_ problem
John Knoeller
2010-01-27 03:41:57
+1 Ditto. That's everything I wanted to say and more. I just love the undocumented API's people hand me expecting me to be some divining guru of memory allocation.
wheaties
2010-01-27 03:44:02
@John - Am I considered childish for chucking at the emphasis in your comment?
ChaosPandion
2010-01-27 03:44:55
In general, programming is hard.
Anon.
2010-01-27 03:54:52
I don't believe it's hard at all. You just have to explicitly understand ownership of resources. When a function returns a dynamically allocated block to you, it should say in the doco that you now have ownership and that it's your responsibility to free it. Likewise, if you pass the ownership onto another function, *it* is responsible. Note that you can pass memory to, and receive memory from, functions without transferring ownership, for example 'printf("%s",dyn_mem);' doesn't pass ownership but 'dyn_mem = strdup(str);' does.
paxdiablo
2010-01-27 04:19:18
If the problem is not hard, then incompetent developers are the norm.
Justin Smith
2010-01-27 04:25:14
@Chaos: not by me :)
John Knoeller
2010-01-27 04:37:20
@Justin - Isn't it the norm?
Tor Valamo
2010-01-27 04:51:53
@paxdiablo: "You just have to explicitly understand ownership of resources." That's exactly what is hard. My brain can't keep up with this sort of thing. Either you're smarter than me, or less self-aware.
Jay Bazuzi
2010-01-27 07:31:30
Luckily, most leaks are pretty small and never affect anyone in a significant way. It's the few leaks that are either big or repeated that are trouble. Unfortunately, tracking down a bad leak in a sea of innocuous leaks is extremely hard.
Jay Bazuzi
2010-01-27 07:32:51
+2
A:
In a decent sized project, one can lose track of allocated resources.
Sometimes a function is written expecting an uninitialized data structure as input that it will then initialize. Someone passes in a data structure that already initialized, and thus the previously allocated memory is leaked.
Memory leaks are caused by basic misunderstandings the same sense every bug is. And I would be shocked to find out anyone writes bug free code the first time every time. Memory leaks just happen to be the kind of bug that rarely causes a crash or explicitly wrong behavior (other than using too much memory, of course), so unless memory leaks are explicitly tested for a developer will likely never know they are present. Given that changes in the codebase always add bugs, and memory leaks are virtually invisible, memory leaks expand as a program ages and expands in size.
Even in languages which have automatic memory management, memory can be leaked because of cyclical references, depending on the garbage collection algorithm used.
Justin Smith
2010-01-27 03:40:22
+2
A:
I think it is due to the pressures of working in job that requires dead-lines and upper management pushing the project to get it out the door. So you could imagine, with the testing, q&a, peer code reviews, in such pressurized environments, that memory leaks could slip through the net.
Since your question did not mention language, today, there's automatic memory management that takes care of the memory accounting/tracking to ensure no memory leaks occur, think Java/.NET, but a few can slip through the net. It would have been with the likes of C/C++ that uses the malloc/new functions, and invariably are harder to check, due to the sheer volume of memory being allocated.
Then again, tracking down those leaks can be hard to find which is throwing another curveball to this answer - is it that it works on the dev's machine that it doesn't show up, but when in production, the memory starts leaking like hell, is it the configuration, hardware, software configuration, or worse, the memory leak can appear at random situation that is unique to within the production environment, or is it the time/cost constraint that allowed the memory leaks to occur or is it that the memory profiling tools are cost prohibitive or lack of funding to help the dev team track down leaks...
All in all, each and everyone within the dev team, have their own responsibility to ensure the code works, and know the rules about memory management (for example, such as for every malloc there should be a free, for every new there should be a delete), but no blame should be accounted for the dev team themselves, neither is finger pointing at the management for 'piling on the pressure on the dev team' either.
At the end of day, it would be false economy to rely on just the dev team and place 'complacency' on their shoulders.
Hope this helps, Best regards, Tom.
tommieb75
2010-01-27 03:46:03
Memory leaks are just bugs. Pressures on you as a programmer may cause you to make more mistakes (it happens to me), but without any pressure, you'll still have leaks. It's just a hard problem.
Jay Bazuzi
2010-01-27 07:29:27
+1
A:
Bugs.
Even without bugs, it can be impossible to know in advance which function should deallocate memory. It's easy enough if the code structure is essentially functional (the main function calls sub-functions, which process data then return a result), but it isn't trivial if several treads (or several different objects) share a piece of memory. Smart pointers can be used (in C++), but otherwise it's more or less impossible.
Leaks aren't the worst kind of bug. Their effect is generally just a cumulative degradation in performance (until you run out of memory), so they just aren't as high a priority.
wisty
2010-01-27 04:50:21