4 ms·
I am sorry but you are wrong. Your understanding of the concept is not complete yet. Close but not complete. Memory leak has a specific meaning. A memory leak
by siscia 6y ago
I am sorry but you are wrong. Your understanding of the concept is not complete yet. Close but not complete.
Memory leak has a specific meaning. A memory leak is memory that is been allocated but cannot be accessed and deallocate anymore. How useful is that memory is not important. The Wikipedia article explains it much better than myself: https://en.m.wikipedia.org/wiki/Memory_leak https://en.m.wikipedia.org/wiki/Memory_leak
There are useful definition of memory leak, some software need to run for a very long time, they cannot leak memory.
In languages where the memory is automatically managed it is quite hard to generate a memory leak.
Indeed is the original article that simply used a wrong terminology.
If you got more questions let me know! Happy to help!
- gnulinux 6y agoI understand this definition, I explained it above in my comment. The problem is that definition is not useful. It's useful to detect memory leaks this way since it's easier, but that doesn't help us understand all problems our program can have with leaking resources. First and foremost, the problem the original definition points out doesn't exist any more. When a program dies, all the resources it allocated, file descriptors, memory, ports etc will safely be cleaned by the OS. Any modern OS that doesn't do so will consider this a bug. So there is no practical reason to sweat the original problem. It's still useful to sweat it since it's an indication of a problem, which is that your program fails to deallocate resources it allocates. However, this failure is not important just at the moment your program dies. It will remain important the entire lifetime of the program. As I explaind above, if your program runs in a loop, and needs to make O(N) resources runs on this loop and you can use constant memory every time, all you really need is O(1) memory since you can deallocate at the end of each loop. The problem arises when you fail to do and use O(N) resources. This will make your program break on large inputs when it really can work. What's more crucial is: (1) Analyzing your program's minimum asymptotic resource need (2) Observing your program's real asymptotic resource need (3) Optimizing your program in a way (2) is closer to (1)
- siscia 6y agoI just believe we work in very different environments. We had problems with compilers having memory leak. The software I write, runs for weeks or even months without being restarted. Yeah, the original problem of memory leak, or even resources leaks in general is still very very real in some field. Now, of course if you use python or golang, or javascript, basically you will never have a real memory leak. But this is not a good reason for calling bad use of resources "a memory leak". BTW: > First and foremost, the problem the original definition points out doesn't exist any more. When a program dies, all the resources it allocated, file descriptors, memory, ports etc will safely be cleaned by the OS. Any modern OS that doesn't do so will consider this a bug. So there is no practical reason to sweat the original problem. Memory leak never concerns the OS, like never. When the OS allocate memory to a software then is the software responsibility to deallocate it, returning it to the OS. > Any modern OS that doesn't do so will consider this a bug. This is true but it is not what we are discussing. Anyhow, I am just trying to help you understand what people usually means with "memory leak" because you seems a little confused. But if you are sure and you are definitely not confused and you think that it is me being wrong, I am not going to engage in any discussion. Cheers,