ICE in release/9.x when using LLVM_ENABLE_MODULES

modocache · July 29, 2019, 1:40pm

I ran into an LLVM/Clang crash when attempting to do the following:

1. Build Clang from the release/9.x branch source.
2. Use the Clang from (1) to build clangd on the release/9.x branch,
with LLVM_ENABLE_MODULES=On.

I wrote a script to reproduce the crash:

gist.github.com

https://gist.github.com/modocache/ac366ca9673b93bb21e75d3e72162608

out.txt

ninja: Entering directory `/home/modocache/Source/llvm/git/dev/build-s2'
[1/1534] Building CXX object lib/Demangle/CMakeFiles/LLVMDemangle.dir/Demangle.cpp.o
[2/1534] Building CXX object lib/Demangle/CMakeFiles/LLVMDemangle.dir/MicrosoftDemangleNodes.cpp.o
[3/1534] Building CXX object lib/Demangle/CMakeFiles/LLVMDemangle.dir/MicrosoftDemangle.cpp.o
[4/1534] Building CXX object lib/Demangle/CMakeFiles/LLVMDemangle.dir/ItaniumDemangle.cpp.o
[5/1534] Linking CXX static library lib/libLLVMDemangle.a
[6/1534] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/DJB.cpp.o
[7/1534] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.o
[8/1534] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/DAGDeltaAlgorithm.cpp.o
[9/1534] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/FileUtilities.cpp.o

This file has been truncated. show original

repro.sh

#!/usr/bin/env bash

set -x

ROOT_PATH="$HOME/Source/llvm/git/dev"

# Stage 1: Build Clang

rm -rf "$ROOT_PATH/build-s1"
mkdir -p "$ROOT_PATH/build-s1"

This file has been truncated. show original

At the above URL, you'll find a script `repro.sh` that reproduces the
crash, and a file `out.txt` that contains the build output and the
stack trace.

I used the script to bisect, and bisect determined the first "bad" commit was:

The stack trace appears to crash when generating code for an
`llvm::Expected` declaration, and the commit above seems to add a few
of them, so that seems suspicious. The stack trace is in the GitHub
gist URL above, but I'll also paste the relevant portion here:

Stack dump:
0. Program arguments: ...
1. <eof> parser at end of file
2. Per-file LLVM IR generation
3. /home/modocache/Source/llvm/git/dev/llvm-project/llvm/include/llvm/Support/Error.h:625:17:
Generating code for declaration
'llvm::Expected<std::__cxx11::basic_string<char> >::getStorage'
/home/modocache/Source/llvm/git/dev/build-s1/bin/clang-9(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x2a)[0x557bc131549a]
/home/modocache/Source/llvm/git/dev/build-s1/bin/clang-9(_ZN4llvm3sys17RunSignalHandlersEv+0x34)[0x557bc13131b4]
/home/modocache/Source/llvm/git/dev/build-s1/bin/clang-9(+0x1649335)[0x557bc1313335]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x13f40)[0x7f3bc780af40]
/home/modocache/Source/llvm/git/dev/build-s1/bin/clang-9(_ZN5clang7CodeGen15CodeGenFunction18EmitLValueForFieldENS0_6LValueEPKNS_9FieldDeclE+0x8ad)[0x557bc1749abd]

I have an immediate workaround -- I can turn off LLVM_ENABLE_MODULES,
and the crash goes away. However, I think it might be worth looking
into the commit above and determining why it crashes when using
`-fmodules`. At first glance, I don't see the problem, but I've cc'ed
the author, in case they might know more.

Does anyone have any ideas on how to fix the underlying crash?

- Brian Gesiak

ahatanak · July 29, 2019, 5:51pm

This is probably the same failure we’ve been seeing here:

http://green.lab.llvm.org/green/job/clang-stage2-coverage-R/4124/console

But it looks like the bot has turned green since July 19th, so I’m wondering whether you are still seeing the same failure if you use trunk?

If I remember correctly, there was a MemberExpr node in the AST that was referencing the anonymous union in class Expected, but the parent class (class Expected) didn’t contain the AST node for the anonymous union.

Thomas_Preud_homme · July 30, 2019, 8:49am

Hi Brian,

Thanks for letting me know about this. I’ve been able to reproduce the issue thanks to your reproducer and realized there’s some missing include in FileCheck.h, namely for StringRef(“llvm/ADT/StringRef.h”), Expected (“llvm/Support/Error.h”), Optional (“llvm/ADT/Optional.h”) and std::string (). However that does not solve the problem. Still, this warrants a patch in itself IMO. Unsurprisingly, changing all the Expectedstd::string for Expected in FileCheck.h let the compilation proceed but I can see some other uses of Expectedstd::string in headers so that ought not to be a problem. Please find below the backtrace when building the first stage llvm with debug info:

#0 __GI_raise (sig=sig@entry=6) at …/sysdeps/unix/sysv/linux/raise.c:51

#1 0x00007ffff687b801 in __GI_abort () at abort.c:79

#2 0x00007ffff686b39a in __assert_fail_base (fmt=0x7ffff69f27d8 “%s%s%s:%u: %s%sAssertion `%s’ failed.\n%n”,

