Re: [swift-users] Swift 4.0 LLDBFrontend Crash

[Alex Blewitt via swift-users]

Please record this in a bug at bugs.swift.org so that it doesn’t get lost, if 
you haven’t already. 

Thanks!

Alex

Sent from my iPhone 

> On 16 Oct 2017, at 19:56, Edward Connell  wrote:
> 
> Specifying the clang import location is what is triggering the LLDBFrontend 
> crash. 
> I think you are saying that I should not need to specify the clang include 
> import location to the compiler.
> 
> I've attached the unmodified SwiftProtobuf example program found in the docs 
> at https://github.com/apple/swift-protobuf.git, so this is independent from 
> my project.
> 
> Are you able to simply do "swift build" and successfully debug and examine 
> values like "info"? 
> For me it fails unless I also specify the import location for the clang 
> include directory.
> 
> swift build -I/home/ed/swift/usr/lib/swift/clang/include
> 
> And yes I checked, I am picking up the correct swift binary
> 
> 
> Swift
> $ swift --version
> Swift version 4.0.1-dev (LLVM 2dedb62a0b, Clang b9d76a314c, Swift 00e34e4b1e)
> Target: x86_64-unknown-linux-gnu
> 
> LLDB failure output
> 
> $ lldb HelloWorld
> (lldb) target create "HelloWorld"
> Current executable set to 'HelloWorld' (x86_64).
> (lldb) b main.swift:20
> Breakpoint 1: where = HelloWorld`main + 1116 at main.swift:21, address = 
> 0x0041146c
> (lldb) run
> Process 20745 launched: 
> '/home/ed/Documents/prototest/.build/x86_64-unknown-linux/debug/HelloWorld' 
> (x86_64)
> Process 20745 stopped
> * thread #1, name = 'HelloWorld', stop reason = breakpoint 1.1
> frame #0: 0x0041146c HelloWorld`main at main.swift:21
>18 let binaryData: Data = try info.serializedData()
>19 
>20 // Deserialize a received Data object from `binaryData`
> -> 21 let decodedInfo = try BookInfo(serializedData: 
> binaryData)
>22 
>23 // Serialize to JSON format as a Data object
>24 let jsonData: Data = try info.jsonUTF8Data()
> Target 0: (HelloWorld) stopped.
> (lldb) p info
> error: in auto-import:
> failed to get module 'HelloWorld' from AST context:
> :1:10: note: in file included from :1:
> #include "CoreFoundation.h"
>  ^
> 
> error: /home/ed/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:26:10: 
> error: 'stdarg.h' file not found
> #include 
>  ^
> 
> /home/ed/swift/usr/lib/swift/CoreFoundation/CFStream.h:20:10: note: while 
> building module 'CDispatch' imported from 
> /home/ed/swift/usr/lib/swift/CoreFoundation/CFStream.h:20:
> #include 
>  ^
> 
> :1:10: note: in file included from :1:
> #include "dispatch.h"
>  ^
> 
> /home/ed/swift/usr/lib/swift/dispatch/dispatch.h:30:10: note: in file 
> included from /home/ed/swift/usr/lib/swift/dispatch/dispatch.h:30:
> #include 
>  ^
> 
> /home/ed/swift/usr/lib/swift/os/linux_base.h:19:10: note: in file included 
> from /home/ed/swift/usr/lib/swift/os/linux_base.h:19:
> #include 
>  ^
> 
> error: /usr/include/x86_64-linux-gnu/sys/param.h:23:10: error: 'stddef.h' 
> file not found
> #include 
>  ^
> 
> error: could not build C module 'CoreFoundation'
> 
> 
>> On Mon, Oct 16, 2017 at 11:00 AM, Alex Blewitt  wrote:
>> > On 16 Oct 2017, at 18:52, Edward Connell  wrote:
>> >
>> > 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.
>> 
>> If you can add that information to the bug report, including whawt version 
>> of swift you're using (with swiftc -v) and the crash report then that would 
>> allow others to see what problem you're experiencing.
>> 
>> I assume that SWIFT_HOME is the same location as the swift executable that 
>> you're running? Might be worth checking with 'which swift'.
>> 
>> > 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?
>> 
>> The Swift REPL on Linux needs to have the -I flag in order to work as 
>> expected. However, the swift compiler shouldn't need to have that 
>> information, since it will know where the corresponding include directory is.
>> 
>> Alex
> 
> 
___
swift-users mailing 

Re: [swift-users] Swift 4.0 LLDBFrontend Crash

[Edward Connell via swift-users]

Specifying the clang import location is what is triggering the LLDBFrontend
crash.
I think you are saying that I should not need to specify the clang include
import location to the compiler.

I've attached the unmodified SwiftProtobuf example program found in the
docs at https://github.com/apple/swift-protobuf.git, so this is independent
from my project.

Are you able to simply do "swift build" and successfully debug and examine
values like "info"?
For me it fails unless I also specify the import location for the clang
include directory.

swift build -I/home/ed/swift/usr/lib/swift/clang/include

And yes I checked, I am picking up the correct swift binary


