<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"><<a href="mailto:alblue@apple.com" target="_blank">alblue@apple.com</a>></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'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 <<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>> 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("break here")</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"><<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>></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 "types" and "expressions" 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"><<a href="mailto:mgottesman@apple.com" target="_blank">mgottesman@apple.com</a>></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 <<a href="mailto:ewconnell@gmail.com" target="_blank">ewconnell@gmail.com</a>> 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'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'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<AllocStackInst>(address) || isa<SILUndef>(address)' failed.</i></div><div><i>Stack dump:</i></div><div><i>0.<span style="white-space:pre-wrap"> </span>While running pass #10 SILModuleTransform ""Access Enforcement Selection"".</i></div></div><div><br></div><div><br></div><div>Using the LLDB CLI I am able to stop there. If I try "fr var -O" 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 "inout"</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"><<a href="mailto:mgottesman@apple.com" target="_blank">mgottesman@apple.com</a>></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 <<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>> 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'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<AllocStackInst>(address) || isa<SILUndef>(address)' failed.</i></div><div><i>Stack dump:</i></div><div><i>0.<span style="white-space:pre-wrap"> </span>While running pass #10 SILModuleTransform ""Access Enforcement Selection"".</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't get the simple case to fail.</div><div>A debug build isn't doing whole-module-optimization, so that'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>