assertion=assertion@entry=0x55555f5b0b98 “CachedFieldIndex && "failed to find field in parent"”,

file=file@entry=0x55555f5afa88 “/home/thomasp/repos/llvm-project-modules-crash/clang/lib/AST/Decl.cpp”, line=line@entry=3932,

function=function@entry=0x55555f5c3640 <clang::FieldDecl::getFieldIndex() const::PRETTY_FUNCTION> “unsigned int clang::FieldDecl::getFieldIndex() const”) at assert.c:92

#3 0x00007ffff686b412 in __GI___assert_fail (assertion=0x55555f5b0b98 “CachedFieldIndex && "failed to find field in parent"”,

file=0x55555f5afa88 “clang/lib/AST/Decl.cpp”, line=3932,

function=0x55555f5c3640 <clang::FieldDecl::getFieldIndex() const::PRETTY_FUNCTION> “unsigned int clang::FieldDecl::getFieldIndex() const”) at assert.c:101

#4 0x000055555c4e8773 in clang::FieldDecl::getFieldIndex (this=0x55557702a108) at clang/lib/AST/Decl.cpp:3932

#5 0x000055555929e37f in clang::CodeGen::CodeGenFunction::EmitLValueForField (this=0x7fffffff7d70, base=…, field=0x55557702a108)

at clang/lib/CodeGen/CGExpr.cpp:3965

#6 0x000055555929d8cc in clang::CodeGen::CodeGenFunction::EmitMemberExpr (this=0x7fffffff7d70, E=0x555577029f38) at clang/lib/CodeGen/CGExpr.cpp:3853

#7 0x000055555928e20b in clang::CodeGen::CodeGenFunction::EmitLValue (this=0x7fffffff7d70, E=0x555577029f38) at clang/lib/CodeGen/CGExpr.cpp:1346

#8 0x000055555928d636 in clang::CodeGen::CodeGenFunction::EmitCheckedLValue (this=0x7fffffff7d70, E=0x555577029f38, TCK=clang::CodeGen::CodeGenFunction::TCK_MemberAccess)

at clang/lib/CodeGen/CGExpr.cpp:1212

#9 0x000055555929d782 in clang::CodeGen::CodeGenFunction::EmitMemberExpr (this=0x7fffffff7d70, E=0x55557702a2b8) at clang/lib/CodeGen/CGExpr.cpp:3849

#10 0x000055555928e20b in clang::CodeGen::CodeGenFunction::EmitLValue (this=0x7fffffff7d70, E=0x55557702a2b8) at clang/lib/CodeGen/CGExpr.cpp:1346

#11 0x000055555929fb59 in clang::CodeGen::CodeGenFunction::EmitCastLValue (this=0x7fffffff7d70, E=0x55557702a2e8) at clang/lib/CodeGen/CGExpr.cpp:4264

#12 0x000055555928e36b in clang::CodeGen::CodeGenFunction::EmitLValue (this=0x7fffffff7d70, E=0x55557702a2e8) at clang/lib/CodeGen/CGExpr.cpp:1367