*Swift*
$ swift --version
Swift version 4.0.1-dev (LLVM 2dedb62a0b, Clang b9d76a314c, Swift
00e34e4b1e)
Target: x86_64-unknown-linux-gnu

*LLDB failure output*

$ lldb HelloWorld
(lldb) target create "HelloWorld"
Current executable set to 'HelloWorld' (x86_64).
(lldb) b main.swift:20
Breakpoint 1: where = HelloWorld`main + 1116 at main.swift:21, address =
0x0041146c
(lldb) run
Process 20745 launched:
'/home/ed/Documents/prototest/.build/x86_64-unknown-linux/debug/HelloWorld'
(x86_64)
Process 20745 stopped
* thread #1, name = 'HelloWorld', stop reason = breakpoint 1.1
frame #0: 0x0041146c HelloWorld`main at main.swift:21
   18  let binaryData: Data = try info.serializedData()
   19
   20  // Deserialize a received Data object from `binaryData`
-> 21  let decodedInfo = try BookInfo(serializedData: binaryData)
   22
   23  // Serialize to JSON format as a Data object
   24  let jsonData: Data = try info.jsonUTF8Data()
Target 0: (HelloWorld) stopped.
(lldb) p info
error: in auto-import:
failed to get module 'HelloWorld' from AST context:
:1:10: note: in file included from :1:
#include "CoreFoundation.h"
 ^

error: /home/ed/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:26:10:
error: 'stdarg.h' file not found
#include 
 ^

/home/ed/swift/usr/lib/swift/CoreFoundation/CFStream.h:20:10: note: while
building module 'CDispatch' imported from
/home/ed/swift/usr/lib/swift/CoreFoundation/CFStream.h:20:
#include 
 ^

:1:10: note: in file included from :1:
#include "dispatch.h"
 ^

/home/ed/swift/usr/lib/swift/dispatch/dispatch.h:30:10: note: in file
included from /home/ed/swift/usr/lib/swift/dispatch/dispatch.h:30:
#include 
 ^

/home/ed/swift/usr/lib/swift/os/linux_base.h:19:10: note: in file included
from /home/ed/swift/usr/lib/swift/os/linux_base.h:19:
#include 
 ^

error: /usr/include/x86_64-linux-gnu/sys/param.h:23:10: error: 'stddef.h'
file not found
#include 
 ^

error: could not build C module 'CoreFoundation'


On Mon, Oct 16, 2017 at 11:00 AM, Alex Blewitt  wrote:

> > On 16 Oct 2017, at 18:52, Edward Connell  wrote:
> >
> > 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.
>
> If you can add that information to the bug report, including whawt version
> of swift you're using (with swiftc -v) and the crash report then that would
> allow others to see what problem you're experiencing.
>
> I assume that SWIFT_HOME is the same location as the swift executable that
> you're running? Might be worth checking with 'which swift'.
>
> > 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?
>
> The Swift REPL on Linux needs to have the -I flag in order to work as
> expected. However, the swift compiler shouldn't need to have that
> information, since it will know where the corresponding include directory
> is.
>
> Alex
>


prototest.tar.gz
Description: GNU Zip compressed data
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift 4.0 LLDBFrontend Crash

[Alex Blewitt via swift-users]

> On 16 Oct 2017, at 18:52, Edward Connell  wrote:
> 
> 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.

If you can add that information to the bug report, including whawt version of 
swift you're using (with swiftc -v) and the crash report then that would allow 
others to see what problem you're experiencing. 

I assume that SWIFT_HOME is the same location as the swift executable that 
you're running? Might be worth checking with 'which swift'.

> 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?

The Swift REPL on Linux needs to have the -I flag in order to work as expected. 
However, the swift compiler shouldn't need to have that information, since it 
will know where the corresponding include directory is.

Alex
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift 4.0 LLDBFrontend Crash

[Edward Connell via swift-users]

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  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 > > 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  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(address) || isa(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 

Re: [swift-users] Swift 4.0 LLDBFrontend Crash

[Alex Blewitt via swift-users]

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 
>  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 
> > 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  > 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 > > 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(address) || isa(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 > > 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 
>>> > 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 

Re: [swift-users] Swift 4.0 LLDBFrontend Crash

[Edward Connell via swift-users]

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 
> 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  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(address) || isa(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 
>> 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(address) || isa(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
>>> 

Re: [swift-users] Swift 4.0 LLDBFrontend Crash

[Edward Connell via swift-users]

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 
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  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(address) || isa(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 
> 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(address) || isa(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
>>
>>
>>
>
>


lldb-log.txt.tar.gz
Description: GNU Zip compressed data
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift 4.0 LLDBFrontend Crash

[Michael Gottesman via swift-users]

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  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(address) || isa(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  > 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 
>> > 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(address) || isa(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

Re: [swift-users] Swift 4.0 LLDBFrontend Crash

[Edward Connell via swift-users]

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(address) || isa(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 
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(address) || isa(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

Re: [swift-users] Swift 4.0 LLDBFrontend Crash

[Michael Gottesman via swift-users]

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 
>  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(address) || isa(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