4 ms·

Our industry went through this with the move to Java (and later .Net). "It will solve memory leaks!" ... "whoops, you can still leak memory in garbage collec

Our industry went through this with the move to Java (and later .Net). "It will solve memory leaks!" ... "whoops, you can still leak memory in garbage collected languages, my bad everyone!".

bcrosby95 4y ago
Both a paper cut and a gunshot wound bleed. It doesn't make them equal.
adgjlsfhk1 4y ago
ditching C doesn't solve memory leaks but it does solve use after free. A memory leak is a performance problem that isn't generally exploitable. A use after free is almost always a security vulnerability.
- P5fRxh5kUvp2th 4y ago
  quick, someone tell everyone locking up resources without releasing them isn't exploitable for bad actors.
  - worthless-trash 4y ago
    Memory leak is better than privesc in most cases of active exploitation.
- ndriscoll 4y ago
  You can use resources after releasing them in pretty much any language. That's maybe not as dangerous as reinterpreting arbitrary memory, but then you can also use object pools for everything in C, which is what some very high performance code I used to work on did.
wiseowise 4y ago
In C you leak memory because of all the land mines in the language. In Java/.Net you leak memory because you have flaw in your logic.
- paulmd 4y ago
  Circular references and other things that tend to leak memory on GC languages aren't a logic flaw in the sense of your business logic being wrong or your algorithms being bad, though. They're things the language allows you to do, that can be completely correct at a business level and visually correct at a code level, but result in fundamental breakage of the VM's operation. I say this as someone who does high-level languages as a day job, and doesn't find them to be a problem personally, but, yeah, Java as a concept still allows some unintuitive footguns like that. Difference in magnitude of impact, difference in the response of the standards organizations in handling it, but yeah it's certainly same kind of footgun as C lets you do. The difference being that Java has devoted an enormous amount of resources to squashing these errors and they largely aren't a problem anymore, where C is afraid to touch the "undefined behavior" and "implementation dependent" sacred cows. Is there an unspoken social contract between language committee and language users that aliasing a variable or causing a circular reference should not shoot your dog and burn down the house? That's the fundamental disagreement between Java and C's standards bodies.
  - scawf 4y ago
    Circular reference does not leak memory if your using a proper GC
- donkeybeer 4y ago
  Memory errors are always logic errors in C. Freeing something that was already freed or accessing a buffer out of bounds and so on are pure logic errors.
  - pjmlp 4y ago
    Plenty of logic errors in the last 50 years, CVE appeciates it.
    - donkeybeer 4y ago
      But that person was trying to say memory errors are some kind of special "magical" error, which is simply wrong. Memory errors are merely logical errors. There is nothing "special" or "mysterious" about them.
hardware2win 4y ago
I dont remember single mem leak in my half decade .net career which speaks how rare they are
- P5fRxh5kUvp2th 4y ago
  .net 1.0 was 20 years ago, you've been working in it for 5 years, roughly 25% of its lifetime.
  - hardware2win 4y ago
    We're evaluating techs by their state decade(s) ago here or what?
    - P5fRxh5kUvp2th 4y ago
      judgment is not the only reason for conversation, I strongly suggest you read back over the conversation from the beginning and endeavor to understand the context with which responses are made. I also suggest you say 5 years instead of "half-a-decade", most of us see through that and it's off-putting.
      - zamalek 4y ago
        I have worked with .Net, in a hobby capacity, since beta. I have worked with it professionally since 2007. I have seen two instances of rooted memory: - WPF. The implicit GC root path introduced by events. We were easily able to track this down due to the information that the GC holds in memory[1] (fixing it was not so easy). - A leak in managed C++ (non-pure, i.e. native code). We had to use the normal tools to track this down, not a 5 minute diagnosis. At the end of the day GC'd languages can have (and usually do) richer tooling surrounding memory usage. They are better in this regard even during a failure state. [1]: https://learn.microsoft.com/en-us/dotnet/core/diagnostics/sos-debugging-extension https://learn.microsoft.com/en-us/dotnet/core/diagnostics/so...
        4y ago
zamalek 4y ago
From my comment, emphasis added: > it could slightly reduce
raxxorraxor 4y ago
I had to move part of the Code to C for different reason (imaging device) and used that code in a .net application. But allocating unmanaged memory on .nets heap led to memory fragmentation and while overall there was enough memory available, you ran into allocation errors since unmanaged memory needed to be allocated in one successive block. Usually doesn't happen, but if you have large objects like high resolution images in memory, you can quickly run into problems. And to my knowledge there was no way to check if there was enough successive memory available. Had to wait on a patch for .net... not a problem anymore today, although I don't know the details how they solved the problem.