#13 0x000055555928d636 in clang::CodeGen::CodeGenFunction::EmitCheckedLValue (this=0x7fffffff7d70, E=0x55557702a2e8, TCK=clang::CodeGen::CodeGenFunction::TCK_MemberAccess)

at clang/lib/CodeGen/CGExpr.cpp:1212

#14 0x000055555929d782 in clang::CodeGen::CodeGenFunction::EmitMemberExpr (this=0x7fffffff7d70, E=0x55557702a380) at clang/lib/CodeGen/CGExpr.cpp:3849

#15 0x000055555928e20b in clang::CodeGen::CodeGenFunction::EmitLValue (this=0x7fffffff7d70, E=0x55557702a380) at clang/lib/CodeGen/CGExpr.cpp:1346

#16 0x00005555592998d5 in clang::CodeGen::CodeGenFunction::EmitArrayToPointerDecay (this=0x7fffffff7d70, E=0x55557702a380, BaseInfo=0x0, TBAAInfo=0x0)

at clang/lib/CodeGen/CGExpr.cpp:3307

#17 0x00005555592de962 in (anonymous namespace)::ScalarExprEmitter::VisitCastExpr (this=0x7fffffff7870, CE=0x55557702a3b0)

at clang/lib/CodeGen/CGExprScalar.cpp:2145

#18 0x00005555592ef299 in clang::StmtVisitorBase<std::add_pointer, (anonymous namespace)::ScalarExprEmitter, llvm::Value*>::VisitImplicitCastExpr (this=0x7fffffff7870, S=0x55557702a3b0)

at tools/clang/include/clang/AST/StmtNodes.inc:859

#19 0x00005555592edb8d in clang::StmtVisitorBase<std::add_pointer, (anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit (this=0x7fffffff7870, S=0x55557702a3b0)

at tools/clang/include/clang/AST/StmtNodes.inc:859

#20 0x00005555592d59c9 in (anonymous namespace)::ScalarExprEmitter::Visit (this=0x7fffffff7870, E=0x55557702a3b0) at clang/lib/CodeGen/CGExprScalar.cpp:424

#21 0x00005555592de09e in (anonymous namespace)::ScalarExprEmitter::VisitCastExpr (this=0x7fffffff7870, CE=0x55557702a3c8)

at clang/lib/CodeGen/CGExprScalar.cpp:2040

#22 0x00005555592d6732 in (anonymous namespace)::ScalarExprEmitter::VisitExplicitCastExpr (this=0x7fffffff7870, E=0x55557702a3c8)

at clang/lib/CodeGen/CGExprScalar.cpp:573

#23 0x00005555592ef759 in clang::StmtVisitorBase<std::add_pointer, (anonymous namespace)::ScalarExprEmitter, llvm::Value*>::VisitCXXNamedCastExpr (this=0x7fffffff7870, S=0x55557702a3c8)

at tools/clang/include/clang/AST/StmtNodes.inc:817

#24 0x00005555592ef227 in clang::StmtVisitorBase<std::add_pointer, (anonymous namespace)::ScalarExprEmitter, llvm::Value*>::VisitCXXReinterpretCastExpr (this=0x7fffffff7870, S=0x55557702a3c8)

at tools/clang/include/clang/AST/StmtNodes.inc:833

#25 0x00005555592edb45 in clang::StmtVisitorBase<std::add_pointer, (anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit (this=0x7fffffff7870, S=0x55557702a3c8)

at tools/clang/include/clang/AST/StmtNodes.inc:833

#26 0x00005555592d59c9 in (anonymous namespace)::ScalarExprEmitter::Visit (this=0x7fffffff7870, E=0x55557702a3c8) at clang/lib/CodeGen/CGExprScalar.cpp:424

#27 0x00005555592eb469 in clang::CodeGen::CodeGenFunction::EmitScalarExpr (this=0x7fffffff7d70, E=0x55557702a3c8, IgnoreResultAssign=false)

at clang/lib/CodeGen/CGExprScalar.cpp:4488

