llvm dev - Aug 2019 - 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

On Tue, Jul 30, 2019 at 7:53 AM Brian Gesiak <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
>
> (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

- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190801/ddde2a15/attachment.html>

> 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>