Re: [swift-users] Why does the withUnsafeMutableBufferPointer closure take an inout parameter?

2017-10-13 Thread Andrew Trick via swift-users


> On Oct 12, 2017, at 3:52 AM, Geordie Jay via swift-users 
>  wrote:
> 
> 
> Guillaume Lessard via swift-users  > schrieb am Mi. 11. Okt. 2017 um 23:49:
> A lot of the MutableCollection implementation is in protocol extensions 
> (swapAt, for example.)
> 
> Should an additional version be written just for the Unsafe*BufferPointer 
> types?
> 
> Makes sense to me, given the examples above. It doesn’t seem to be a high 
> priority task though, and one one suited to a contributor pull request rather 
> than taking resources away from the core team.
> 
> Would this kind of change need to go through swift evolution or is it a “no 
> brainer”?
> 
> Geordie

I’ll just point out that it’s already the case that methods defined in 
Unsafe*BufferPointer that write to memory are “nonmutating”. So I think it’s 
both a “no brainer” and needs to go through evolution.

-Andy

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


Re: [swift-users] Swift 4.0 LLDBFrontend Crash

2017-10-13 Thread 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

2017-10-13 Thread 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