#28 0x0000555558f48431 in clang::CodeGen::CodeGenFunction::EmitReturnStmt (this=0x7fffffff7d70, S=…) at clang/lib/CodeGen/CGStmt.cpp:1097

#29 0x0000555558f4416e in clang::CodeGen::CodeGenFunction::EmitStmt (this=0x7fffffff7d70, S=0x55557702a408, Attrs=…) at clang/lib/CodeGen/CGStmt.cpp:144

#30 0x0000555558f44ddb in clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope (this=0x7fffffff7d70, S=…, GetLast=false, AggSlot=…)

at clang/lib/CodeGen/CGStmt.cpp:386

#31 0x0000555558fc8045 in clang::CodeGen::CodeGenFunction::EmitFunctionBody (this=0x7fffffff7d70, Body=0x55557702a498)

at clang/lib/CodeGen/CodeGenFunction.cpp:1023
#32 0x0000555558fc8caf in clang::CodeGen::CodeGenFunction::GenerateCode (this=0x7fffffff7d70, GD=…, Fn=0x555579b00fc8, FnInfo=…)

at clang/lib/CodeGen/CodeGenFunction.cpp:1188

#33 0x0000555558ff07ad in clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition (this=0x555561837460, GD=…, GV=0x555579b00fc8)

at clang/lib/CodeGen/CodeGenModule.cpp:4295

#34 0x0000555558fe9ad4 in clang::CodeGen::CodeGenModule::EmitGlobalDefinition (this=0x555561837460, GD=…, GV=0x555579b00fc8)

at clang/lib/CodeGen/CodeGenModule.cpp:2740

#35 0x0000555558fe6d11 in clang::CodeGen::CodeGenModule::EmitDeferred (this=0x555561837460) at clang/lib/CodeGen/CodeGenModule.cpp:2118

#36 0x0000555558fe6d5f in clang::CodeGen::CodeGenModule::EmitDeferred (this=0x555561837460) at clang/lib/CodeGen/CodeGenModule.cpp:2124

#37 0x0000555558fe6d5f in clang::CodeGen::CodeGenModule::EmitDeferred (this=0x555561837460) at clang/lib/CodeGen/CodeGenModule.cpp:2124

#38 0x0000555558fddfb9 in clang::CodeGen::CodeGenModule::Release (this=0x555561837460) at clang/lib/CodeGen/CodeGenModule.cpp:393

#39 0x0000555559e08f29 in (anonymous namespace)::CodeGeneratorImpl::HandleTranslationUnit (this=0x555561831d40, Ctx=…)

at clang/lib/CodeGen/ModuleBuilder.cpp:256

#40 0x0000555559e024b8 in clang::BackendConsumer::HandleTranslationUnit (this=0x555561831ab0, C=…) at clang/lib/CodeGen/CodeGenAction.cpp:238

#41 0x000055555b3c274c in clang::ParseAST (S=…, PrintStats=false, SkipFunctionBodies=false) at clang/lib/Parse/ParseAST.cpp:171

#42 0x00005555595bb943 in clang::ASTFrontendAction::ExecuteAction (this=0x55556180d440) at clang/lib/Frontend/FrontendAction.cpp:1035

#43 0x0000555559e0067f in clang::CodeGenAction::ExecuteAction (this=0x55556180d440) at clang/lib/CodeGen/CodeGenAction.cpp:1059

#44 0x00005555595bb332 in clang::FrontendAction::Execute (this=0x55556180d440) at clang/lib/Frontend/FrontendAction.cpp:934

#45 0x00005555595576c4 in clang::CompilerInstance::ExecuteAction (this=0x5555617e1a60, Act=…) at clang/lib/Frontend/CompilerInstance.cpp:944

#46 0x0000555559715a87 in clang::ExecuteCompilerInvocation (Clang=0x5555617e1a60) at clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:287

#47 0x000055555762f146 in cc1_main (Argv=…, Argv0=0x7fffffffd6a4 “build-s1/bin/clang-9”,

MainAddr=0x555557622e5a <GetExecutablePath[abi:cxx11](char const*, bool)>) at clang/tools/driver/cc1_main.cpp:250

