141–150 of 175 posts
Earlier quoted context omitted.
Seems like a mitigation for this kind of issue would be to simulate the inputs to the system for the expected flight duration.
IIRC it was the higher acceleration value of Ariane5 that the old code wasn't expecting that caused the problem. Some fuzz testing could have worked, I suppose.
Obviously this is a joke, but the real message should be: if you can't manage your own memory, you should be using a language implementation with automatic memory management. If your code really needs to run "close to the metal", you really need to figure out how to manage your memory. In 2024, language implementations without automatic memory management should be reserved for applications that absolutely need them.
I agree, and would expand the idea to all kinds of resources (files for example). Sadly not many languages have "automatic resource management". For example Go has automatic memory management, but if you read an HTTP request's body you have to remember to call req.Body.Close(). If you open a file you have to call file.Close(). If you launch a goroutine, you have to think about when it's going to end.
I'd like to know if some languages manage to automatically managed resources, and how they do it.
Over the years I had been debugging multiple memory problems and only once I had found a true memory leak. It wasn't the bug I was looking for, accounting for only 8 bytes per hour and it was the easiest of all: directly discovered by valgrind.
All others were memory bloat cases: memory reachable but not used. Like forgetting some small per-request descriptor in some auxiliary hashmap in one of the code pathways. Reproducing and debugging was pain because it required running a loaded backend for days under a profiler, before the bloated part becomes visible.
Funny thing is that while C++ is notorious for memory leaks this particular kind of problem is possible in any language that allows a global mutable state (so all the practical ones). From experience it seems that true leaks are unlikely in a reasonably-good C++ code. Just never mix business logic with memory management and you're good to go.
This is the core idea: > It is [...] entirely optional to call free. If you don’t call free, memory usage will increase over time, but technically, it’s not a leak. As an optimization, you may choose to call free to reduce memory, but again, strictly optional. This is beautiful! Unless your program is long-running, there's no point of ever calling free in your C programs. The system will free the memory for you when…
A professor actually told us that freeing prior to exit was harmful, because you may spend all of that time resurrecting swapped pages for no real benefit. Counterpoint is that debugging leaks is ~hopeless unless you have the ability to prune “intentional leaks” at exit
Earlier quoted context omitted.
Seems like a mitigation for this kind of issue would be to simulate the inputs to the system for the expected flight duration.
IIRC it was the higher acceleration value of Ariane5 that the old code wasn't expecting that caused the problem. Some fuzz testing could have worked, I suppose.
1. The module that failed actually was no longer in use for that part of the flight.
2. The acceleration for the part of the flight where it was in use was within the parameters.
3. Instead of just ignoring / clamping the out-of-bounds values, the no-longer-needed module sent a big error dump.
4. That error dump was sent to the next module in-line, which was expecting...I think numbers, but certainly not big textual error dumps. And so that failed as well.
5. I don't know if that second module was needed.
So had the module just (a) processed the incoming data normally or (b) clamped the values silently or (c) dropped the out-of-bounds values silently, the Ariane 5 would not have exploded.
Instead it did the "make it impossible to represent invalid states"-thing and exploded.
While I understand the appeal of that idea, I think it is overrated with any software that has to interact in some way shape or form with the real world, however indirectly. Because programmers tend to have a pretty limited understanding of what states are valid or invalid in the real world.
(See also: the "falsehoods programmers believe about XXX" series)
This has been PHP’s approach to memory management during its best decades. It’s a fantastic idea for short-running processes, which there should be more of anyway.
Are you saying PHP creates a new process for each request?
It used to be a quite common approach in UNIX server programming.
Earlier quoted context omitted.
It obviously is a joke, but at the same time it's actually a viable approach for the right problem. Sometimes leaking is very tolerable and in terms of programmer time, very cheap!
> It obviously is a joke, but at the same time it's actually a viable approach for the right problem. Define "it" here. Because "just don't free" is pretty different from what's in the post!
To avoid an bugs, you can add a `exit(0)` at the beginning of your program.
Earlier quoted context omitted.
I had a friend who worked for one of the big Market Makers, and he told me that they would indeed turn the GC off, but what they'd do is just pre-allocate everything into bigass arrays before-hand, and have incrementers to simulate the "new" keyword. They might do this in something more or less like a threadlocal to avoid having to deal with locks or race conditions or anything like that.
This is like going back to malloc and free but using array indices rather than pointers, and each type has a fixed-size heap. We did it in one Microsoft service because the very first .NET releases had slow GCs.