[llvm-dev] ICE in release/9.x when using LLVM_ENABLE_MODULES

Adrian Prantl via llvm-dev llvm-dev at lists.llvm.org
Fri Aug 2 09:00:43 PDT 2019



> On Aug 1, 2019, at 2:23 PM, Akira Hatanaka via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On Tue, Jul 30, 2019 at 7:53 AM Brian Gesiak <modocache at gmail.com <mailto:modocache at gmail.com>> wrote:
> 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 <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 <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 <http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/32443/consoleFull>

-- adrian

> 
> - Brian Gesiak
> 
> On Mon, Jul 29, 2019 at 1:51 PM Akira Hatanaka <ahatanak at gmail.com <mailto: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 <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 <mailto: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 <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 <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 <mailto:llvm-dev at lists.llvm.org>
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> _______________________________________________
> 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/20190802/a5b3443d/attachment-0001.html>


More information about the llvm-dev mailing list