Does memory leak? (1995) • Hacker News Board

Re: Does memory leak? (1995)

#101

Post by retrac » Sat, Feb 22, 2020, 4:11 PM UTC

rowanG077 wrote: post #97

0xffff2 wrote: post #91

Earlier quoted context omitted.

The embedded world is very slow to change, so you can read about "modern approaches" (i.e. approaches used today) in any book about embedded programming written in the last 30 years. I currently work on spacecraft flight software and the only real advance on this project over something like the space shuttle that I can point to is that we're trying out some continuous integration on this project. We would like to use…

I find it interesting that such critical code is written in C. Why not use something with a lot more (easily)statically provable properties. Like Rust or Agda?

I think the answer was right there in their comment. "The compiler for our flight hardware platform is GCC 4.1 (upgrading to GCC 4.3 soon if we're lucky)".

Often, the only high-level language available for an embedded platform is a standard C compiler. If you're lucky.

Re: Does memory leak? (1995)

#102

Post by harryf » Sat, Feb 22, 2020, 4:14 PM UTC

0xffff2 wrote: post #91

giu wrote: post #85

Earlier quoted context omitted.

I'm always fascinated about software running on hardware-restricted systems like planes, space shuttles, and so on. Where can someone (i.e., in my case a software engineer who's working with Kotlin but has used C++ in his past) read more about modern approaches to writing embedded software for such systems? I'm asking for one because I'm curious by nature and additionally because I simply take the garbage collector f…

The embedded world is very slow to change, so you can read about "modern approaches" (i.e. approaches used today) in any book about embedded programming written in the last 30 years. I currently work on spacecraft flight software and the only real advance on this project over something like the space shuttle that I can point to is that we're trying out some continuous integration on this project. We would like to use…

I wonder if the same is true of Space X?

Re: Does memory leak? (1995)

#103

Post by NobodyNada » Sat, Feb 22, 2020, 4:17 PM UTC

rowanG077 wrote: post #97

0xffff2 wrote: post #91

Earlier quoted context omitted.

The embedded world is very slow to change, so you can read about "modern approaches" (i.e. approaches used today) in any book about embedded programming written in the last 30 years. I currently work on spacecraft flight software and the only real advance on this project over something like the space shuttle that I can point to is that we're trying out some continuous integration on this project. We would like to use…

I find it interesting that such critical code is written in C. Why not use something with a lot more (easily)statically provable properties. Like Rust or Agda?

Using a newer language carries a lot of risks and challenges for embedded programs:

- There’s a high risk of bugs in the compiler/standard library in languages with lots of features

- Usually, the manufacturer of an embedded platform provides a C compiler. Porting a new compiler can be a LOT of work, and the resulting port can often be very buggy

- Even if you can get a compiler to work, many newer languages rely on a complicated runtime/standard library, which is a deal-breaker when your complete program has to fit in a few kilobytes of ROM

Re: Does memory leak? (1995)

#104

Post by newscracker » Sat, Feb 22, 2020, 4:20 PM UTC

jmpman wrote: post #71

GordonS wrote: post #42

A bit OT, but I wonder how I'd feel if I was offered a job working on software for missiles. I'm sure the technical challenge would be immensely interesting, and I could tell myself that I cared more about accuracy and correctness than other potential hires... but from a moral standpoint, I don't think I could bring myself to do it. I realise of course that the military uses all sorts of software, including line of b…

Straight out of college, I was offered a job writing software for missiles. Extremely interesting area, working for my adjunct professor’s team, who I highly admired and whose class was the best of my college career. The pay was on par with all my other offers. I didn’t accept for two reasons. First, I logically agreed that the missiles were supporting our armed services and I believed that our government was general…

> I came on to a project which was 5 years into a 3 year schedule, and not expected to ship for another 2 years. Shocked, I asked my team lead “Why didn’t the government just cancel the contract and assign the work to another company?”, her reply, “If they did that, the product likely wouldn’t be delivered in under two years, so they stick with us”. I understood that this mentality was pervasive, and would ultimately become part of me, if I continued to work for that company. That mentality was completely unacceptable in the competitive commercial world, and I feared the complacency which would infect me and not prepare me for the eventual time when I’d need to look for a job outside that company.

Software for any system is complex. And it’s quite common for almost every software project to be late on schedule. The Triple Constraint — “schedule, quality, cost: pick any two” doesn’t even fit software engineering in any kind of serious endeavor because it’s mostly a “pick one” scenario.

If you’ve worked on projects where all these three were met with the initial projections, then whoever is estimating those has really made sure that they’ve added massive buffers on cost and time or the project is too trivial for a one person team to do in a month or two.

The entire reason Agile came up as a methodology was in recognizing that requirements change all the time, and that the “change is the only constant” refrain should be taken in stride to adapt how teams work.

Re: Does memory leak? (1995)

#105

Post by cozzyd » Sat, Feb 22, 2020, 4:22 PM UTC

ken wrote: post #38

nneonneo wrote: post #24

Earlier quoted context omitted.

Why is it hard to calculate? Suppose I maintain lots of complex calculations that require variable amounts of buffered measurements (e.g. the last few seconds, the last few minutes at lower resolution, some extrapolations from measurements under different conditions, etc.). Freeing up the right measurements might be really tricky to get right, and if you free a critical measurement and need it later you’re hosed. On…

