Brendan (btrotter.delete@this.gmail.com) on January 18, 2020 2:15 pm wrote:
> Fine. I hereby formally submit FireFox as an example of a piece of software that doesn't handle all
> allocation failures gracefully. My evidence includes hundreds of pages of crash reports despite developers
> putting an overwhelming amount of effort into failing to solve problems that were caused by:
>
> a) overcommit masking symptoms of idiotic "continually increasing
> without limit resource consumption" design decisions
>
> b) overcommit creating an attitude of "can't justify the hassle of dealing with allocation
> failures' in some developers, leading to parts of the software being shit (e.g. not
> passing failure up the call chain to a point where the user can be informed "Sorry,
> not enough memory to do that" without screwing everything else up/crashing).

Alright, now I see your point: I'm holding it wrong.

> It's entirely possible, you just refuse to try.
>
> Lets's look at a piece of "my" evidence (the first crash log in the list): https://crash-stats.mozilla.com/report/index/ed62286b-ccd3-4d3f-b8d3-5d4a00200108
>
> The bottom of the page shows about 20 places that could have caught a "std::bad_alloc";
> where you are able to choose any of those ~20 places (wherever is most convenient)
> to handle the allocation failure instead of crashing.

See the name of the class at the top of the stack? It's called AutoEnterOOMUnsafeRegion because it's used by the GC to handle parts of its run where it can't recover from an OOM - it usually can but it's not always possible. A compacting generational GC sometimes need to allocate memory to be able to make forward progress and the heap is in such a state that a failure is not recoverable.

Also, funky datapoint: there's a memory report attached to that crash report and it indicates that the resident set is 88,61MiB. Does that fit your definition of a resource hog? It's also a perfect example of the limitations of Windows: with 271 MiB free physical memory it cannot satisfy a 256 bytes allocation for a process that's using 88 MiB.

> Look at https://hg.mozilla.org/releases/mozilla-release/annotate/501aef7fe1d9622236600a7e53843d40d163a123/ipc/glue/MessagePump.cpp#l238
>
> That line of code is handling errors already!
>
> Where is the most convenient place to handle the error? I don't know (I'm not spending several
> months getting familiar with your codebase and it's very likely that it's not quite as simple
> as slapping a "try/catch" somewhere), but don't try to pretend it's impossible.

If it were at all possible would we have developed an entire new language to deal with that?

> Sure; and vehicle manufacturers should avoid this "flaw" by installing petrol/gas gauges that lie
> and tell you it can provide the resources to reach the next town causing you to end up stranded on
> the highway between towns; and banks should avoid this "flaw" by telling customers they have lots
> of money in their account causing customers to go bankrupt because they bought things they can't afford;
> and restaurants should avoid this "flaw" by lying and tell customers they have plenty of meat to sell
> and then when they find out they don't they should randomly select a customer to butcher.

I think there must be a variant of Godwin's law for making car analogies in IT discussion threads.

> If a site leaks or holds onto too much data, a browser can tell the user "Sorry, this one
> page had to be closed (or maybe frozen/paused) because it leaks or holds onto too much data
> (and the OS can't provide it, and there's no previously cached data to discard)".

You just described exactly how Firefox behaves in that scenario.

> No; but I would blame them if they crash because they've failed to handle allocation failures.

OK, I gather from your arguments that this is an acceptable way of dealing with OOM crashes:

type* foo;
if (!(foo = malloc(sizeof(type)))) {
  fprintf(stderr, "OMG, we're out of memory!");
  abort();
}

But Firefox - which does precisely that and even manages to gather a minidump when that happens - is not handling OOMs correctly?

> I'm not sure if/where I said FireFox doesn't go to these lengths, but it sounds like something
> I might've said before I found out more about Firefox; so if I was wrong and should've said
> something more like "FireFox is a bad because it does go to extraordinary lengths to prevent
> OOM that are proven to be ineffective by 100+ pages of crash reports" then I apologize.

Ah, but our Linux and macOS builds doesn't seem to be affected by that particular problem. I wonder what's different on Windows.