Live data from Hacker News

Does memory leak? (1995)

groups.google.com

251–260 of 289 posts

Re: Does memory leak? (1995)

#251
post #233
post #196

Earlier quoted context omitted.

I think developing defense mechanisms against Slaughterbot attacks is a good idea, because certainly they will happen sooner or later. If the best defense mechanism is killing the ones launching the attacks, we will see several significant consequences: 1. Power will only be exercised by the anonymous and the reckless; government transparency will become a thing of the past. If killing the judge who ruled against you…

You paint a bleak future. Keep in mind though, there have been many dark moments in human history when a lot of people got killed for very bad reasons, and yet here we are. is as easy and anonymous as buying porn on Amazon I'm not sure ease of use is such a game changer. You can buy a drone today, completely anonymously, strap some explosives to it, remotely fly it into someone and detonate it, a few hundred yards aw…

> CIA drone strikes all over the world

The US is known to have carried out drone strikes in Afghanistan, Yemen (including against US citizens), Pakistan, Libya, and Somalia; authority over the assassination program was officially transferred from the CIA to the military by Obama. That leaves another 200-plus countries whose citizens do not yet know the feeling of helpless terror when the car in front of you on the highway explodes into a fireball unexpectedly, presaged only by the far-off ripping sound of a Reaper on the horizon, just like most days. The smaller drones that make this tactic affordable to a wider range of groups will give no such warning.

> It’s much easier to defend soldiers against tiny drones than against heavy fire.

Daesh used tiny drones against soldiers with some effectiveness, but there are several major differences between autonomous drones and heavy fire. First, heavy fire is expensive, requiring either heavy weapons or a large number of small arms. Second, autonomous drones (which Daesh evidently did not have) can travel a lot farther than heavy fire; the attacker can target the soldiers’ families in another city rather than the soldiers themselves, and even if they are targeting the soldiers directly, they do not need to expose themselves to counterattack from the soldiers. Third, almost all bullets miss, but autonomous drones hardly ever need to miss; like a sniper, they can plan for one shot, one kill.

You may be thinking of the 5 m/s quadcopters shown in the Slaughterbots video, but there’s no reason for drones to move that slowly. Slingshot stones, arrows from bows, and bottle-rockets all move on the order of 100 m/s, and you can stick guidance canards on any of them, VAPP-style.

> If you don’t know who your enemy is, say terrorists mixed in the crowd of civilians, how would face detection help you?

Yes, it’s true that if your enemy is protected by anonymity, face-recognition drones are less than useful — that’s why the first step in my scenario is the end of any government transparency, because the only people who can govern in that scenario (in the Westphalian sense of applying deadly force with impunity) are anonymous terrorists. But if the terrorists know who their victims are, the victims cannot protect themselves by mixing into a crowd of civilians.

> Yes, terrorists and evil governments will keep murdering people just like they always have. No, this technology does not make it fundamentally easier.

Well, on the battlefield it definitely will drive down the cost per kill, even though it hasn’t yet. It’s plausible to think that it will drive down the cost per kill in scenarios of mass political killing, as I described above, but you might be right that it won’t.

The two really big changes, though, are not about making killing easier, but about making killing more persuasive, for two reasons. ① It allows the killing to be precisely focused on the desired target, for example enabling armies to kill only the officers of the opposing forces, only the men in a city, or only the workers at a munitions plant, rather than everybody within three kilometers; ② it allows the killing to be truly borderless, so that it’s very nearly as easy to kill the officers’ families as to kill the officers — but only the officers who refuse to surrender.

You say “evil governments”, but killing people to break their will to continue to struggle is not limited to some subset of governments; it is the fundamental way that governments retain power in the face of the threat of invasion.

Covering a city with nets is surprisingly practical, given modern materials like Dyneema and Zylon, but not effective against all kinds of drones. I agree that underground fortresses and off-planet camps cannot save very many people, but perhaps they can preserve some seed of human civilization.

Re: Does memory leak? (1995)

#252
post #12

Earlier quoted context omitted.

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!

This is a strawman. Nobody uses missiles for law enforcement, the very idea is ridiculous. Presumably the

> person who intends to kill you

in this context is a terrorist hiding a cave somewhere, or a certain Iranian general. Now, it's definitely debatable if those striking those targets is morally correct (and I usually don't believe that it is), but it's silly to equate a military strike with the type of law enforcement seen in Minority Report.

Re: Does memory leak? (1995)

#253

Earlier quoted context omitted.

> On the rust side, it's that, plus the pointer must point to a valid region of memory (non-null) even if the slice is empty. Do you have a citation for that, because it seems obviously wrong[0] (since the slice points to zero bytes of memory) and I'm having trouble coming up with any situation that would justify it (except possibly using a NULL pointer to indicate the Nothing case of a Maybe datum)? 0: by which I me…

Well the docs have this to say [1]: `data` must be non-null and aligned even for zero-length slices. One reason for this is that enum layout optimizations may rely on references (including slices of any length) being aligned and non-null to distinguish them from other data. You can obtain a pointer that is usable as data for zero-length slices using NonNull::dangling(). So yes, this requirement allows optimizations l…

