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

[Gabor Kozar]

Okay, that makes more sense. But it does not explain why we're getting
crashes for all kinds of normal integers as well: int, unsigned int,
unsigned long, double - just to name a few I checked manually. None of
them had anything special about them, some of them were even literals.



Unfortunately, the source code is internal and I cannot share it. But
the parts that have been causing the crashes are completely
uninteresting, absolutely nothing special going on. Also, the same
checker code works perfectly on my dev machine.



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





On Mon, Oct 21, 2013, at 20:39, Richard Smith wrote:

On Mon, Oct 21, 2013 at 7:08 AM, Gabor Kozar <[1]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
[2]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
[3]kozargabor at gmail.com



_______________________________________________

cfe-dev mailing list

[4]cfe-dev at cs.uiuc.edu

[5]http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

References

1. mailto:kozargabor at gmail.com
2. mailto:kozargabor at gmail.com
3. mailto:kozargabor at gmail.com
4. mailto:cfe-dev at cs.uiuc.edu
5. 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/1aa03239/attachment.html>