[llvm-bugs] [Bug 30409] New: valgrind reports use of uninitialized memory in clang::Preprocessor::HandleEndOfFile() in my tool

[via llvm-bugs]

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

            Bug ID: 30409
           Summary: valgrind reports use of uninitialized memory in
                    clang::Preprocessor::HandleEndOfFile() in my tool
           Product: new-bugs
           Version: 3.9
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: s3rvac at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

I use Clang to build my own tools that analyze C files. When using includes and
libraries from the official Clang 3.9 build for Debian 8
(http://llvm.org/releases/3.9.0/clang+llvm-3.9.0-x86_64-linux-gnu-debian8.tar.xz),
valgrind reports uses of uninitialized memory:

Conditional jump or move depends on uninitialised value(s)
  at 0xE47439: clang::Preprocessor::HandleEndOfFile(clang::Token&, bool)
  by 0xE0DCAE: clang::Lexer::LexEndOfFile(clang::Token&, char const*)
  by 0xE0EC52: clang::Lexer::LexTokenInternal(clang::Token&, bool)
  by 0xE67DA3: clang::Preprocessor::Lex(clang::Token&)
  by 0x679D12: clang::Parser::ConsumeBrace()
  by 0x67F6EC: clang::BalancedDelimiterTracker::consumeClose()
  by 0x6FAA3E: clang::Parser::ParseCompoundStatementBody(bool)
  by 0x6FB175: clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&)
  by 0x67DA6A:
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*)
  by 0x691792: clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned
int, clang::SourceLocation*, clang::Parser::ForRangeInit*)
  by 0x67CA59:
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier)
  by 0x67C4A7:
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier)

I have a fully updated Debian Jessie (x86_64) with GCC 4.9.2 on Intel Xeon CPU
E5-2680 v3.

To obtain a more specific info, I managed to build Clang 3.9 from source
(http://llvm.org/releases/3.9.0/llvm-3.9.0.src.tar.xz +
http://llvm.org/releases/3.9.0/cfe-3.9.0.src.tar.xz) with debug info:

$ cmake .. -DCMAKE_INSTALL_PREFIX:PATH=/clang-3.9
-DCMAKE_BUILD_TYPE=RelWithDebInfo

Then, I created the following minimal example that shows the problem. It is a
shortened version of an official example
(http://clang.llvm.org/docs/RAVFrontendAction.html):

#include <memory>
#include <clang/AST/ASTConsumer.h>
#include <clang/Frontend/CompilerInstance.h>
#include <clang/Tooling/Tooling.h>

using namespace clang;

struct MyAction: public ASTFrontendAction {
  virtual std::unique_ptr<ASTConsumer> CreateASTConsumer(
      CompilerInstance &, llvm::StringRef) override {
    return std::make_unique<ASTConsumer>();
  }
};

int main() {
  tooling::runToolOnCode(new MyAction, "int main() { return 0; }");
}

After I build the example:

$ g++ test.cpp -o test -std=c++14 -fno-rtti -D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-I/clang-3.9/include -L/clang-3.9/lib -lclangFrontendTool -lclangFrontend
-lclangDriver -lclangSerialization -lclangCodeGen -lclangParse -lclangSema
-lclangStaticAnalyzerFrontend -lclangStaticAnalyzerCheckers
-lclangStaticAnalyzerCore -lclangAnalysis -lclangARCMigrate
-lclangRewriteFrontend -lclangRewrite -lclangEdit -lclangTooling -lclangAST
-lclangLex -lclangBasic `/clang-3.9/bin/llvm-config --libs --system-libs`

I get the following output when I run the program via valgrind. Notice that it
contains line numbers and also the origins of the uninitialized memory:

$ valgrind --track-origins=yes ./test

Conditional jump or move depends on uninitialised value(s)
   at 0xE1A7BC: clang::Preprocessor::HandleEndOfFile(clang::Token&, bool)
(PPLexerChange.cpp:467)
   by 0xDDDC37: clang::Lexer::LexEndOfFile(clang::Token&, char const*)
(Lexer.cpp:2568)
   by 0xDDFBA9: clang::Lexer::LexTokenInternal(clang::Token&, bool)
(Lexer.cpp:2969)
   by 0xE3AFD3: clang::Preprocessor::Lex(clang::Token&) (Preprocessor.cpp:728)
   by 0x674AC2: clang::Parser::ConsumeBrace() (Parser.h:418)
   by 0x679E27: clang::BalancedDelimiterTracker::consumeClose()
(RAIIObjectsForParser.h:430)
   by 0x6F819E: clang::Parser::ParseCompoundStatementBody(bool)
(ParseStmt.cpp:1035)
   by 0x6F8885: clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) (ParseStmt.cpp:1951)
   by 0x6785EC:
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*)
(Parser.cpp:1173)
   by 0x68D43D: clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned
int, clang::SourceLocation*, clang::Parser::ForRangeInit*) (ParseDecl.cpp:1791)
   by 0x67775A:
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier) (Parser.cpp:940)
   by 0x677197:
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier) (Parser.cpp:956)
 Uninitialised value was created by a heap allocation
   at 0x4C29180: operator new(unsigned long) (vg_replace_malloc.c:324)
   by 0x42B92D:
clang::CompilerInstance::createPreprocessor(clang::TranslationUnitKind)
(CompilerInstance.cpp:312)
   by 0x40B294:
clang::FrontendAction::BeginSourceFile(clang::CompilerInstance&,
clang::FrontendInputFile const&) (FrontendAction.cpp:313)
   by 0x42F82B: clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(CompilerInstance.cpp:866)
   by 0xC142A8:
clang::tooling::FrontendActionFactory::runInvocation(clang::CompilerInvocation*,
clang::FileManager*, std::shared_ptr<clang::PCHContainerOperations>,
clang::DiagnosticConsumer*) (Tooling.cpp:310)
   by 0xC1411C: clang::tooling::ToolInvocation::runInvocation(char const*,
clang::driver::Compilation*, clang::CompilerInvocation*,
std::shared_ptr<clang::PCHContainerOperations>) (Tooling.cpp:285)
   by 0xC136F1: clang::tooling::ToolInvocation::run() (Tooling.cpp:270)
   by 0xC12A59: clang::tooling::runToolOnCodeWithArgs(clang::FrontendAction*,
llvm::Twine const&, std::vector<std::string, std::allocator<std::string> >
const&, llvm::Twine const&, llvm::Twine const&,
std::shared_ptr<clang::PCHContainerOperations>,
std::vector<std::pair<std::string, std::string>,
std::allocator<std::pair<std::string, std::string> > > const&)
(Tooling.cpp:155)
   by 0xC1257D: clang::tooling::runToolOnCode(clang::FrontendAction*,
llvm::Twine const&, llvm::Twine const&,
std::shared_ptr<clang::PCHContainerOperations>) (Tooling.cpp:107)
   by 0x4084BE: main (in test)

I was also able to reproduce this exact problem when:
* I use Clang 3.8 instead of GCC 4.9.2 to build the example on Debian Jessie
(x86_64).
* I use GCC 6.2.1 to build the example on a completely different machine with a
fully updated Arch Linux (x86_64).

-- 
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/20160916/1d83b52f/attachment.html>