llvm dev - Nov 2016 - PVS-Studio analysis of LLVM code

On Wed, Nov 2, 2016 at 9:41 AM, Jonas Wagner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello,
>
> I think this should be added by Clang itself.
>
>
> I don't think so. There are several sources online that indicate that
> developers need to *manually* specify std::nothrow. If they don't,
> operator new will throw an exception even if code is compiled with
> -fno-exception. This will abort the program.
>
That's correct. The default new should never return nullptr, even with
-fno-exceptions. It should either succeed, throw an exception, or abort.

At some point, this caused Firefox to replace a bunch of `new`
with
> `new(std::nothrow)` [1] Would this be a good idea in LLVM as well? Or
> should we just let LLVM crash on OOM, and remove the null-checks as PVS
> suggests?
>
LLVM shouldn't replace new with new(std::nothrow), it should just abort.
There's effectively zero chance the codebase will ever be able to recover
from OOMing, and with modern OSes, you're almost never going to actually
see a malloc failure until it's way too late, anyways.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161102/7bdd1abf/attachment.html>

>
> LLVM shouldn't replace new with new(std::nothrow), it should just
abort.
>
Does it? When we were evaluating embedding LLVM a few years back, that was
one of the major pain points for us. Something goes wrong and LLVM/Clang
calls abort, crashing the whole program. Library shouldn't make these type
of decisions lightly: return an error, throw an exception, fire up a smoke
signal - whatever - but there's just not enough context to decide right at
that level.

> There's effectively zero chance the codebase will ever be able to
recover
> from OOMing, and with modern OSes, you're almost never going to
actually
> see a malloc failure until it's way too late, anyways.
>
IMO the best way is to allow user to specify their own allocation strategy
with default fallback to std::new: JITs have bursts of activity between
longer quiet periods and may want to defer memory cleanup until later; IDE
with code completion may want to keep memory consumption in check and
choose to disable whole feature, rather than impede other processes; and so
on.

- Yury
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161103/f01be6c1/attachment.html>

On Thu, Nov 3, 2016 at 12:23 PM, Yury Mikhaylov <yury.mikhaylov at
gmail.com>
wrote:
> LLVM shouldn't replace new with new(std::nothrow), it should just
abort.
>>
> Does it? When we were evaluating embedding LLVM a few years back, that was
> one of the major pain points for us. Something goes wrong and LLVM/Clang
> calls abort, crashing the whole program. Library shouldn't make these
type
> of decisions lightly: return an error, throw an exception, fire up a smoke
> signal - whatever - but there's just not enough context to decide right
at
> that level.
>
I agree you could make that argument for many of the places LLVM uses
assert() today. LLVM uses assert not just in checking invariants, but as an
error handling mechanism.

However, the level of extra complexity that would be required in order to
try to handle *memory allocation failure* is not worth it. Not even close
to worth it. There's only VERY limited classes of programs where that is a
worthwhile thing to try to do (example: PID 1). A compiler library isn't
one of them.

There's effectively zero chance the codebase will ever be able to
recover
>> from OOMing, and with modern OSes, you're almost never going to
actually
>> see a malloc failure until it's way too late, anyways.
>>
> IMO the best way is to allow user to specify their own allocation strategy
> with default fallback to std::new: JITs have bursts of activity between
> longer quiet periods and may want to defer memory cleanup until later; IDE
> with code completion may want to keep memory consumption in check and
> choose to disable whole feature, rather than impede other processes; and so
> on.
>
The global operator new is already overridable per the C++ standard. And,
malloc/free themselves are overridable, in practice, on common systems.
LLVM doesn't need to do anything special to allow users to plug in their
own allocator if they want to.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161103/a2263bcd/attachment.html>