[llvm-dev] UBSan, StringRef and Allocator.h

[David Blaikie via llvm-dev]

On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper <peter_cooper at apple.com> wrote:

> Hi all
>
> (No idea if I have the correct audience.  Please CC more people as needed).
>
> I have an UBSan failure in BumpPtrAllocatorImpl.Allocate.
>
> The problem is that lld requests that we StringRef::copy an empty string.
> This passes a length of 0 to a BumpPtrAllocator.  The BumpPtrAllocator
> happened to not have anything allocated yet so the CurPtr is nullptr, but
> given that we need 0 space we think we have enough space and return an
> allocation of size 0 at address nullptr.  This therefore returns nullptr
> from Allocate, but that method is marked
> with LLVM_ATTRIBUTE_RETURNS_NONNULL and LLVM_ATTRIBUTE_RETURNS_NOALIAS,
> both of which aren’t true in this case.
>
> To put this in code, if I have
>
> BumpPtrAllocator allocator;
> StringRef s;
> s.copy(allocator);
>
>
> then i’m going to allocate 0 bytes in the allocator and get a
> StringRef(nullptr, 0).  Its a valid StringRef, but an UBSan failures in the
> allocator.
>
> Lang and I looked up malloc behaviour online as this is fairly analogous.
> The answer there is that you are allowed to return nullptr, or not, its
> implementation defined.  So no help there.
>
> So the question is, how do we want this to behave in our code?
>
> Some options:
> - Assert that Allocate never gets a size 0 allocation.  So fix
> StringRef::copy to see this case
> - Remove the attributes from Allocate but continue to return nullptr (or
> base of the allocator?) in this case
> - Keep the attributes on Allocate and treat size 0 allocations as size 1
>

I believe the last is closer to 'new's behavior - which I think returns a
unique non-null address (well, unique amongst current allocations - can be
recycled once deleted) if I recall correctly. Can check for wording if
that's helpful/desired.


>
> Thanks,
> Pete
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160322/094dcf31/attachment.html>