> [1] https://doc.rust-lang.org/std/slice/fn.from_raw_parts.html

Thanks.

> having Option be the same size as &[T]

That is literally what I mentioned as a possible reason ("except possibly ..."), but what I overlooked was that you could take a mutable reference to the &[T] inside a Option, then store a valid &[T] into it - if NULL is allowed, you effectively mutated the discriminant of a enum when you have active references to its fields, violating some aspect of type/memory safety, even I'm not sure which.

> C generally chooses NULL, Rust happens to choose a different value.

It's not about what pointer value the langauge chooses when it's asked to create a zero-length slice, it's about whether the language accepts a NULL pointer in a zero-length slice it finds lying around somewhere.

Re: Does memory leak? (1995)

#254

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…

Cleaning up memory is an antipattern for many tools , especially of the EVA/IPO model (input-process-output). For example, cp(1) in preserve hard links mode has to keep track of things in a table; cleaning it up at the end of the operation is a waste of time. Someone "fixed" the leak to make valgrind happy and by doing so introduced a performance regression. Another example might be a compiler; it's pointless to deal…

> Another example might be a compiler; it's pointless to deallocate all your structures manually before calling exit().

And now the compiler can no longer be embedded into another application, e.g. an IDE.

It's a reasonably pragmatic way of thinking, but beware the consequences. One benefit of working with custom allocators is that you can have the best of both worlds. Unfortunately, custom allocators are clumsy to work with.

Re: Does memory leak? (1995)

#255
post #11

Earlier quoted context omitted.

There's a middle ground. Eg the classic Unix 'cat' (ignoring all the command line switches) does something really simple and re-usable, so it makes sense to make sure it does the Right Thing in all situations.

I mean, 'cat' does something so simple (apply the identity function to the input) that it has no need to be reusable because there's no point using it in the first place. If you have input, processing it with cat just means you wasted your time to produce something you already had.

In addition to what the other commenters pointed out about cat being able to concatenate, even using cat as the identity function is useful. Just as the number zero is useful.

Re: Does memory leak? (1995)

#256
post #11

Earlier quoted context omitted.

There's a middle ground. Eg the classic Unix 'cat' (ignoring all the command line switches) does something really simple and re-usable, so it makes sense to make sure it does the Right Thing in all situations.

For sure, if you can apply a small amount of effort for a high probability of easy re-usability, do it. But if you start going off into weird abstract design land to solve a problem you don't have yet, while it might be fun, probably you should stop. At least if it is a real production thing you are working on.

I guess it depends a bit on the shape of your abstract design land. Sometimes it can give you hints about how your API should look like, or what's missing.

Re: Does memory leak? (1995)

#257

Earlier quoted context omitted.

I think you are conflating two issues: while one should understand who owns what and for how long, it does not follow that one should always free resources even when it is not necessary, if doing so adds complexity and therefore more things to go wrong, or if it makes things slower than optimal. In this particular case, correctness was not primarily assured by a massive amount of testing (though that may have been do…

I feel like I've read about some rocket launch failures that were caused in part by launch delays leading to overflow and sign flipping, but can't find it now =/ It may be unwise to overide static analysis (a leak is found) with hueristics (the program won't run long enough to matter)

Possibly the Ariane 5 failure?

https://en.m.wikipedia.org/wiki/Cluster_(spacecraft)#Launch_...

Re: Does memory leak? (1995)

#258

Earlier quoted context omitted.

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 exis…

> Why not static allocation, but sharing memory between the greedy chunks of code that can't run parallel to each other?

That's what I wanted to say with my comment actually.

Re: Does memory leak? (1995)

#259

Earlier quoted context omitted.

Cleaning up memory is an antipattern for many tools , especially of the EVA/IPO model (input-process-output). For example, cp(1) in preserve hard links mode has to keep track of things in a table; cleaning it up at the end of the operation is a waste of time. Someone "fixed" the leak to make valgrind happy and by doing so introduced a performance regression. Another example might be a compiler; it's pointless to deal…

> Another example might be a compiler; it's pointless to deallocate all your structures manually before calling exit(). And now the compiler can no longer be embedded into another application, e.g. an IDE. It's a reasonably pragmatic way of thinking, but beware the consequences. One benefit of working with custom allocators is that you can have the best of both worlds. Unfortunately, custom allocators are clumsy to w…

Solve the problem you have now, not the problem you may not have later. You can worry about that when the time comes, if it ever comes.

In the case of compiler, one solution would be to replace all calls to `malloc` with something like `ccalloc` that simply returns pieces of a `realloc`'d buffer which is freed after the in-IDE compiler has finished compiling.

Re: Does memory leak? (1995)

#260
post #25
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…

>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. Why? I could calculate the average amount of leaking of a program much easier than I could find all the leaks. Calculating just involves performing a typical run under valgrind and seeing how much was never freed. Do that N times and average. Finding the leaks is much more invo…

Did you read in my original post the distinction between calculating and measuring a leak?
Post reply on HN