#48 0x00005555576245cb in ExecuteCC1Tool (argv=…, Tool=…) at clang/tools/driver/driver.cpp:309

#49 0x0000555557624cbc in main (argc_=125, argv_=0x7fffffffcf48) at clang/tools/driver/driver.cpp:381

Note that I think this should give an error message rather than an assert but of course that does not change that there is a bug somewhere. I’ll keep looking.

Best regards,

Thomas

Thomas_Preud_homme · July 30, 2019, 2:36pm

I’ve reduced FileCheck.h (obviously FileCheck.cpp or other users of FileCheck.h won’t build with this) to the following while still triggering the bug when building FindSymbols.cpp:

#ifndef LLVM_SUPPORT_FILECHECK_H

#define LLVM_SUPPORT_FILECHECK_H

#include “llvm/Support/Error.h”

#include

llvm::Expectedstd::string getFileCheckResult();

#endif

I do not have any issue if using Optional instead of Expected, nor if using something else than std::string. Moving the header to llvm/include/llvm/Object also allows the compilation to proceed, as well as removing the -fimplicit-module-maps

I’m not sure how to progress further, I believe this hint at the bug being somewhere else instead.

Best regards,

Thomas

modocache · July 30, 2019, 2:53pm

Thank you for the link and the suggestion to try master! I did so and
discovered that it reproduces on master for me as well. The repro
script I used (unchanged from before) and the output can be found
here: https://gist.github.com/modocache/d9700166067f4a155820bc57d9bee1f3

(Note that the output looks nearly identical, but it's using clang-10
from the master branch of llvm-project.)

I wonder why the buildbots would begin passing again, whereas locally
the issue reproduces... very strange. Looking at the CMake invocation
in the build logs that Akira linked to, I can see that
'-DLLVM_ENABLE_MODULES=On' is being used. Could it be one of the other
options is masking the error I'm seeing on master?

- Brian Gesiak

ahatanak · August 1, 2019, 9:23pm

Thank you for the link and the suggestion to try master! I did so and
discovered that it reproduces on master for me as well. The repro
script I used (unchanged from before) and the output can be found
here: https://gist.github.com/modocache/d9700166067f4a155820bc57d9bee1f3

(Note that the output looks nearly identical, but it’s using clang-10
from the master branch of llvm-project.)

I wonder why the buildbots would begin passing again, whereas locally
the issue reproduces… very strange. Looking at the CMake invocation
in the build logs that Akira linked to, I can see that
‘-DLLVM_ENABLE_MODULES=On’ is being used. Could it be one of the other
options is masking the error I’m seeing on master?

Sorry, I didn’t notice that someone had disabled modules by passing ‘-DLLVM_ENABLE_MODULES=Off’ to cmake. I think that’s why we haven’t seen the failure since July 19th.

http://green.lab.llvm.org/green/job/clang-stage2-coverage-R/4172/consoleText

adrian.prantl · August 2, 2019, 4:00pm

Thank you for the link and the suggestion to try master! I did so and
discovered that it reproduces on master for me as well. The repro
script I used (unchanged from before) and the output can be found
here: https://gist.github.com/modocache/d9700166067f4a155820bc57d9bee1f3

(Note that the output looks nearly identical, but it’s using clang-10
from the master branch of llvm-project.)

I wonder why the buildbots would begin passing again, whereas locally
the issue reproduces… very strange. Looking at the CMake invocation
in the build logs that Akira linked to, I can see that
‘-DLLVM_ENABLE_MODULES=On’ is being used. Could it be one of the other
options is masking the error I’m seeing on master?

Sorry, I didn’t notice that someone had disabled modules by passing ‘-DLLVM_ENABLE_MODULES=Off’ to cmake. I think that’s why we haven’t seen the failure since July 19th.

http://green.lab.llvm.org/green/job/clang-stage2-coverage-R/4172/consoleText

Oh, that’s unfortunate. As another data point, the LLDB jobs build llvm+clang+lldb with modules enabled and seem to be doing fine at the moment:

http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/32443/consoleFull

– adrian