[microsoft] clang crashes while trying to print an error message about mangling #14356

nico · 2012-10-01T11:30:05Z


Bugzilla Link	13984
Resolution	FIXED
Resolved on	Sep 07, 2015 01:32
Version	unspecified
OS	All
Blocks	#12849
Attachments	repro
CC	@majnemer,@DougGregor,@rnk,@timurrrr

Extended Description

Run

clang -cc1 -triple i686-pc-win -S -fms-extensions -cxx-abi microsoft test/CodeGenCXX/mangle-ms-uuidof.cpp

Expected: Prints "Cannot mangle this yet"
Actual: Crash.

Looks related to r160667.

Nicos-MacBook-Pro:clang thakis$ ~/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/clang -cc1 -triple i686-pc-win -S -fms-extensions -cxx-abi microsoft test/CodeGenCXX/mangle-ms-uuidof.cpp
0 clang 0x000000010166c525 PrintStackTrace(void*) + 37
1 clang 0x000000010166c8e4 SignalHandler(int) + 500
2 libsystem_c.dylib 0x00007fff8ef8e8ea _sigtramp + 26
3 libsystem_c.dylib 0x000000010285ca00 _sigtramp + 18446603342454776112
4 clang 0x0000000100ac9515 clang::TemplateArgumentLoc::getSourceRange() const + 53
5 clang 0x0000000100a94228 (anonymous namespace)::MicrosoftCXXNameMangler::mangleTemplateArgs(llvm::SmallVectorImplclang::TemplateArgumentLoc const&) + 200
6 clang 0x0000000100a93156 (anonymous namespace)::MicrosoftCXXNameMangler::mangleUnqualifiedName(clang::NamedDecl const*, clang::DeclarationName) + 2678
7 clang 0x0000000100a92e8e (anonymous namespace)::MicrosoftCXXNameMangler::mangleUnqualifiedName(clang::NamedDecl const*, clang::DeclarationName) + 1966
8 clang 0x0000000100a92553 (anonymous namespace)::MicrosoftCXXNameMangler::manglePostfix(clang::DeclContext const*, bool) + 227
9 clang 0x0000000100a8f8be (anonymous namespace)::MicrosoftCXXNameMangler::mangleName(clang::NamedDecl const*) + 126
10 clang 0x0000000100a8ee84 (anonymous namespace)::MicrosoftCXXNameMangler::mangle(clang::NamedDecl const*, llvm::StringRef) + 340
11 clang 0x0000000100a8e6ab (anonymous namespace)::MicrosoftMangleContext::mangleName(clang::NamedDecl const*, llvm::raw_ostream&) + 251
12 clang 0x00000001002c3f95 clang::CodeGen::CodeGenModule::getMangledName(clang::GlobalDecl) + 773
13 clang 0x00000001002c8822 clang::CodeGen::CodeGenModule::GetAddrOfFunction(clang::GlobalDecl, llvm::Type*, bool) + 82
14 clang 0x0000000100245595 clang::CodeGen::CodeGenFunction::EmitCXXMemberCallExpr(clang::CXXMemberCallExpr const*, clang::CodeGen::ReturnValueSlot) + 2549
15 clang 0x0000000100239e94 clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*, clang::CodeGen::ReturnValueSlot) + 676
16 clang 0x0000000100263114 (anonymous namespace)::ScalarExprEmitter::VisitCallExpr(clang::CallExpr const*) + 132
17 clang 0x000000010025d849 clang::StmtVisitorBase<clang::make_ptr, (anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) + 473
18 clang 0x0000000100258590 clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 96
19 clang 0x000000010022c839 clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, clang::CodeGen::AggValueSlot, bool) + 169
20 clang 0x000000010022c78a clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) + 58
21 clang 0x00000001002ad35d clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 381
22 clang 0x00000001002b227b clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) + 251
23 clang 0x00000001002ad809 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 185
24 clang 0x00000001002ad209 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 41
25 clang 0x00000001002bec51 clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 913
26 clang 0x00000001002c7c5d clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl) + 2109
27 clang 0x00000001002c5229 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 249
28 clang 0x00000001002c6977 clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) + 1463
29 clang 0x00000001002cca72 clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 882
30 clang 0x00000001002e6d3f (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 95
31 clang 0x00000001002bb708 clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 168
32 clang 0x00000001002f32d3 clang::ParseAST(clang::Sema&, bool, bool) + 419
33 clang 0x00000001002ba6dc clang::CodeGenAction::ExecuteAction() + 460
34 clang 0x00000001000bdd68 clang::FrontendAction::Execute() + 104
35 clang 0x000000010009210c clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 956
36 clang 0x000000010005b7b7 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3463
37 clang 0x0000000100051bbd cc1_main(char const**, char const**, char const*, void*) + 749
38 clang 0x000000010005805e main + 3134
39 clang 0x00000001000518a4 start + 52

nico · 2012-10-01T11:30:05Z

assigned to @rnk

nico · 2012-10-01T11:31:02Z

timurrrr, looks like some code on the stack was added by you. Ideas?

timurrrr · 2012-10-01T12:57:21Z

Looking at the code, I think for some reason one of the TemplateArgumentLoc #1 has wrong SourceRange set up.
These guys come from the isTemplate function.
In this particular case, the bad data comes from the (Spec != NULL, TSI == NULL) branch (line 400 currently) which was introduced in r158376 by Charles:
400: TemplateArgs.push_back(TemplateArgumentLoc(ArgList[i],
401: TemplateArgumentLocInfo()));

Charles, do you have any idea how to fix this?

timurrrr · 2012-10-01T12:57:42Z

FTR, the diagnostic printing code was written by Charles as well.

llvmbot · 2012-10-01T13:10:34Z

Looking at the code, I think for some reason one of the TemplateArgumentLoc #1
has wrong SourceRange set up.
These guys come from the isTemplate function.
In this particular case, the bad data comes from the (Spec != NULL, TSI ==
NULL) branch (line 400 currently) which was introduced in r158376 by Charles:
400: TemplateArgs.push_back(TemplateArgumentLoc(ArgList[i],
401: TemplateArgumentLocInfo()));

Charles, do you have any idea how to fix this?
I do not. In fact, if I did, I probably wouldn't have passed an empty TemplateArgumentLocInfo to the TemplateArgumentLoc constructor in the first place.

As I recall, the problem is that we don't have source location information--or if we do, it's really hard to get. I remember looking into getting proper source location information before proposing this patch, but I (obviously) didn't find much for this particular case (Spec != NULL && TSI == NULL).

This source location madness should go away anyway once all the template argument manglings are implemented. (It isn't present in the Itanium mangler, where unlike the Microsoft mangler they actually are all implemented.) Maybe the right solution is to work on actually implementing the case demonstrated by Nico :).

Let's run the test case through Visual Studio and see what it produces. I'll get back to you later on that.

timurrrr · 2012-10-01T13:33:16Z

Is there any way to re-write diagnostics like this:
if () {
// Full diagnostic
} else {
// Compact diagnostic
}
?

Otherwise we'll be seeing bugs like this on and on again.

nico · 2012-10-03T16:17:46Z

Something like this makes the crash go away:

 SourceLocation Loc; SourceRange Range;

```
 if (TAL.getLocInfo().getAsExpr()) {
```

   Loc = TAL.getLocation(); Range = TAL.getSourceRange() }
 // Issue a diagnostic.

[...]

     "template argument yet");

 Diags.Report(TAL.getLocation(), DiagID)

