LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 34309 - Assertion failure in clang::ento::MemRegionManager::getElementRegion()
Summary: Assertion failure in clang::ento::MemRegionManager::getElementRegion()
Status: RESOLVED FIXED
Alias: None
Product: clang
Classification: Unclassified
Component: Static Analyzer (show other bugs)
Version: trunk
Hardware: PC Linux
: P enhancement
Assignee: Alexander Shaposhnikov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-24 06:14 PDT by Alexander Kornienko
Modified: 2017-08-30 06:44 PDT (History)
2 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Kornienko 2017-08-24 06:14:07 PDT
$ cat /tmp/getElementRegion-crash.cc
struct {
  int *n;
  bool f(unsigned &p1) { p1 = (long)n - 1; }
} b;
unsigned a;
int c;
void g() { b.f(a) && a == c; }
$ clang_tidy -checks=-*,clang-analyzer-* /tmp/getElementRegion-crash.cc -- -std=c++11 
assert.h assertion failed at llvm/tools/clang/include/clang/AST/Type.h:628 in const clang::ExtQualsTypeCommonBase *clang::QualType::getCommonPtr() const: !isNull() && "Cannot retrieve a NULL type pointer"
    @          0x53f0f5a  __assert_fail
    @           0x5e9065  clang::QualType::getCommonPtr()
    @           0x5ddbe9  clang::QualType::getCanonicalType()
    @          0x1b4f5cc  clang::ASTContext::getCanonicalType()
    @          0x2c50612  clang::ento::MemRegionManager::getElementRegion()
    @          0x2d07f58  (anonymous namespace)::SimpleSValBuilder::evalBinOpLN()
    @          0x2bbbace  clang::ento::SValBuilder::evalBinOp()
    @          0x2d09ab4  (anonymous namespace)::SimpleSValBuilder::simplifySVal()::Simplifier::VisitSymIntExpr()
    @          0x2d09692  clang::ento::SymExprVisitor<>::Visit()
    @          0x2d093ea  (anonymous namespace)::SimpleSValBuilder::simplifySVal()::Simplifier::VisitNonLocSymbolVal()
    @          0x2d08f6b  clang::ento::SValVisitor<>::Visit()
    @          0x2d0822f  (anonymous namespace)::SimpleSValBuilder::simplifySVal()
    @          0x2d056cc  (anonymous namespace)::SimpleSValBuilder::evalBinOpNN()
    @          0x2bbbd92  clang::ento::SValBuilder::evalBinOp()
    @          0x2cab136  clang::ento::ExprEngine::evalBinOp()
    @          0x2cd8320  clang::ento::ExprEngine::VisitBinaryOperator()
    @          0x2ca0a91  clang::ento::ExprEngine::Visit()
    @          0x2c9dea4  clang::ento::ExprEngine::ProcessStmt()
    @          0x2c9db6a  clang::ento::ExprEngine::processCFGElement()
    @          0x2ccb526  clang::ento::CoreEngine::HandlePostStmt()
    @          0x2ccae23  clang::ento::CoreEngine::dispatchWorkItem()
    @          0x2cca9b8  clang::ento::CoreEngine::ExecuteWorkList()
    @          0x21227d5  clang::ento::ExprEngine::ExecuteWorkList()
    @          0x20cb182  (anonymous namespace)::AnalysisConsumer::ActionExprEngine()
    @          0x20caf41  (anonymous namespace)::AnalysisConsumer::RunPathSensitiveChecks()
    @          0x20cac05  (anonymous namespace)::AnalysisConsumer::HandleCode()
    @          0x20be323  (anonymous namespace)::AnalysisConsumer::HandleDeclsCallGraph()
    @          0x20bc5a7  (anonymous namespace)::AnalysisConsumer::HandleTranslationUnit()
    @          0x29d335e  clang::MultiplexConsumer::HandleTranslationUnit()
Comment 1 Alexander Kornienko 2017-08-24 06:40:05 PDT
This started happening after r310887.
Comment 2 Devin Coughlin 2017-08-24 11:25:05 PDT
Tracking this internally as rdar://problem/34062527
Comment 3 Alexander Shaposhnikov 2017-08-24 13:28:12 PDT
a bit smaller reduced test case:

m.cpp:

bool f(long x, char *p) {
  long y = (long)p - 1;
  return y == x;
}


clang --analyze -c m.cpp

i have an idea what's going on there, but need a bit more time to double check
Comment 4 Alexander Shaposhnikov 2017-08-24 14:11:08 PDT
if i am not mistaken we hit the following FIXME
(in ./lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp at the line 368)

 359     case nonloc::LocAsIntegerKind: {
 360       Loc lhsL = lhs.castAs<nonloc::LocAsInteger>().getLoc();
 361       switch (rhs.getSubKind()) {
 362         case nonloc::LocAsIntegerKind:
 363           return evalBinOpLL(state, op, lhsL,
 364                              rhs.castAs<nonloc::LocAsInteger>().getLoc(),
 365                              resultTy);
 366         case nonloc::ConcreteIntKind: {
 367           // Transform the integer into a location and compare.
 368           // FIXME: This only makes sense for comparisons. If we want to, say,
 369           // add 1 to a LocAsInteger, we'd better unpack the Loc and add to it,
 370           // then pack it back into a LocAsInteger.
 371           llvm::APSInt i = rhs.castAs<nonloc::ConcreteInt>().getValue();
 372           BasicVals.getAPSIntType(Context.VoidPtrTy).apply(i);
 373           return evalBinOpLL(state, op, lhsL, makeLoc(i), resultTy);
 374         }
Comment 5 Alexander Shaposhnikov 2017-08-29 12:46:29 PDT
Resolved by https://reviews.llvm.org/rL311935 and https://reviews.llvm.org/rL311947 .
Comment 6 Alexander Kornienko 2017-08-29 13:08:19 PDT
Thank you! It looks like the fix has introduced another failure though (or didn't fix all cases, since the stack trace looks suspiciously similar). I'm currently reducing the test case and will file a separate issue.
Comment 7 Alexander Shaposhnikov 2017-08-29 13:18:21 PDT
I've reopened this bug.
I guess my old change (where i was fixing a separate issue) has uncovered several new code paths in the static analyzer that's why we see these new crashes.
Comment 8 Alexander Shaposhnikov 2017-08-29 13:21:08 PDT
oh, i see, i didn't read your comment,
yeah, many thanks for building reduced test cases,
then let's file a separate bug report for that.
Comment 9 Alexander Kornienko 2017-08-30 06:44:44 PDT
The other bug is filed as http://llvm.org/PR34374.

Could you also take a look at http://llvm.org/PR34373 ?