Brian Gesiak via llvm-dev
2019-Jul-29 13:40 UTC
[llvm-dev] ICE in release/9.x when using LLVM_ENABLE_MODULES
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: https://gist.github.com/modocache/ac366ca9673b93bb21e75d3e72162608 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: https://github.com/llvm/llvm-project/commit/baae41ff76f662987f31447686ba819dcd748b3f 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
Akira Hatanaka via llvm-dev
2019-Jul-29 17:51 UTC
[llvm-dev] ICE in release/9.x when using LLVM_ENABLE_MODULES
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. On Mon, Jul 29, 2019 at 6:41 AM Brian Gesiak via llvm-dev < llvm-dev at lists.llvm.org> wrote:> 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: > https://gist.github.com/modocache/ac366ca9673b93bb21e75d3e72162608 > > 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: > > https://github.com/llvm/llvm-project/commit/baae41ff76f662987f31447686ba819dcd748b3f > > 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 > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190729/57e9f488/attachment.html>
Thomas Preud'homme via llvm-dev
2019-Jul-30 08:49 UTC
[llvm-dev] ICE in release/9.x when using LLVM_ENABLE_MODULES
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 (<string>). However that does not solve the problem.
Still, this warrants a patch in itself IMO. Unsurprisingly, changing all the
Expected<std::string> for Expected<StringRef> in FileCheck.h let the
compilation proceed but I can see some other uses of Expected<std::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 at 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 at entry=0x55555f5b0b98 "CachedFieldIndex
&& \"failed to find field in parent\"",
file=file at entry=0x55555f5afa88
"/home/thomasp/repos/llvm-project-modules-crash/clang/lib/AST/Decl.cpp",
line=line at entry=3932,
function=function at 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
________________________________
From: Brian Gesiak <modocache at gmail.com>
Sent: 29 July 2019 14:40
To: llvm-dev <llvm-dev at lists.llvm.org>
Cc: Thomas Preud'homme <thomasp at graphcore.ai>
Subject: ICE in release/9.x when using LLVM_ENABLE_MODULES
[This message was sent from somebody outside of your organisation]
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:
https://gist.github.com/modocache/ac366ca9673b93bb21e75d3e72162608
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:
https://github.com/llvm/llvm-project/commit/baae41ff76f662987f31447686ba819dcd748b3f
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
** We have updated our privacy policy, which contains important information
about how we collect and process your personal data. To read the policy, please
click here<http://www.graphcore.ai/privacy> **
This email and its attachments are intended solely for the addressed recipients
and may contain confidential or legally privileged information.
If you are not the intended recipient you must not copy, distribute or
disseminate this email in any way; to do so may be unlawful.
Any personal data/special category personal data herein are processed in
accordance with UK data protection legislation.
All associated feasible security measures are in place. Further details are
available from the Privacy Notice on the website and/or from the Company.
Graphcore Limited (registered in England and Wales with registration number
10185006) is registered at 107 Cheapside, London, UK, EC2V 6DN.
This message was scanned for viruses upon transmission. However Graphcore
accepts no liability for any such transmission.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190730/39b5638e/attachment.html>
Thomas Preud'homme via llvm-dev
2019-Jul-30 14:36 UTC
[llvm-dev] ICE in release/9.x when using LLVM_ENABLE_MODULES
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 <string>
llvm::Expected<std::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
________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Thomas
Preud'homme via llvm-dev <llvm-dev at lists.llvm.org>
Sent: 30 July 2019 09:49
To: Brian Gesiak <modocache at gmail.com>; llvm-dev <llvm-dev at
lists.llvm.org>
Subject: Re: [llvm-dev] ICE in release/9.x when using LLVM_ENABLE_MODULES
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 (<string>). However that does not solve the problem.
Still, this warrants a patch in itself IMO. Unsurprisingly, changing all the
Expected<std::string> for Expected<StringRef> in FileCheck.h let the
compilation proceed but I can see some other uses of Expected<std::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 at 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 at entry=0x55555f5b0b98 "CachedFieldIndex
&& \"failed to find field in parent\"",
file=file at entry=0x55555f5afa88
"/home/thomasp/repos/llvm-project-modules-crash/clang/lib/AST/Decl.cpp",
line=line at entry=3932,
function=function at 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
________________________________
From: Brian Gesiak <modocache at gmail.com>
Sent: 29 July 2019 14:40
To: llvm-dev <llvm-dev at lists.llvm.org>
Cc: Thomas Preud'homme <thomasp at graphcore.ai>
Subject: ICE in release/9.x when using LLVM_ENABLE_MODULES
[This message was sent from somebody outside of your organisation]
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:
https://gist.github.com/modocache/ac366ca9673b93bb21e75d3e72162608
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:
https://github.com/llvm/llvm-project/commit/baae41ff76f662987f31447686ba819dcd748b3f
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
** We have updated our privacy policy, which contains important information
about how we collect and process your personal data. To read the policy, please
click here<http://www.graphcore.ai/privacy> **
This email and its attachments are intended solely for the addressed recipients
and may contain confidential or legally privileged information.
If you are not the intended recipient you must not copy, distribute or
disseminate this email in any way; to do so may be unlawful.
Any personal data/special category personal data herein are processed in
accordance with UK data protection legislation.
All associated feasible security measures are in place. Further details are
available from the Privacy Notice on the website and/or from the Company.
Graphcore Limited (registered in England and Wales with registration number
10185006) is registered at 107 Cheapside, London, UK, EC2V 6DN.
This message was scanned for viruses upon transmission. However Graphcore
accepts no liability for any such transmission.
** We have updated our privacy policy, which contains important information
about how we collect and process your personal data. To read the policy, please
click here<http://www.graphcore.ai/privacy> **
This email and its attachments are intended solely for the addressed recipients
and may contain confidential or legally privileged information.
If you are not the intended recipient you must not copy, distribute or
disseminate this email in any way; to do so may be unlawful.
Any personal data/special category personal data herein are processed in
accordance with UK data protection legislation.
All associated feasible security measures are in place. Further details are
available from the Privacy Notice on the website and/or from the Company.
Graphcore Limited (registered in England and Wales with registration number
10185006) is registered at 107 Cheapside, London, UK, EC2V 6DN.
This message was scanned for viruses upon transmission. However Graphcore
accepts no liability for any such transmission.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190730/039918cb/attachment.html>
Brian Gesiak via llvm-dev
2019-Jul-30 14:53 UTC
[llvm-dev] ICE in release/9.x when using LLVM_ENABLE_MODULES
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 On Mon, Jul 29, 2019 at 1:51 PM Akira Hatanaka <ahatanak at gmail.com> wrote:> > 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. > > On Mon, Jul 29, 2019 at 6:41 AM Brian Gesiak via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> 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: >> https://gist.github.com/modocache/ac366ca9673b93bb21e75d3e72162608 >> >> 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: >> https://github.com/llvm/llvm-project/commit/baae41ff76f662987f31447686ba819dcd748b3f >> >> 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 >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Possibly Parallel Threads
- ICE in release/9.x when using LLVM_ENABLE_MODULES
- Why is lldb telling me "variable not available"?
- Why is lldb telling me "variable not available"?
- Why is lldb telling me "variable not available"?
- Suggestions for how coroutines and UBSan codegen can play nice with one another?