<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - valgrind reports use of uninitialized memory in clang::Preprocessor::HandleEndOfFile() in my tool"
href="https://llvm.org/bugs/show_bug.cgi?id=30409">30409</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>valgrind reports use of uninitialized memory in clang::Preprocessor::HandleEndOfFile() in my tool
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>3.9
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>s3rvac@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>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
(<a href="http://llvm.org/releases/3.9.0/clang+llvm-3.9.0-x86_64-linux-gnu-debian8.tar.xz">http://llvm.org/releases/3.9.0/clang+llvm-3.9.0-x86_64-linux-gnu-debian8.tar.xz</a>),
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
(<a href="http://llvm.org/releases/3.9.0/llvm-3.9.0.src.tar.xz">http://llvm.org/releases/3.9.0/llvm-3.9.0.src.tar.xz</a> +
<a href="http://llvm.org/releases/3.9.0/cfe-3.9.0.src.tar.xz">http://llvm.org/releases/3.9.0/cfe-3.9.0.src.tar.xz</a>) 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
(<a href="http://clang.llvm.org/docs/RAVFrontendAction.html">http://clang.llvm.org/docs/RAVFrontendAction.html</a>):
#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).</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>