Are you taking into account memory fragmentation? Or the internal malloc data structures? If your record were just 1 byte more, it could easily double the total actual memory usage. Memory usage is discrete, not continuous. It's not as simple as calculating the safety factor on a rope.

If you don't free, malloc doesn't need all that overhead

Re: Does memory leak? (1995)

#106

Post by amw-zero » Sat, Feb 22, 2020, 4:23 PM UTC

rowanG077 wrote: post #97

0xffff2 wrote: post #91

Earlier quoted context omitted.

The embedded world is very slow to change, so you can read about "modern approaches" (i.e. approaches used today) in any book about embedded programming written in the last 30 years. I currently work on spacecraft flight software and the only real advance on this project over something like the space shuttle that I can point to is that we're trying out some continuous integration on this project. We would like to use…

I find it interesting that such critical code is written in C. Why not use something with a lot more (easily)statically provable properties. Like Rust or Agda?

You’ll find that for very serious, industrial applications, a conservative mindset prevails. C may not be trendy at the moment, but it powers the computing world. Its shortcomings are also extremely well known and also statically analyzable.

Also, think about when flight software started being written. Was Rust an option? And once it came out, do you expect that programmers who are responsible for millions of people’s lives to drop their decades of tested code and development practices to make what is a bet on what is still a new language?

What I find interesting is this mindset. My conservativeness on a project is directly proportional to its importance / criticality, and I can’t think of anything more important or critical than software that runs on a commercial airplane. C is a small, very well understood language. Of course it gives you nothing in terms of automatic memory safety, but that is one tradeoff in the list of hundreds of other dimensions.

When building “important” things it’s important to think about tradeoffs, identify your biases, and make a choice that’s best for the project and the people that the choice will affect. If you told me that the moment anyone dies as a result of my software I would have to be killed, I would make sure to use the most tried-and-true tools available to me.

Re: Does memory leak? (1995)

#107

Post by asdfasgasdgasdg » Sat, Feb 22, 2020, 4:24 PM UTC

saagarjha wrote: post #89

catblast wrote: post #86

Earlier quoted context omitted.

Not sure how this is related. A general purpose allocator with a plain malloc interface can’t use this to do anything useful wrt lifetime because there is no correlation to lifetime provided by the interface. Internal arenas can be useful to address contention and fragmentation.

I'm pointing out that an arena is more about "a region of memory that you can split up to use later" than "a region of memory that must be allocated and deallocated all at once".

I've never heard that use of the term "arena". Are you thinking of slabs? Arenas are typically allocated and deallocated at once. That's their main feature.

Re: Does memory leak? (1995)

#108

Post by harryf » Sat, Feb 22, 2020, 4:24 PM UTC

emsy wrote: post #50

Out_of_Characte wrote: post #37

What an interesting concept. Good programmers always consider certain behaviours to be wrong. Memory 'leaks' being one of them. But this real application of purposefully not managing memory is also an interesting thought exercise. However counter intuitive, a memory leak in this case might be the most optimal solution in this problem space. I just never thought I would have to think of an object's lifetime in such a…

No, they did what good engineers do: They analyzed the problem and found a feasible and robust solution. Following rules without thinking is not what good programmers do. I’d argue that most problems of modern software development stem from this mindset, even when it’s a rule that should be applied 99% of the time.

All good until years later, a new team builds, unaware of the leak, same system into a longer range missile...

Re: Does memory leak? (1995)

#109

Post by ncmncm » Sat, Feb 22, 2020, 4:28 PM UTC

wbhart wrote: post #77

willvarfar wrote: post #62

Earlier quoted context omitted.

A simple bump allocator with no reclaim is fairly common in embedded code. Garbage collection makes the performance of the code much less deterministic. A lot of embedded loops running on embedded in-order cpus without an operating system use cycle count as a timing mechanism etc.

Right, but that isn't the argument that was being used here, which is my point. The way I read it, the contractor cared only enough to get the design over the line so the customer would sign off on it. Their argument was that you shouldn't care about leaks due to scheduled deconstruction, not because of a technical consideration. There exist options between no reclaim and using a garbage collector which could be cons…

Fetishism is not compatible with sound engineering.

"Cared only enough" is just your projection. The contractor knew the requirements, and satified the requirements with no waste of engineering time, and no risk of memory reclamation interfering with correct operation. The person complaining about leaks wasted both his time and the contractor's.

Re: Does memory leak? (1995)

#110

Post by Dylan16807 » Sat, Feb 22, 2020, 4:31 PM UTC

bootloop wrote: post #81

jakeinspace wrote: post #69

As somebody working on embedded software for aerospace, I'm surprised this missile system even had dynamic memory allocation. My entire organization keeps flight-critical code fully statically allocated.

I would imagine it might make sense if you offload some short, less frequent but memory intensive sub-routines (sensors, navigation) to run in parallel to the rest of the system. But I would still avoid having a system wide dynamic memory management and just implement one specifically for that part.

Whichever ones you allow to run in parallel need to have enough memory to run at the same time, but such a situation might happen quite rarely.

In other words, that sounds like a system where dynamic memory management is significantly riskier and harder to test than usual!

Why not static allocation, but sharing memory between the greedy chunks of code that can't run parallel to each other? (I assume these chunks exist, because otherwise your worst-case analysis for dynamic memory would be exactly the same as for static, and it wouldn't save you anything.)