[llvm] r312582 - Revert "[Decompression] Fail gracefully when out of memory"

[David Blaikie via llvm-commits]

On Fri, Sep 8, 2017 at 1:24 PM Kostya Serebryany <kcc at google.com> wrote:

>
>> I'm not sure I understand what you mean.
>>
>> It seems unfortunate to me to build fixed memory limits into programs -
>> it's nice if they scale up with bigger inputs and more memory on the
>> machine to do more of whatever it is they do - only limited by the memory
>> available on the machine, not some fixed limit in the program.
>>
>> If this means making programs robust to allocation failure (failing
>> gracefully rather than 'crashing') for them to be fuzzable - that seems, to
>> me at least, an OK tradeoff.
>>
>
> This is subtle, but let me try again.
> 1. IMHO any code that tries to recover from malloc (or new!!) returning
> nullptr is much more complicated than adding an artificial limit as a flag
> (by default the flag could be arbitrarily large).
>

By 'recover' I'd be OK with "exits with an error code", so not too complex,
hopefully.

I feel like plumbing through flags with bounds into every
program/allocation is a bit burdensome/awkward/uncommon. Maybe other folks
have other ideas/perspectives & I'm off in the weeds.


> It's also much harder to test.
> 2. malloc is not guaranteed to return nullptr even in cases when there is
> actually not enough memory. It may instead return something backed by swap
> and this can easily kill your machine.
>

Sure enough - though I'm not sure adding a flag to every program is going
to be a real path forward for protecting processes from user input. I'd
expect to use OS level protections for memory limits, etc, there.

- Dave


>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170908/b91cf7d0/attachment.html>