[llvm-bugs] [Bug 45304] New: clang crashes (SIGSEGV) in clang::TypeLoc::findNullabilityLoc()

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Mar 25 10:47:31 PDT 2020


https://bugs.llvm.org/show_bug.cgi?id=45304

            Bug ID: 45304
           Summary: clang crashes (SIGSEGV) in
                    clang::TypeLoc::findNullabilityLoc()
           Product: clang
           Version: unspecified
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: hanauska at equinux.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org,
                    neeilans at live.com, richard-llvm at metafoo.co.uk

Created attachment 23279
  --> https://bugs.llvm.org/attachment.cgi?id=23279&action=edit
Crash Info

I know that Apple is shipping customized versions of clang in Xcode, yet this
issue doesn't seem Apple clang specific as I doubt Apple has touched the
related files in their release.

I can reproducible crash clang with EXC_BAD_ACCESS (SIGSEGV) when compiling an
Objective-C file. It crashes at 

0x00000001098130c1 clang::TypeLoc::findNullabilityLoc() const + 49
(clang load address was 0x10619b000)

See attached file for more details and full call stack.

clang --version identifies it as:
Apple clang version 11.0.3 (clang-1103.0.32.29)

I reported that issue to Apple already when they released the first Xcode 11.4
beta. I updated the bug withe the two betas to follow. There was never any
reaction and now Apple has released Xcode 11.4 final and it still contains a
clang with that problem.

I fail to create a minimal test case and I must not upload the original source
files in public. Also I think there might be issues with the code, yet even
with issues in code, a compiler shouldn't crash, should it?

Apparently the crash won't happen if I remove all
"__attribute__((ns_returns_retained))" from the source files, despite the fact
that these are set correctly (C functions that indeed return objects that
require releasing).

Other information that may be relevant:

- All source files are wrapped in between 
#pragma clang assume_nonnull begin 
and 
#pragma clang assume_nonnull end

- Automatic Reference Counting is active

- The retained object by the C functions mentioned above is always of the type:
id<SomeProtocol> and can never be NULL.

I shared the source code with Apple but as there it isn't public. Let me know
what else you need; as long as it's not the source code itself, I can probably
provide it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200325/a5fa599f/attachment.html>


More information about the llvm-bugs mailing list