Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Does memory leak? (1995)

groups.google.com

Post reply on HN
Print view View original

51–60 of 289 posts

Re: Does memory leak? (1995)

#51

Post by geophile »

The problem, of course, is that the chief software engineer doesn't appear to be have any understanding of what is causing the leaks, and whether the safety margin is adequate. Maybe there is some obscure and untested code path in which leaking would be much faster than anticipated.

To be sure, it is a unique environment, in which you know for a fact that your software does not need to run beyond a certain point in time. And in a situation like that, I think it is OK to say that we have enough of some resource to reach that point in time. (It's sort of like admitting that climate change is real, and will end life on earth, but then counting on The Rapture to excuse not caring.) But that's not what's going on here. It sounds like they weren't really sure that there would definitely be enough memory.

Re: Does memory leak? (1995)

#52

Post by ezoe »

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…

Well, there is a SAM system which is designed to kill missiles, not the humans.

That said, I think any software development which involves the government aren't fun at all for all the bureaucracies and inefficiency.

Re: Does memory leak? (1995)

#53

Post by derefr »

chapium wrote: post #16
mojuba wrote: post #8

One other class of applications that don't really require garbage collection is HTTP request handlers if run as isolated processes. They are usually very short-lived - they can't even live longer than some maximum enforced by the server. For example, PHP takes advantage of this and allows you not to worry about circular references much.

This is clearly not my subject area. Why would we be spawning processes for HTTP requests? This sounds awful for performance. My best guess is a security guarantee.

Not spawning, forking. Web servers were simple “accept(2) then fork(2)” loops for a long time. This is, for example, how inetd(8) works. Later, servers like Apache were optimized to “prefork” (i.e. to maintain a set of idle processes waiting for work, that would exit after a single request.)

Long-running worker threads came a long time later, and were indeed intensely criticized from a security perspective at the time, given that they’d be one use-after-free away from exposing a previous user’s password to a new user. (FCGI/WSGI was criticized for the same reason, as compared to the “clean” fork+exec subprocess model of CGI.)

Note that in the context of longer-running connection-oriented protocols, servers are still built in the “accept(2) then fork(2)” model. Postgres forks a process for each connection, for example.

One lesser-thought-about benefit of the forking model, is that it allows the OS to “see” requests; and so to apply CPU/memory/IO quotas to them, that don’t leak over onto undue impacts on successive requests against the same worker. Also, the OOM killer will just kill a request, not the whole server.

Re: Does memory leak? (1995)

#54

Post by kelvin0 »

MrBuddyCasino wrote: post #15

Why go through the trouble of a) calculating maximum leakage b) doubling physical memory instead of just fixing the leaks? Was it to save cycles? Prevent memory fragmentation? I feel this story misses the details that would make it more than just a cute anecdote.

I feel the same way too, dunno why the down votes? In the absence of all other details it just seems like shoddy work, but of course reality is probably more nuanced ... which is what's missing from the story.

Re: Does memory leak? (1995)

#55

Post by pietrovismara »

swalsh wrote: post #12
DagAgren wrote: post #10

What a cute story about writing software to kill people by shredding them with shrapnel.

What if the bomb is landing on someone who intends to kill you?

Have you watched Minority Report? What could go wrong with preemptively punishing crimes!

Re: Does memory leak? (1995)

#56

Post by bathtub365 »

H8crilA wrote: post #26
ptero wrote: post #23

Earlier quoted context omitted.

In a perfect world, yes. But in a hard real time system (and much of missile control will likely be designed as such), timing may be the #1 focus. That is, making sure that events are handled in at most X microseconds or N CPU cycles. In such cases adding GC may open a new can of worms. I agree that in general leaking resources is bad, but sometimes it is good enough by a large margin. Just a guess.

It would be an acceptable solution if the memory supply would vastly outsize the demand, by over an order of magnitude. For example if the program never needed more than 100MiB and you'd install 1GiB or 10GiB. 10GiB is still nothing compared to the cost of the missile, and you get the benefit of truly never worrying about the memory management latency. My favorite trick to optimizing some systems is to see if I can m…

What’s your rationale for picking an order of magnitude instead of, say, double?

Re: Does memory leak? (1995)

#57

Post by cushychicken »

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…

I recently interviewed, and was offered a job at, Draper Labs in Cambridge MA.

The technical work was super interesting. Everyone I spoke to was plainly super sharp, and not morally bankrupt. I fielded similar moral concerns as you, but truthfully, I don't really have much of a personal ethical problem with it. I was a little more concerned at having to explain it to all of my friends, many of whom are substantially more liberal leaning in political views than I am.

Perception, and the pay cut I'd have to take from my current work, ended up being the major things that stopped me from taking it.

Re: Does memory leak? (1995)

#58

Post by willvarfar »

geophile wrote: post #51

The problem, of course, is that the chief software engineer doesn't appear to be have any understanding of what is causing the leaks, and whether the safety margin is adequate. Maybe there is some obscure and untested code path in which leaking would be much faster than anticipated. To be sure, it is a unique environment, in which you know for a fact that your software does not need to run beyond a certain point in t…

You are reading a lot into a short story. You don’t know that the engineer hasn’t had someone exactly calculate the memory allocations.

Static or never-reclaimed allocations are common enough in embedded code.

Re: Does memory leak? (1995)

#60

Post by StupidOne »

FreeFull wrote: post #28
kleiba wrote: post #17

Seems a bit unlikely to me. Intuitively, calculating how much memory a program will leak in the worst case should be at least as much effort as fixing the memory leaks. And if you actually calculated (as in, proved) the amount of leaked memory rather than just by empirically measuring it, there's no need to install double the amount of physical memory. This whole procedure appears to be a bit unbelievable. And we're…

A memory allocator without the ability to free memory is a lot simpler and faster. Usually though, I'd expect to see static allocation for this sort of code, I'm not sure why a missile would have to allocate more memory on the fly.

Because he needed more memory mid-air? :)

Not sure was it pun or no pun intended, but you gave me a good laugh.

Post reply on HN