<div dir="ltr">> I don't know what tools are installed on the builder but I'll ask around the office on Monday, I know there are people who are more familiar with how these bots are set up.<br><div><br></div><div>Sounds good. Thank you!<br><br>> FWIW I could repo promise_type failure on my macOS desktop which has the current Xcode 14 tools installed<br><br>You mean you were able to reproduce the crash? Or were you able to reproduce the test failure described in <a href="https://github.com/llvm/llvm-project/commit/2b2f2f66141d52dc0d3082ddd12805d36872a189">https://github.com/llvm/llvm-project/commit/2b2f2f66141d52dc0d3082ddd12805d36872a189</a> also on your macOS desktop?<br><br>My current hypothesis is:<br><ol><li><a href="https://github.com/llvm/llvm-project/commit/4346318f5c700f4e85f866610fb8328fc429319b">https://github.com/llvm/llvm-project/commit/4346318f5c700f4e85f866610fb8328fc429319b</a> failed because<br></li><ul><li>green dragon is using an outdated pre-release version of clang<br></li><li>as commented in the test case "clang version < 16 did not yet write debug info for the noop coroutines."</li><li>the test case hence uses the condition "if not (is_clang and self.expectedCompilerVersion(["<", "16"])):"" to only expect check this test expectation on recent enough compilers<br></li><li>my understanding is that "clang-16 development builds" would pass this version check, even if they did not yet include <a href="https://reviews.llvm.org/D132580">https://reviews.llvm.org/D132580</a> and then fail the test expectation</li><li>If it turns out to be true that green dragon uses an older clang-version, I would propose the following course of action:</li><ul><li>Somebody should upgrades the version of clang used in green dragon</li><li>I resubmit this change unchanged</li></ul></ul><li><a href="https://github.com/llvm/llvm-project/commit/cd3091a88f7c55c90d9b5fff372ce1cdfc71948d">https://github.com/llvm/llvm-project/commit/cd3091a88f7c55c90d9b5fff372ce1cdfc71948d</a><br></li><ul><li>was indeed buggy. This commit turned a "missing debug information" situation into a crash</li><li>I am pretty sure that Apple clang version 14.0.0 did not contain <a href="https://reviews.llvm.org/D132580">https://reviews.llvm.org/D132580</a>, and is hence missing the debug information. This would explain the crash on your mac Desktop.</li><li>I would first wait after we resolved the issues around the first commit, though, because rebasing this commit so it can be applied before 4346318f5c700f4e85f866610fb8328fc429319b would be cumbersome<br></li><li>I will then add the additional `if (!promise_type.isVoid())` check, so we no longer crash on missing debug info, and then re-apply the patch</li></ul></ol><div>Do you agree with that plan? Do you know somebody who can update clang on green dragon?</div></div><div><br></div><div>Cheers,<br>Adrian</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 26, 2022 at 3:24 AM Jason Molenda <<a href="mailto:jason@molenda.com">jason@molenda.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">FWIW I could repo promise_type failure on my macOS desktop which has the current Xcode 14 tools installed, but I can't tell you exactly what this corresponds to in github hash terms (it's "Apple clang version 14.0.0 (clang-1400.0.29.100)"), I think it was originally branched 2021-10-26, although there have been a lot of cherrypicks pulled in too, so it's not an exact snapshot of October 26 sources.<br>
<br>
J<br>
<br>
> On Nov 25, 2022, at 2:22 PM, Adrian Vogelsgesang <<a href="mailto:avogelsgesang@salesforce.com" target="_blank">avogelsgesang@salesforce.com</a>> wrote:<br>
> <br>
> Hm... wait a second...<br>
> <br>
> Which clang-version is <a href="https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/" rel="noreferrer" target="_blank">https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/</a> using? Is it using an older version of clang? Does that version already contain the patch <a href="https://reviews.llvm.org/D132580" rel="noreferrer" target="_blank">https://reviews.llvm.org/D132580</a>?<br>
> <br>
> If not, that might explain things...<br>
> <br>
> On Fri, Nov 25, 2022 at 11:18 PM Adrian Vogelsgesang <<a href="mailto:avogelsgesang@salesforce.com" target="_blank">avogelsgesang@salesforce.com</a>> wrote:<br>
> Hi Jason,<br>
> <br>
> Sorry for the late reply - your mail got caught in my spam filter, and I just realized about the build breakage now after you reverted the commits. Just to confirm: <br>
> <br>
> I looked at the original change again, and I think I know what's going wrong here: Devirtualization fails, and `promise_type` stays `void`. Obviously, `CreateValueObjectFromAddress` cannot create an object of type `void` and fails. The previous version was robust against that scenario, but <a href="https://reviews.llvm.org/D132815" rel="noreferrer" target="_blank">https://reviews.llvm.org/D132815</a> accidentally regressed this.<br>
> <br>
> If a program has all the expected debug info, devirtualization should never fail and `promise_type` never stays `void`. It seems something is wrong/unexpected with the debug info on Darwin. Devirtualization relies on being able to identify the function pointer of the `destroy` function and inspects that function. So the root cause seems to be the same as for the revert <a href="https://github.com/llvm/llvm-project/commit/2b2f2f66141d52dc0d3082ddd12805d36872a189" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/commit/2b2f2f66141d52dc0d3082ddd12805d36872a189</a>: For some reason, the debugger cannot find debug info for the function pointed to by the `destroy` function.<br>
> <br>
> However, I still don't quite understand what's wrong with the debug info on Mac.<br>
> <br>
> Either way, the pretty printer should of course be robust against such unexpected debug info. I think a simple additional check should be enough to make this robust so we no longer crash:<br>
> if (!promise_type.isVoid()) { // <---- additional check<br>
>   lldb::ValueObjectSP promise = CreateValueObjectFromAddress(<br>
>       "promise", frame_ptr_addr + 2 * ptr_size, exe_ctx, promise_type);<br>
>   Status error;<br>
>   lldb::ValueObjectSP promisePtr = promise->AddressOf(error);<br>
>   if (error.Success())<br>
>     m_promise_ptr_sp = promisePtr->Clone(ConstString("promise"));<br>
> }<br>
> <br>
> Meta question: I am a bit confused about <a href="https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/" rel="noreferrer" target="_blank">https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/</a>. I thought LLVM's buildbots were set up to send an email in case somebody breaks the build. Also, I made sure that all builds in <a href="https://lab.llvm.org/buildbot/#/builders" rel="noreferrer" target="_blank">https://lab.llvm.org/buildbot/#/builders</a> stayed green after my commit. So what are the expectations around which CIs need to stay green after a commit? Do I need to setup anything such that <a href="http://green.lab.llvm.org" rel="noreferrer" target="_blank">green.lab.llvm.org</a> also sends me an email if I break it?<br>
> <br>
> Cheers,<br>
> Adrian<br>
> <br>
> On Thu, Nov 24, 2022 at 10:50 PM Jason Molenda <<a href="mailto:jason@molenda.com" target="_blank">jason@molenda.com</a>> wrote:<br>
> Ah, little misstatement below.  My first thought was that promise_type was null, but when I stepped through here with a debugger, it was not.  I didn't know how to dig in to a CompilerType object but there was some reason why this CreateValueObjectFromAddress failed to return an actual ValueObject, and I assumed it's something to do with that CompilerType.  But I didn't dig in far enough to understand what the issue in the type was.<br>
> <br>
> > On Nov 24, 2022, at 1:20 PM, Jason Molenda <<a href="mailto:jason@molenda.com" target="_blank">jason@molenda.com</a>> wrote:<br>
> > <br>
> > Hi Adrian, the green dragon Incremental CI bot has been failing the past couple of days after the changes for the coroutines formatter, most directly   <a href="https://reviews.llvm.org/D132815" rel="noreferrer" target="_blank">https://reviews.llvm.org/D132815</a> landed - TestCoroutineHandle.py results in a segfault on Darwin systems (both on the CI and on my mac desktop) consistently.   <a href="https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/" rel="noreferrer" target="_blank">https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/</a><br>
> > <br>
> > It's crashing in formatters::StdlibCoroutineHandleSyntheticFrontEnd where you're doing<br>
> > <br>
> > ```<br>
> >  // Add the `promise` member. We intentionally add `promise` as a pointer type<br>
> >  // instead of a value type, and don't automatically dereference this pointer.<br>
> >  // We do so to avoid potential very deep recursion in case there is a cycle in<br>
> >  // formed between `std::coroutine_handle`s and their promises.<br>
> >  lldb::ValueObjectSP promise = CreateValueObjectFromAddress(<br>
> >      "promise", frame_ptr_addr + 2 * ptr_size, exe_ctx, promise_type);<br>
> >  Status error;<br>
> >  lldb::ValueObjectSP promisePtr = promise->AddressOf(error);<br>
> > ```<br>
> > <br>
> > and the promise_type dose not have a CompilerType so promisePtr is nullptr and we crash on the method call to AddressOf. I looked briefly, but this isn't a part of lldb I know well and I'm not sure the nature of the problem.<br>
> > <br>
> > It's a long weekend in the US, so if you have a suggestion for addressing this that'd be great, or I can roll back the changes necessary to get the bot clean later today and we can look at this next week.  <br>
> > <br>
> > Thanks!<br>
> <br>
> <br>
<br>
</blockquote></div>