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

[Richard Smith]

On Mon, Oct 21, 2013 at 7:08 AM, Gabor Kozar <kozargabor at gmail.com> wrote:

> **
> 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?
>

TypeClass is not Enum here (if it were, we'd hit the 'case Type::Enum:'
below) -- we're visiting the integral type for the enum type, and *that* is
dependent. What source code are you analyzing here?

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
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131021/f1e0fbd7/attachment.html>