dwblaikie wrote:
Hit an msan use-of-uninitialized on an internal use case (a tool that uses
Clang via API).
the test was compiling this source code:
```
#include <string>
namespace proto2 {
struct Message {};
} // namespace proto2
struct FakeProto : proto2::Message {
const std::string& getter() const { return str; } // NOLINT
static std::string str;
};
struct S {
S(std::string) {} // NOLINT
};
void UseS(S s) {}
const std::string& foo() {
FakeProto fp;
return fp.getter();
}
void baz() { UseS(foo()); }
std::string s = foo();
```
and failed in this stack:
```
#0 0x7f1da36404cd in NoteFunctionCandidate
third_party/llvm/llvm-project/clang/lib/Sema/SemaOverload.cpp:12113:35
#1 0x7f1da36404cd in
clang::OverloadCandidateSet::NoteCandidates(clang::Sema&,
llvm::ArrayRef<clang::Expr*>, llvm::ArrayRef<clang::OverloadCandidate*>,
llvm::StringRef, clang::SourceLocation)
third_party/llvm/llvm-project/clang/lib/Sema/SemaOverload.cpp:12733:7
#2 0x7f1da3207016 in clang::InitializationSequence::Diagnose(clang::Sema&,
clang::InitializedEntity const&, clang::InitializationKind const&,
llvm::ArrayRef<clang::Expr*>)
third_party/llvm/llvm-project/clang/lib/Sema/SemaInit.cpp:9933:26
#3 0x7f1da31fa0e2 in clang::InitializationSequence::Perform(clang::Sema&,
clang::InitializedEntity const&, clang::InitializationKind const&,
llvm::MutableArrayRef<clang::Expr*>, clang::QualType*)
third_party/llvm/llvm-project/clang/lib/Sema/SemaInit.cpp:8705:5
#4 0x7f1da2704fbe in clang::Sema::AddInitializerToDecl(clang::Decl*,
clang::Expr*, bool)
third_party/llvm/llvm-project/clang/lib/Sema/SemaDecl.cpp:13730:33
#5 0x7f1da58cfea0 in
clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*)
third_party/llvm/llvm-project/clang/lib/Parse/ParseDecl.cpp:2787:17
#6 0x7f1da58c924b in clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&,
clang::DeclaratorContext, clang::ParsedAttributes&,
clang::Parser::ParsedTemplateInfo&, clang::SourceLocation*,
clang::Parser::ForRangeInit*)
third_party/llvm/llvm-project/clang/lib/Parse/ParseDecl.cpp:2480:7
#7 0x7f1da5b06b4d in
clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributes&,
clang::ParsedAttributes&, clang::ParsingDeclSpec&, clang::AccessSpecifier)
third_party/llvm/llvm-project/clang/lib/Parse/Parser.cpp:1249:10
#8 0x7f1da5b058b0 in
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&,
clang::ParsedAttributes&, clang::ParsingDeclSpec*, clang::AccessSpecifier)
third_party/llvm/llvm-project/clang/lib/Parse/Parser.cpp:1271:12
#9 0x7f1da5b0338b in
clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&,
clang::ParsedAttributes&, clang::ParsingDeclSpec*)
third_party/llvm/llvm-project/clang/lib/Parse/Parser.cpp:1074:14
#10 0x7f1da5afe984 in
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&,
clang::Sema::ModuleImportState&)
third_party/llvm/llvm-project/clang/lib/Parse/Parser.cpp:763:12
#11 0x7f1da588c011 in clang::ParseAST(clang::Sema&, bool, bool)
third_party/llvm/llvm-project/clang/lib/Parse/ParseAST.cpp:163:20
#12 0x7f1da743f407 in clang::ASTFrontendAction::ExecuteAction()
third_party/llvm/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1192:3
#13 0x7f1da743dfab in clang::FrontendAction::Execute()
third_party/llvm/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1078:8
```
I realize this isn't exactly repro steps - the <string> included is from
libc++, for what that's worth - I don't /think/ this build is using modules.
But providing this info in case it's sufficient information to diagnose the
issue.
It seems to be the TookAddressOfOverload variable is used-uninitialized
somewhere in this path.
(I don't actually have a clang-built-with-msan to test this further myself at
the moment, but trying to figure out some bootstrapping issues to try to help
narrow it down)
https://github.com/llvm/llvm-project/pull/93430
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
