[cfe-dev] BuiltinType 'unsigned int' causing ASTContext::getTypeInfo to segfault

[Gabor Kozar]

Update: it also crashes on any other builtin type, including int,
double and enums. After realizing that we were building LLVM in release
mode, we rebuilt in in debug, and got a more useful stack trace:



UNREACHABLE executed at
.../llvm-3.3/tools/clang/lib/AST/ASTContext.cpp:1380!



Program received signal SIGABRT, Aborted.

0x00007ffff6af9945 in raise () from .../lib/clangLib/libc.so.6

(gdb) bt full

#0  0x00007ffff6af9945 in raise () from .../lib/clangLib/libc.so.6

No symbol table info available.

#1  0x00007ffff6afaf21 in abort () from .../lib/clangLib/libc.so.6

No symbol table info available.

#2  0x0000000002f93571 in llvm::llvm_unreachable_internal
(msg=0x3836fa0 "Should not see dependent types", file=0x38365a8
".../llvm-3.3/tools/clang/lib/AST/ASTContext.cpp", line=1380)

    at .../llvm-3.3/lib/Support/ErrorHandling.cpp:98

No locals.

#3  0x0000000001d06772 in clang::ASTContext::getTypeInfoImpl
(this=0x7fffffff5e80, T=0x5096460) at
.../llvm-3.3/tools/clang/lib/AST/ASTContext.cpp:1380

        Width = 0

        Align = 8

        __PRETTY_FUNCTION__ = "std::pair<long unsigned int, unsigned
int> clang::ASTContext::getTypeInfoImpl(const clang::Type*) const"

#4  0x0000000001d06677 in clang::ASTContext::getTypeInfo
(this=0x7fffffff5e80, T=0x5096460) at
.../llvm-3.3/tools/clang/lib/AST/ASTContext.cpp:1359

        it = {Ptr = 0x7fffffff6280, End = 0x7fffffff6280}

        Info = {first = 5378736, second = 60216803}

#5  0x00007ffff63c5af3 in clang::ASTContext::getTypeInfo
(this=0x5096460, T=...) at
.../llvm-3.3/tools/clang/include/clang/AST/ASTContext.h:1541

No locals.

#6  0x00007ffff63c5b24 in clang::ASTContext::getTypeSize
(this=0x5096460, T=...) at
.../llvm-3.3/tools/clang/include/clang/AST/ASTContext.h:1546

No locals.



Looking at the Clang source, this is the relevant part:



std::pair<uint64_t, unsigned> ASTContext::getTypeInfoImpl(const Type
*T) const {

  uint64_t Width=0;

  unsigned Align=8;

  switch (T->getTypeClass()) {

#define TYPE(Class, Base)

#define ABSTRACT_TYPE(Class, Base)

#define NON_CANONICAL_TYPE(Class, Base)

#define DEPENDENT_TYPE(Class, Base) case Type::Class:

#include "clang/AST/TypeNodes.def"

    llvm_unreachable("Should not see dependent types"); // CRASH!



However, we know that the TypeClass is Enum, and we also checked
isDependentType(), and it gave us false. So why does Clang still crash
on this?



Thanks!



--
Gábor Kozár -- ShdNx
kozargabor at gmail.com





On Mon, Oct 21, 2013, at 12:58, Gabor Kozar wrote:

Hi,



We're using Clang 3.3.

In a Static Analyzer checker, I'm trying to determine the size of a
Type. I use ASTContext::getTypeSize on it, which works fine... usually.
However, on a certain Suse Linux 11 environment, attempting to do so
causes a segmentation fault inside Clang. Here is the relevant part of
the stack trace:



0  clang-3.3               0x000000000136b592
llvm::sys::PrintStackTrace(_IO_FILE*) + 34

1  clang-3.3               0x000000000136b219

2  libpthread.so.0         0x00007ff45b1e75d0

3  clang-3.3               0x0000000001e3bc4e
clang::ASTContext::getTypeInfo(clang::Type const*) const + 62



The Type passed to it dumps to 'unsigned int' identifier, and is
actually a TypedefType, wrapping a BuiltinType representing unsigned
int. In other environments, this causes no problem.



We have no root access on this system, and the gcc 4.3 is preinstalled
- we have, however, created a fakeroot with gcc 4.7.1 and other
goodies. Unfortunately, we are unable to prevent Clang (and even gcc
4.7.1) from having gcc 4.3's headers in the include path. I do not know
if this is relevant, though - after all, builtin types shouldn't really
be affected by system headers, should they?



So any idea what's going on?



Thanks!



--
Gábor Kozár -- ShdNx
kozargabor at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131021/adf87371/attachment.html>