5 ms·

This doesn't make any sense. If you don't know how to create one, if you don't know how to test that you don't have leak, how can you know you don't have leaks?

This doesn't make any sense. If you don't know how to create one, if you don't know how to test that you don't have leak, how can you know you don't have leaks? A simple python memory leak: a = get_a_huge_object() use_huge_object(a) # a function that takes long # that does not use a, but allocates more resources f() You can fix this by doing: # get_huge_object() returns a context manager # it deallocates at the end with get_huge_object() as a: use_huge_object(a) f() or even just: def g(): a = get_a_huge_object() use_huge_object(a) g() f() if you can rely on built-in deallocators. I hardly believe javascript code is divinely protected against something like this.

siscia 6y ago
That python one is not a memory leak, it is just uncareful use of resources.
- gnulinux 6y ago
  I don't consider this to be correct since the main computation in that function will be done in `f()` where `a` is inaccessible and therefore cannot be deallocated. This is similar to mallocing `a` and then not free'ing. Obviously when the program dies python will deallocate everything, duh, that's not a useful definition of memory leak since even in a memory leaking C program, OS will clean up the memory after program dies. While the program is working though, it's going to keep leaking memory this way even in python.
  - Kiro 6y ago
    In JavaScript where there's often a single thread running a long-lived process I think the common case is when you keep allocating stuff through event handlers and not dereferencing them. A single wasteful build-up of memory is not really what I see discussed when people are discussing memory leaks in JS. As another commenter said, the classic case being adding UI event handlers and then removing the DOM object without dereferencing the handler. Doing this over and over will eventually make the app unresponsive but not immediately.
  - 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 ago
      I 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 ago
        I 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,
Kiro 6y ago
Like I said in another reply, I don't think I have leaks because memory sits at a fixed percentage even though I get hundreds of requests a second. If there was a memory leak wouldn't the memory be eaten up eventually?
- gnulinux 6y ago
  If there is a memory leak, then yes, memory usage would increase as your program continues making progress. That's like saying: "I run my program and it works, how can I have bugs??" Unless you know how to properly test, of course you won't be able to find memory leaks and memory usage will stay the same. Do you click the same thing 5000 times and observe every time memory is cleaned? Do you have unittests against this? Idk, long story short "I don't know how to make memory leaks in javascript, so I must not have them" is non sequitur.
  - Kiro 6y ago
    Well, I have zero unit tests so there's that. > Do you click the same thing 5000 times and observe every time memory is cleaned? I don't know how to check that but not sure I understand. If it really was a memory leak the hundred of requests a second I get would surely make the app consume the whole server's memory eventually. I don't need to click stuff 5000 times to test that. It's happening in production as we speak. Just to clarify, it's a single-threaded Node process and its memory consumption has stayed the same for weeks, since the last time I restarted it.
    - jonathanlydall 6y ago
      It seems highly unlikely you have a memory leak as it doesn’t sound like you are observing continually increasing memory usage. I’ve worked a lot in C# and JavaScript and I’ve only had to watch out for memory leaks with event aggregators for messaging between UI components. So the UI has a button to start a use case. Each time the user goes into the use case a new object is created which on construction registers a callback against an event type with the event aggregator. The memory leak occurs if this callback is never de-registered on completion of the use case, since the callback is holding onto a reference to the new object created at initiation of the use case. If the use case is called repeatedly (think something like a check-in terminal), eventually the memory is exhausted. On backends I’ve only ever worried about potential memory exhaustion from things like unbounded caches.

siscia 6y ago

That python one is not a memory leak, it is just uncareful use of resources.

gnulinux 6y ago
I don't consider this to be correct since the main computation in that function will be done in `f()` where `a` is inaccessible and therefore cannot be deallocated. This is similar to mallocing `a` and then not free'ing. Obviously when the program dies python will deallocate everything, duh, that's not a useful definition of memory leak since even in a memory leaking C program, OS will clean up the memory after program dies. While the program is working though, it's going to keep leaking memory this way even in python.
- Kiro 6y ago
  In JavaScript where there's often a single thread running a long-lived process I think the common case is when you keep allocating stuff through event handlers and not dereferencing them. A single wasteful build-up of memory is not really what I see discussed when people are discussing memory leaks in JS. As another commenter said, the classic case being adding UI event handlers and then removing the DOM object without dereferencing the handler. Doing this over and over will eventually make the app unresponsive but not immediately.
- 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 ago
    I 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 ago
      I 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,

Kiro 6y ago

Like I said in another reply, I don't think I have leaks because memory sits at a fixed percentage even though I get hundreds of requests a second. If there was a memory leak wouldn't the memory be eaten up eventually?

gnulinux 6y ago
If there is a memory leak, then yes, memory usage would increase as your program continues making progress. That's like saying: "I run my program and it works, how can I have bugs??" Unless you know how to properly test, of course you won't be able to find memory leaks and memory usage will stay the same. Do you click the same thing 5000 times and observe every time memory is cleaned? Do you have unittests against this? Idk, long story short "I don't know how to make memory leaks in javascript, so I must not have them" is non sequitur.
- Kiro 6y ago
  Well, I have zero unit tests so there's that. > Do you click the same thing 5000 times and observe every time memory is cleaned? I don't know how to check that but not sure I understand. If it really was a memory leak the hundred of requests a second I get would surely make the app consume the whole server's memory eventually. I don't need to click stuff 5000 times to test that. It's happening in production as we speak. Just to clarify, it's a single-threaded Node process and its memory consumption has stayed the same for weeks, since the last time I restarted it.
  - jonathanlydall 6y ago
    It seems highly unlikely you have a memory leak as it doesn’t sound like you are observing continually increasing memory usage. I’ve worked a lot in C# and JavaScript and I’ve only had to watch out for memory leaks with event aggregators for messaging between UI components. So the UI has a button to start a use case. Each time the user goes into the use case a new object is created which on construction registers a callback against an event type with the event aggregator. The memory leak occurs if this callback is never de-registered on completion of the use case, since the callback is holding onto a reference to the new object created at initiation of the use case. If the use case is called repeatedly (think something like a check-in terminal), eventually the memory is exhausted. On backends I’ve only ever worried about potential memory exhaustion from things like unbounded caches.