[swift-users] Swift 4.0 LLDBFrontend Crash

Mon Oct 16 12:52:40 CDT 2017

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 <alblue at 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 at 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 at 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 <mgottesman at 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 <ewconnell at 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 <mgottesman at 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 at 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 at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-users
>>>>
>>>>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> swift-users mailing list
>> swift-users at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>>
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20171016/1898d4e4/attachment.html>