Swift 4.0 LLDBFrontend Crash

Using Swift
1

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

2

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

3

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 Home · ewconnell/Netlib Wiki · GitHub
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@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

4

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@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 Home · ewconnell/Netlib Wiki · GitHub
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@apple.com <mailto:mgottesman@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 <mailto: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 <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

5

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

lldb-log.txt.tar.gz (92.5 KB)

···

On Thu, Oct 12, 2017 at 11:13 AM, Michael Gottesman <mgottesman@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@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 Home · ewconnell/Netlib Wiki · GitHub
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@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

6

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 <mgottesman@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@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 Home · ewconnell/Netlib Wiki · GitHub
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@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

7

Thanks for the analysis. Can you create a bug at https://bugs.swift.org <Issues · apple/swift · GitHub; 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 <mailto: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 <mgottesman@apple.com <mailto:mgottesman@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@gmail.com <mailto:ewconnell@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 Home · ewconnell/Netlib Wiki · GitHub
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@apple.com <mailto:mgottesman@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 <mailto: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 <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org <mailto: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

8

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@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 <mgottesman@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@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 Home · ewconnell/Netlib Wiki · GitHub
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@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

9

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

···

On 16 Oct 2017, at 18:52, Edward Connell <ewconnell@gmail.com> wrote:

10

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 GitHub - apple/swift-protobuf: Plugin and runtime library for using protobuf with Swift, so this is independent

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*

prototest.tar.gz (5.48 KB)

···

from my project.
------------------------
$ 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 =
0x000000000041146c
(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: 0x000000000041146c 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:
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "CoreFoundation.h"
         ^

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

/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 <dispatch/dispatch.h>
         ^

<module-includes>:1:10: note: in file included from <module-includes>: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 <os/linux_base.h>
         ^

/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 <sys/param.h>
         ^

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

error: could not build C module 'CoreFoundation'

On Mon, Oct 16, 2017 at 11:00 AM, Alex Blewitt <alblue@apple.com> wrote:

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

11

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 :iphone:

On 16 Oct 2017, at 19:56, Edward Connell <ewconnell@gmail.com> 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 GitHub - apple/swift-protobuf: Plugin and runtime library for using protobuf with Swift, 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 = 0x000000000041146c
(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: 0x000000000041146c 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:
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "CoreFoundation.h"
         ^

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

/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 <dispatch/dispatch.h>
         ^

<module-includes>:1:10: note: in file included from <module-includes>: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 <os/linux_base.h>
         ^

/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 <sys/param.h>
         ^

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

error: could not build C module 'CoreFoundation'

On Mon, Oct 16, 2017 at 11:00 AM, Alex Blewitt <alblue@apple.com> wrote:
> On 16 Oct 2017, at 18:52, Edward Connell <ewconnell@gmail.com> 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>