Our industry went through this with the move to Java (and later .Net). "It will solve memory leaks!" ... "whoops, you can still leak memory in garbage collected languages, my bad everyone!".

bcrosby95 4y ago

Both a paper cut and a gunshot wound bleed. It doesn't make them equal.

adgjlsfhk1 4y ago

ditching C doesn't solve memory leaks but it does solve use after free. A memory leak is a performance problem that isn't generally exploitable. A use after free is almost always a security vulnerability.

P5fRxh5kUvp2th 4y ago
quick, someone tell everyone locking up resources without releasing them isn't exploitable for bad actors.
- worthless-trash 4y ago
  Memory leak is better than privesc in most cases of active exploitation.
ndriscoll 4y ago
You can use resources after releasing them in pretty much any language. That's maybe not as dangerous as reinterpreting arbitrary memory, but then you can also use object pools for everything in C, which is what some very high performance code I used to work on did.

wiseowise 4y ago

In C you leak memory because of all the land mines in the language. In Java/.Net you leak memory because you have flaw in your logic.

paulmd 4y ago
Circular references and other things that tend to leak memory on GC languages aren't a logic flaw in the sense of your business logic being wrong or your algorithms being bad, though. They're things the language allows you to do, that can be completely correct at a business level and visually correct at a code level, but result in fundamental breakage of the VM's operation. I say this as someone who does high-level languages as a day job, and doesn't find them to be a problem personally, but, yeah, Java as a concept still allows some unintuitive footguns like that. Difference in magnitude of impact, difference in the response of the standards organizations in handling it, but yeah it's certainly same kind of footgun as C lets you do. The difference being that Java has devoted an enormous amount of resources to squashing these errors and they largely aren't a problem anymore, where C is afraid to touch the "undefined behavior" and "implementation dependent" sacred cows. Is there an unspoken social contract between language committee and language users that aliasing a variable or causing a circular reference should not shoot your dog and burn down the house? That's the fundamental disagreement between Java and C's standards bodies.
- scawf 4y ago
  Circular reference does not leak memory if your using a proper GC
donkeybeer 4y ago
Memory errors are always logic errors in C. Freeing something that was already freed or accessing a buffer out of bounds and so on are pure logic errors.
- pjmlp 4y ago
  Plenty of logic errors in the last 50 years, CVE appeciates it.
  - donkeybeer 4y ago
    But that person was trying to say memory errors are some kind of special "magical" error, which is simply wrong. Memory errors are merely logical errors. There is nothing "special" or "mysterious" about them.

hardware2win 4y ago

I dont remember single mem leak in my half decade .net career which speaks how rare they are

P5fRxh5kUvp2th 4y ago
.net 1.0 was 20 years ago, you've been working in it for 5 years, roughly 25% of its lifetime.
- hardware2win 4y ago
  We're evaluating techs by their state decade(s) ago here or what?
  - P5fRxh5kUvp2th 4y ago
    judgment is not the only reason for conversation, I strongly suggest you read back over the conversation from the beginning and endeavor to understand the context with which responses are made. I also suggest you say 5 years instead of "half-a-decade", most of us see through that and it's off-putting.
    - zamalek 4y ago
      I have worked with .Net, in a hobby capacity, since beta. I have worked with it professionally since 2007. I have seen two instances of rooted memory: - WPF. The implicit GC root path introduced by events. We were easily able to track this down due to the information that the GC holds in memory[1] (fixing it was not so easy). - A leak in managed C++ (non-pure, i.e. native code). We had to use the normal tools to track this down, not a 5 minute diagnosis. At the end of the day GC'd languages can have (and usually do) richer tooling surrounding memory usage. They are better in this regard even during a failure state. [1]: https://learn.microsoft.com/en-us/dotnet/core/diagnostics/sos-debugging-extension https://learn.microsoft.com/en-us/dotnet/core/diagnostics/so...
      - 4y ago

zamalek 4y ago

From my comment, emphasis added: > it could slightly reduce

raxxorraxor 4y ago

I had to move part of the Code to C for different reason (imaging device) and used that code in a .net application. But allocating unmanaged memory on .nets heap led to memory fragmentation and while overall there was enough memory available, you ran into allocation errors since unmanaged memory needed to be allocated in one successive block. Usually doesn't happen, but if you have large objects like high resolution images in memory, you can quickly run into problems. And to my knowledge there was no way to check if there was enough successive memory available. Had to wait on a patch for .net... not a problem anymore today, although I don't know the details how they solved the problem.