```
   << TA.getKind()
```
```
   << TAL.getSourceRange();
```

```
 Diags.Report(Loc, DiagID)
```
```
   << TA.getKind() << Range;
```

…but it prints errors without locations in most cases with that, and it's pretty hacky. Maybe it's better to just implement manglings for more things, and medium term move off of TemplateArgumentLoc to just TemplateArgument (and get locations from elsewhere, e.g. off Exprs, or don't omit them.)

llvmbot · 2012-10-07T05:32:48Z

Something like this makes the crash go away:
 SourceLocation Loc; SourceRange Range;
 if (TAL.getLocInfo().getAsExpr()) {
   Loc = TAL.getLocation(); Range = TAL.getSourceRange() }
 // Issue a diagnostic.
[...]
     "template argument yet");
 Diags.Report(TAL.getLocation(), DiagID)
   << TA.getKind()
   << TAL.getSourceRange();
 Diags.Report(Loc, DiagID)
   << TA.getKind() << Range;
…but it prints errors without locations in most cases with that, and it's
pretty hacky. Maybe it's better to just implement manglings for more things,
and medium term move off of TemplateArgumentLoc to just TemplateArgument (and
get locations from elsewhere, e.g. off Exprs, or don't omit them.)
Well, this is better than crashing ;). I was considering doing something like this myself.

How about we do this for now, and then we can work on implementing more manglings? WDYT?

rnk · 2013-08-03T02:01:52Z

I think this was fixed way back in r177471 by simplifying the diagnostic.

llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021

This issue was closed.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[microsoft] clang crashes while trying to print an error message about mangling #14356

[microsoft] clang crashes while trying to print an error message about mangling #14356

nico commented Oct 1, 2012

nico commented Oct 1, 2012

nico commented Oct 1, 2012

timurrrr commented Oct 1, 2012

timurrrr commented Oct 1, 2012

llvmbot commented Oct 1, 2012

timurrrr commented Oct 1, 2012

nico commented Oct 3, 2012

llvmbot commented Oct 7, 2012

rnk commented Aug 3, 2013

[microsoft] clang crashes while trying to print an error message about mangling #14356

[microsoft] clang crashes while trying to print an error message about mangling #14356

Comments

nico commented Oct 1, 2012

Extended Description

nico commented Oct 1, 2012

nico commented Oct 1, 2012

timurrrr commented Oct 1, 2012

timurrrr commented Oct 1, 2012

llvmbot commented Oct 1, 2012

timurrrr commented Oct 1, 2012

nico commented Oct 3, 2012

llvmbot commented Oct 7, 2012

rnk commented Aug 3, 2013