4 ms·

Seems like there's some debate over what "memory leak" really means. On the one hand, you can just inadvertently grow some resource -- say, by appending to a li

Seems like there's some debate over what "memory leak" really means. On the one hand, you can just inadvertently grow some resource -- say, by appending to a list indefinitely -- until your sever crashes. But in this case, if the list goes out of scope it should be garbage collected, so such memory is in practice reclaimable. The more interesting case is allocation of memory which is not in practice reclaimable (as described in the first answer.) The former seems pretty trivial to understand, but if the original interviewers meant the latter I doubt I would have been able to come up with a good example off the top of my head.

bluGill 10y ago
Actually the more interesting case is your first: some list is appended to indefinitely. The memory isn't leaked in that you can access it, but by the act of not cleaning it up your run time performance slowly goes down over time: each list traversal hits elements in the list that presumably never need to be considered again. (if you are not traversing the list from time to time why are you keeping a list?) Several real world bugs have been root caused to some variation of this.
hinkley 10y ago
Any time the memory necessary to perform a similar action on similar data increases over time, people will call it a memory leak. It's just shorthand now for "we are using up all our memory and getting nothing in the bargain"
sqeaky 10y ago
I think I see where you are coming from and I disagree. I don't think that whether or not the memory is "reclaimable" is an important detail. When going to fix a performance issue or otherwise reduce memory usage the process to fix it is largely the same. Some programmer needs to understand the code in question at least well enough to mentally model its use of resources. Then that programmer needs to find a flaw and either prevent the allocation or clean up after the allocation. Whether or not it is "reclaimable" doesn't play a major role in the problem solving process. Both can be hard to find and both with bring an application down if left unchecked. Both need cleanup or prevention. There are tools to find both kinds of issues. Which tool is one of the first differences a programmer might see, but I think it is hard to argue that choosing between valgrind and a memory profiler is a deeply interesting issue that warrants separating these kinds of issues.
tannhaeuser 10y ago
Memory leaks on the server side are also a consequence of long-running single-process server software. What was traditionally run as a CGI (eg. Apache creating a fresh process for each request) or was started from inetd is now frequently implemented in a multi-threaded or evented fashion, so that using the O/S as garbage collector for memory and temp files doesn't work anymore. Not only does this put additional strain on getting memory management 100% right, it also creates memory fragmentation when done naively. While the consensus and narrative seems to be that evented I/O is more performant because the O/S doesn't have to schedule loads that have "nothing to do anyway most of the time" so to speak, I've yet to see a benchmark comparing traditional process-per-request vs. multithreaded and/or evented approaches; it's not that user-space memory management doesn't introduce additional overhead. My suspicion is that in many cases memory management strategies of desktop software have been used for server-side software without evaluation, or out of a habit because Java introduced GC into server software. But OTOH even OpenBSDs "new" (3-5 years old) httpd integrates traditional CGIs via the so-called "slowcgi" bridge, and uses evented I/O and asynchronous APIs natively so maybe I'm wrong on this one. If even OpenBSD developers themselves don't use ASLR and other techniques of OpenBSD to ensure non-deterministic memory allocation and go to great length to get equivalent protection within single-process request processing containers, they sure must be on to something.
- algesten 10y ago
  > Memory leaks on the server side are also a consequence of long-running single-process server software. On a tangent to this. I noticed that one benefit my company reaped from embracing a micro service architecture was that we get away with _a lot_ of shit code. Suddenly a NodeJS process can have glaring memory leaks and work fine for weeks because whenever it crashes, it restarts in 0.5 second and no one even bothered to investigate. Compare that with the good-ol-JBoss monolith with a 3-4 minute startup time. On the one hand, crap code can go unnoticed for weeks, which feels wrong and probably will bite us somewhere in the end, on the other hand, we can focus on function not code quality.
  - koolba 10y ago
    Plus if you build for this from the get go and assign a max life to your processes with auto restart, it becomes a native part of of their lifecycle. With multiple processes listening to the same socket it's easy to create a continuously on service that under the covers respawns with no apparent loss of service.

bluGill 10y ago

Actually the more interesting case is your first: some list is appended to indefinitely. The memory isn't leaked in that you can access it, but by the act of not cleaning it up your run time performance slowly goes down over time: each list traversal hits elements in the list that presumably never need to be considered again. (if you are not traversing the list from time to time why are you keeping a list?) Several real world bugs have been root caused to some variation of this.

hinkley 10y ago

Any time the memory necessary to perform a similar action on similar data increases over time, people will call it a memory leak. It's just shorthand now for "we are using up all our memory and getting nothing in the bargain"

sqeaky 10y ago

I think I see where you are coming from and I disagree. I don't think that whether or not the memory is "reclaimable" is an important detail. When going to fix a performance issue or otherwise reduce memory usage the process to fix it is largely the same. Some programmer needs to understand the code in question at least well enough to mentally model its use of resources. Then that programmer needs to find a flaw and either prevent the allocation or clean up after the allocation. Whether or not it is "reclaimable" doesn't play a major role in the problem solving process. Both can be hard to find and both with bring an application down if left unchecked. Both need cleanup or prevention. There are tools to find both kinds of issues. Which tool is one of the first differences a programmer might see, but I think it is hard to argue that choosing between valgrind and a memory profiler is a deeply interesting issue that warrants separating these kinds of issues.

tannhaeuser 10y ago

Memory leaks on the server side are also a consequence of long-running single-process server software. What was traditionally run as a CGI (eg. Apache creating a fresh process for each request) or was started from inetd is now frequently implemented in a multi-threaded or evented fashion, so that using the O/S as garbage collector for memory and temp files doesn't work anymore. Not only does this put additional strain on getting memory management 100% right, it also creates memory fragmentation when done naively. While the consensus and narrative seems to be that evented I/O is more performant because the O/S doesn't have to schedule loads that have "nothing to do anyway most of the time" so to speak, I've yet to see a benchmark comparing traditional process-per-request vs. multithreaded and/or evented approaches; it's not that user-space memory management doesn't introduce additional overhead. My suspicion is that in many cases memory management strategies of desktop software have been used for server-side software without evaluation, or out of a habit because Java introduced GC into server software. But OTOH even OpenBSDs "new" (3-5 years old) httpd integrates traditional CGIs via the so-called "slowcgi" bridge, and uses evented I/O and asynchronous APIs natively so maybe I'm wrong on this one. If even OpenBSD developers themselves don't use ASLR and other techniques of OpenBSD to ensure non-deterministic memory allocation and go to great length to get equivalent protection within single-process request processing containers, they sure must be on to something.

algesten 10y ago
> Memory leaks on the server side are also a consequence of long-running single-process server software. On a tangent to this. I noticed that one benefit my company reaped from embracing a micro service architecture was that we get away with _a lot_ of shit code. Suddenly a NodeJS process can have glaring memory leaks and work fine for weeks because whenever it crashes, it restarts in 0.5 second and no one even bothered to investigate. Compare that with the good-ol-JBoss monolith with a 3-4 minute startup time. On the one hand, crap code can go unnoticed for weeks, which feels wrong and probably will bite us somewhere in the end, on the other hand, we can focus on function not code quality.
- koolba 10y ago
  Plus if you build for this from the get go and assign a max life to your processes with auto restart, it becomes a native part of of their lifecycle. With multiple processes listening to the same socket it's easy to create a continuously on service that under the covers respawns with no apparent loss of service.