<div dir="ltr">While creating a bug report for this problem I placed my simple repro case in a separate project with default build settings and I found that it no longer crashes LLDB.<div><br></div><div>My main project links to several system C libraries, because I am using libpng, Cuda, etc...</div><div>In order for LLDB to function with my project and load things from the AST context, I was told to specify the clang include directory.</div><div><br></div><div>swift build -Xswiftc -I${SWIFT_HOME}/lib/swift/clang/include</div><div><br></div><div>In the past everything worked fine.</div><div><br></div><div>The stand alone bug repro project has no C library dependencies, however if I add this option, LLDB crashes.</div><div><br></div><div>I tried eliminating this option from my main project, and from a separate project using SwiftProtobuf. The result is that I am no longer able to debug either of them. Is there some new way we are supposed to pick up system imports, or is the a legitimate bug?</div><div><br></div><div>Ed</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 16, 2017 at 1:37 AM, Alex Blewitt <span dir="ltr">&lt;<a href="mailto:alblue@apple.com" target="_blank">alblue@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Thanks for the analysis. Can you create a bug at <a href="https://bugs.swift.org" target="_blank">https://bugs.swift.org</a> and attach the reproducing test case? That way it can be routed to the appropriate people, in case they&#39;re not on this mailing list.<span class="HOEnZb"><font color="#888888"><div><br></div></font></span><div><span class="HOEnZb"><font color="#888888">Alex</font></span><div><div class="h5"><br><div><br><blockquote type="cite"><div>On 13 Oct 2017, at 22:09, Edward Connell via swift-users &lt;<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>&gt; wrote:</div><br class="m_-992934321960961547Apple-interchange-newline"><div><div dir="ltr">I was able to boil down a repro that has nothing to do with my project, woo hoo!<div>Put a break at the print statement and run. When it hits the break point LLDBFrontend crashes.</div><div>The do/catch seems to be necessary to trigger the crash</div><div><br></div><div>Swift 4.0 release</div><div>Ubuntu 16.04</div><div><br></div><div>Ed<br><div><br></div><div>----------------------------</div><div><div>import Foundation</div><div><br></div><div>public class SomeClass { }</div><div><br></div><div>public struct SomeStruct {</div><div>  public weak var someClass: SomeClass?</div><div>}</div><div><br></div><div>do {</div><div>  let data = SomeStruct()</div><div><br></div><div>  print(&quot;break here&quot;)</div><div>} catch {</div><div>  print(String(describing: error))</div><div>}</div></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 13, 2017 at 10:21 AM, Edward Connell via swift-users <span dir="ltr">&lt;<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><div dir="ltr"><span style="font-size:12.8px">Hi Michael,</span><div style="font-size:12.8px">Thanks, I created and attached a log for you with &quot;types&quot; and &quot;expressions&quot; enabled</div><div style="font-size:12.8px">I set a breakpoint right before calling the function that triggers the crash, enabled logging, then continued. I was trying to reduce the amount of log output to sift through.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">This was run with the Swift 4.0 release version</div><div style="font-size:12.8px">Let me know if you want me to try anything else.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Thanks, Ed</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><br></div></div></span><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Oct 12, 2017 at 11:13 AM, Michael Gottesman <span dir="ltr">&lt;<a href="mailto:mgottesman@apple.com" target="_blank">mgottesman@apple.com</a>&gt;</span> wrote:<br></span><div><div class="m_-992934321960961547h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I just added a section to ./docs/<a href="http://DebuggingTheCompiler.rs" target="_blank">DebuggingTheCompiler.rs</a><wbr>t on how to get enable logging from LLDB.<div><br></div><div>Can you enable the logging there and add file an SR?</div><div><br></div><div>Michael</div><div><br><div><div><blockquote type="cite"><div>On Oct 7, 2017, at 11:27 AM, Edward Connell &lt;<a href="mailto:ewconnell@gmail.com" target="_blank">ewconnell@gmail.com</a>&gt; wrote:</div><br class="m_-992934321960961547m_-2179302737174038848m_-6406537339308252266Apple-interchange-newline"><div><div dir="ltr">Hi Michael,<div>No I am not evaluating an expression or anything. This all worked fine in past builds.</div><div><br></div><div>I simply set a breakpoint in a function and after stopping while gathering values for the debugger view, it crashes.</div><div><br></div><div>It doesn&#39;t crash in all functions, but it does crash when trying to stop in many different functions.</div><div>An example function signature where it crashes is (DataView is a concrete struct):<br></div><div><br></div><div><div>public func setupForward(mode: EvaluationMode, inData: DataView, labels: DataView?,</div><div><span style="white-space:pre-wrap">        </span>                                 outData: inout DataView, backData: inout DataView?) throws { ... }</div></div><div><br></div><div>Before calling the function, all of the parameters have valid values that I can examine. But as soon as I step into this function, LLDB crashes with that message. It behaves the same way with other functions that have different signatures.</div><div><br></div><div>I tried to create a very simple repro case using this signature, but it didn&#39;t crash. My project is on GitHub and this can be easily reproduced. The only pain is installing my project on your test machine.</div><div><br></div><div>Ubuntu 16.04</div><div>Swift 4.0 release</div><div>NVidia gpu</div><div>Netlib <a href="https://github.com/ewconnell/Netlib/wiki#installation" target="_blank">https://github.com/ewco<wbr>nnell/Netlib/wiki#installation</a></div><div>CLion IDE with Swift plugin</div><div><br></div><div>1) do a debug build</div><div>2) set a breakpoint at CudaSoftmax.swift:44  or any line in the function</div><div>3) run</div><div>4) when it stops LLDBFrontend crashes</div><div><br></div><div><div><i>LLDBFrontend: /home/buildnode/jenkins/worksp<wbr>ace/oss-swift-4.0-package-linu<wbr>x-ubuntu-16_04/swift/lib/SILOp<wbr>timizer/Mandatory/AccessEnforc<wbr>ementSelection.cpp:613: (anonymous namespace)::SourceAccess (anonymous namespace)::AccessEnforcementS<wbr>election::getSourceAccess(swif<wbr>t::SILValue): Assertion `isa&lt;AllocStackInst&gt;(address) || isa&lt;SILUndef&gt;(address)&#39; failed.</i></div><div><i>Stack dump:</i></div><div><i>0.<span style="white-space:pre-wrap">        </span>While running pass #10 SILModuleTransform &quot;&quot;Access Enforcement Selection&quot;&quot;.</i></div></div><div><br></div><div><br></div><div>Using the LLDB CLI I am able to stop there. If I try &quot;fr var -O&quot; with </div><div><ul><li>mode, inData, and labels, it prints their values no problem</li><li>outData and backData gives me a segmentation violation<br></li></ul><div>The visible difference is the &quot;inout&quot;</div></div><div><br></div><div>Not sure what the problem is. It worked fine in the past.</div><div><br></div><div>If you can think of an experiment I can try to create a simple repro case, please let me know.</div><div><br></div><div>Thanks, Ed</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 6, 2017 at 4:34 PM, Michael Gottesman <span dir="ltr">&lt;<a href="mailto:mgottesman@apple.com" target="_blank">mgottesman@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">It looks like this is failing during guaranteed optimization. Are you running an expression in the debugger and we are crashing there?<div><br></div><div>Michael</div><div><br><div><blockquote type="cite"><div><div class="m_-992934321960961547m_-2179302737174038848m_-6406537339308252266h5"><div>On Oct 6, 2017, at 11:53 AM, Edward Connell via swift-users &lt;<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>&gt; wrote:</div><br class="m_-992934321960961547m_-2179302737174038848m_-6406537339308252266m_1753879203729931118Apple-interchange-newline"></div></div><div><div><div class="m_-992934321960961547m_-2179302737174038848m_-6406537339308252266h5"><div dir="ltr">While trying to debug a Netlib function, LLDB is crashing<div><br></div><div><div>I&#39;m not sure what this assert means.</div></div><div><br></div><div><div><i>LLDBFrontend: /home/buildnode/jenkins/worksp<wbr>ace/oss-swift-4.0-package-linu<wbr>x-ubuntu-16_04/swift/lib/SILOp<wbr>timizer/Mandatory/AccessEnforc<wbr>ementSelection.cpp:613: (anonymous namespace)::SourceAccess (anonymous namespace)::AccessEnforcementS<wbr>election::getSourceAccess(swif<wbr>t::SILValue): Assertion `isa&lt;AllocStackInst&gt;(address) || isa&lt;SILUndef&gt;(address)&#39; failed.</i></div><div><i>Stack dump:</i></div><div><i>0.<span style="white-space:pre-wrap">        </span>While running pass #10 SILModuleTransform &quot;&quot;Access Enforcement Selection&quot;&quot;.</i></div></div><div><br></div><div>It fails every time and the same way in several functions, but not all functions.<br></div><div>I tried to create a simple repro with the same function signature, but I can&#39;t get the simple case to fail.</div><div>A debug build isn&#39;t doing whole-module-optimization, so that&#39;s not it</div><div><br></div><div>Ideas anyone?</div><div><br></div><div>Who owns the LLDBFrontend?</div><div><br></div><div>Thanks, Ed</div></div></div></div>
______________________________<wbr>_________________<br>swift-users mailing list<br><a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-users" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-users</a><br></div></blockquote></div><br></div></div></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></blockquote></div></div></div><br></div>
<br>______________________________<wbr>_________________<br>
swift-users mailing list<br>
<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-users</a><br>
<br></blockquote></div><br></div>
______________________________<wbr>_________________<br>swift-users mailing list<br><a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-users" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-users</a><br></div></blockquote></div><br></div></div></div></div></blockquote></div><br></div>