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.
My main project links to several system C libraries, because I am using libpng, Cuda, etc... 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. swift build -Xswiftc -I${SWIFT_HOME}/lib/swift/clang/include In the past everything worked fine. The stand alone bug repro project has no C library dependencies, however if I add this option, LLDB crashes. 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? Ed On Mon, Oct 16, 2017 at 1:37 AM, Alex Blewitt <alb...@apple.com> wrote: > Thanks for the analysis. Can you create a bug at https://bugs.swift.org 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. > > Alex > > > On 13 Oct 2017, at 22:09, Edward Connell via swift-users < > swift-users@swift.org> wrote: > > I was able to boil down a repro that has nothing to do with my project, > woo hoo! > Put a break at the print statement and run. When it hits the break point > LLDBFrontend crashes. > The do/catch seems to be necessary to trigger the crash > > Swift 4.0 release > Ubuntu 16.04 > > Ed > > ---------------------------- > import Foundation > > public class SomeClass { } > > public struct SomeStruct { > public weak var someClass: SomeClass? > } > > do { > let data = SomeStruct() > > print("break here") > } catch { > print(String(describing: error)) > } > > > On Fri, Oct 13, 2017 at 10:21 AM, Edward Connell via swift-users < > swift-users@swift.org> wrote: > >> Hi Michael, >> Thanks, I created and attached a log for you with "types" and >> "expressions" enabled >> 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. >> >> This was run with the Swift 4.0 release version >> Let me know if you want me to try anything else. >> >> Thanks, Ed >> >> >> >> On Thu, Oct 12, 2017 at 11:13 AM, Michael Gottesman <mgottes...@apple.com >> > wrote: >> >>> I just added a section to ./docs/DebuggingTheCompiler.rst on how to get >>> enable logging from LLDB. >>> >>> Can you enable the logging there and add file an SR? >>> >>> Michael >>> >>> On Oct 7, 2017, at 11:27 AM, Edward Connell <ewconn...@gmail.com> wrote: >>> >>> Hi Michael, >>> No I am not evaluating an expression or anything. This all worked fine >>> in past builds. >>> >>> I simply set a breakpoint in a function and after stopping while >>> gathering values for the debugger view, it crashes. >>> >>> It doesn't crash in all functions, but it does crash when trying to stop >>> in many different functions. >>> An example function signature where it crashes is (DataView is a >>> concrete struct): >>> >>> public func setupForward(mode: EvaluationMode, inData: DataView, labels: >>> DataView?, >>> outData: inout DataView, backData: >>> inout DataView?) throws { ... } >>> >>> 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. >>> >>> 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. >>> >>> Ubuntu 16.04 >>> Swift 4.0 release >>> NVidia gpu >>> Netlib https://github.com/ewconnell/Netlib/wiki#installation >>> CLion IDE with Swift plugin >>> >>> 1) do a debug build >>> 2) set a breakpoint at CudaSoftmax.swift:44 or any line in the function >>> 3) run >>> 4) when it stops LLDBFrontend crashes >>> >>> *LLDBFrontend: >>> /home/buildnode/jenkins/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/swift/lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp:613: >>> (anonymous namespace)::SourceAccess (anonymous >>> namespace)::AccessEnforcementSelection::getSourceAccess(swift::SILValue): >>> Assertion `isa<AllocStackInst>(address) || isa<SILUndef>(address)' failed.* >>> *Stack dump:* >>> *0. While running pass #10 SILModuleTransform ""Access Enforcement >>> Selection"".* >>> >>> >>> Using the LLDB CLI I am able to stop there. If I try "fr var -O" with >>> >>> - mode, inData, and labels, it prints their values no problem >>> - outData and backData gives me a segmentation violation >>> >>> The visible difference is the "inout" >>> >>> Not sure what the problem is. It worked fine in the past. >>> >>> If you can think of an experiment I can try to create a simple repro >>> case, please let me know. >>> >>> Thanks, Ed >>> >>> On Fri, Oct 6, 2017 at 4:34 PM, Michael Gottesman <mgottes...@apple.com> >>> wrote: >>> >>>> It looks like this is failing during guaranteed optimization. Are you >>>> running an expression in the debugger and we are crashing there? >>>> >>>> Michael >>>> >>>> On Oct 6, 2017, at 11:53 AM, Edward Connell via swift-users < >>>> swift-users@swift.org> wrote: >>>> >>>> While trying to debug a Netlib function, LLDB is crashing >>>> >>>> I'm not sure what this assert means. >>>> >>>> *LLDBFrontend: >>>> /home/buildnode/jenkins/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/swift/lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp:613: >>>> (anonymous namespace)::SourceAccess (anonymous >>>> namespace)::AccessEnforcementSelection::getSourceAccess(swift::SILValue): >>>> Assertion `isa<AllocStackInst>(address) || isa<SILUndef>(address)' failed.* >>>> *Stack dump:* >>>> *0. While running pass #10 SILModuleTransform ""Access Enforcement >>>> Selection"".* >>>> >>>> It fails every time and the same way in several functions, but not all >>>> functions. >>>> I tried to create a simple repro with the same function signature, but >>>> I can't get the simple case to fail. >>>> A debug build isn't doing whole-module-optimization, so that's not it >>>> >>>> Ideas anyone? >>>> >>>> Who owns the LLDBFrontend? >>>> >>>> Thanks, Ed >>>> _______________________________________________ >>>> swift-users mailing list >>>> swift-users@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-users >>>> >>>> >>>> >>> >>> >> >> _______________________________________________ >> swift-users mailing list >> swift-users@swift.org >> https://lists.swift.org/mailman/listinfo/swift-users >> >> > _______________________________________________ > swift-users mailing list > swift-users@swift.org > https://lists.swift.org/mailman/listinfo/swift-users > > >
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users