date:20170301

Re: [swift-users] Ugliness bridging Swift String to char *

2017-03-01 Thread Kenny Leung via swift-users

> On Mar 1, 2017, at 7:08 PM, Kenny Leung via swift-users 
>  wrote:
> 
> If it’s “making very few assumptions”, I would think that, for safety’s sake, 
> functions that return a pointer would always be optional, forcing the user to 
> deal with any possible null pointer returns.
> 

Talking myself into a circle there. We’re not talking about return values, but 
the value of PQprintOpt.fieldSep.

Also interesting - I thought being a IUO meant that you could not set the value 
to nil, but that’s not true. You can!

-Kenny

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

Re: [swift-users] Ugliness bridging Swift String to char *

2017-03-01 Thread Kenny Leung via swift-users

Hi Jordan.

Thanks for the lengthy answer.

> On Mar 1, 2017, at 6:21 PM, Jordan Rose  wrote:
> 
> Hey, Kenny. The const vs non-const part is important, since both the implicit 
> conversion and cString(using:) are allowed to return a pointer to the 
> internal data being used by the String, and modifying that would be breaking 
> the rules (and could potentially cause a crash). In the case of 'fieldSep', 
> it's unlikely that anyone is going to mutate the contents of the string; it 
> was probably just the original author (you?) not bothering to be 
> const-correct. If you control this struct, a better fix would be to use 
> 'const char *' for the field.

This is the PostgreSQL client library, so I don’t really want to change it. 
(Although the source is available. Maybe I should submit a patch…)

> That said, that's not the main isuse. The implicit conversion from String to 
> UnsafePointer is only valid when the string is used as a function 
> argument, because the conversion might need to allocate temporary storage. In 
> that case, it’s important to know when it’s safe to deallocate that storage. 
> For a function call, that’s when the call returns, but for storing into a 
> struct field it’s completely unbounded. So there’s no implicit conversion 
> there.
> 
> If you’re willing to limit your use of the pointer value to a single block of 
> code, you can use withCString 
> :
> 
> myString.withCString {
>   var opt :PQprintOpt = PQprintOpt()
>   opt.fieldSep = UnsafeMutablePointer(mutating: $0)
>   // use 'opt'
> }

Unfortunately, this is not always an option, since there are multiple char * 
files in PQprintOpt. Or could I just nest .withCString calls? Looks ugly, but 
might work, I guess.

> Note that it is illegal to persist the pointer value beyond the execution of 
> withCString, because it might point to a temporary buffer.
> 
> Alternately, if you’re willing to call free() later, you can use the C 
> function strdup:
> 
> opt.fieldSep = strdup(myString)
> // use ‘opt’
> free(opt.fieldSep)
> 
> 
> Of course, all of this is overkill for a string literal. Perhaps when Swift 
> gets conditional conformances, we could consider making UnsafePointer 
> conform to ExpressibleByStringLiteral. Meanwhile, you can use the type 
> designed specifically for this purpose, StaticString 
> :
> 
> let separator: StaticString = “|”
> opt.fieldSep = UnsafeMutablePointer(mutating: separator.utf8start)
> 
> Note that you still have to do the init(mutating:) workaround for the fact 
> that you’re not allowed to mutate this string.

Ah - that's 

>> 
>> Also, why is the conversion to Swift an IUO? NULL is a totally valid value 
>> for fieldSep.
> 
> You're welcome to mark that field as _Nullable on the C side, but without 
> annotations Swift makes very few assumptions about pointers imported from C.

If it’s “making very few assumptions”, I would think that, for safety’s sake, 
functions that return a pointer would always be optional, forcing the user to 
deal with any possible null pointer returns.

> Hope that helps!

Definitely!

-Kenny




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

Re: [swift-users] Is this really a race condition?

2017-03-01 Thread Edward Connell via swift-users

Ahh! thank you. That makes sense.

On Wed, Mar 1, 2017 at 3:29 PM, Guillaume Lessard <
gless...@tffenterprises.com> wrote:

>
> > On Mar 1, 2017, at 3:21 PM, Edward Connell via swift-users <
> swift-users@swift.org> wrote:
> >
> > The thread sanitizer on Linux is reporting that I have race conditions
> in libswiftcore. I eliminated enough code down to this trivial example. Is
> there really a race condition here or are these bogus errors?
> >
> >   let count = 1000
> >   var items = [[UInt8]?](repeating: nil, count: count)
> >
> >   DispatchQueue.concurrentPerform(iterations: count) {
> >   items[$0] = [UInt8](repeating: 7, count: 10)
> >   }
> >
> > My real scenario is retrieving data asynchronously, so I just threw in a
> buffer assignment.
>
> The assignments to array elements are where the race lies.
>
> I don’t know about the libswiftcore part, but: assigning to a shared Array
> concurrently from multiple threads won't work, because of Array's
> copy-on-write behaviour. You could do
>
> let items = UnsafeMutablePointer<[UInt8]?>.allocate(capacity: 1)
> items.initialize(to: nil, count: count)
>
> DispatchQueue.concurrentPerform(iterations: count) {
>   items[$0].initialize([UInt8](repeating: 7, count: 10))
> }
>
> // you’ll be able to see here that they’re all initialized
>
> items.deallocate(capacity: count)
>
> Cheers,
> Guillaume Lessard
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Ugliness bridging Swift String to char *

2017-03-01 Thread Jordan Rose via swift-users

> On Mar 1, 2017, at 14:23, Kenny Leung via swift-users  
> wrote:
> 
> Hi All.
> 
> Swift automatically bridges String to char * when calling C functions. For 
> instance, strlen gets translated as:
> 
> public func strlen(_ __s: UnsafePointer!) -> UInt
> 
> I can call it from Swift like this:
> 
> strlen("|")
> 
> I’m But, I’m working with a C struct containing a char *:
> 
> public struct _PQprintOpt {
> public var header: pqbool /* print output field headings and row 
> count */
> public var align: pqbool /* fill align the fields */
> public var fieldSep: UnsafeMutablePointer! /* field separator */
> ...
> }
> public typealias PQprintOpt = _PQprintOpt
> 
> When I try to assign to fieldSep like this:
> 
> opt.fieldSep = "|"
> 
> I get the error:
> 
> Cannot assign value of type 'String' to type 'UnsafeMutablePointer!'
> 
> I assume that the difference is that strlen declares const char * and 
> fieldSep is simply char *, so strlen is non-mutable while fieldSep is 
> mutable. Is this correct?
> 
> I currently have this ugly hack to get this to work:
> 
> var opt :PQprintOpt = PQprintOpt()
> guard let fieldSeparator = "|".cString(using: .utf8) else {
> throw Errors.databaseConnectionError("Could not set field separator")
> }
> opt.fieldSep = UnsafeMutablePointer(mutating:fieldSeparator)
> 
> Is there a cleaner way this could work, or should this be considered a 
> compiler bug?

Hey, Kenny. The const vs non-const part is important, since both the implicit 
conversion and cString(using:) are allowed to return a pointer to the internal 
data being used by the String, and modifying that would be breaking the rules 
(and could potentially cause a crash). In the case of 'fieldSep', it's unlikely 
that anyone is going to mutate the contents of the string; it was probably just 
the original author (you?) not bothering to be const-correct. If you control 
this struct, a better fix would be to use 'const char *' for the field.

That said, that's not the main isuse. The implicit conversion from String to 
UnsafePointer is only valid when the string is used as a function 
argument, because the conversion might need to allocate temporary storage. In 
that case, it’s important to know when it’s safe to deallocate that storage. 
For a function call, that’s when the call returns, but for storing into a 
struct field it’s completely unbounded. So there’s no implicit conversion there.

If you’re willing to limit your use of the pointer value to a single block of 
code, you can use withCString 
:

myString.withCString {
  var opt :PQprintOpt = PQprintOpt()
  opt.fieldSep = UnsafeMutablePointer(mutating: $0)
  // use 'opt'
}

Note that it is illegal to persist the pointer value beyond the execution of 
withCString, because it might point to a temporary buffer.

Alternately, if you’re willing to call free() later, you can use the C function 
strdup:

opt.fieldSep = strdup(myString)
// use ‘opt’
free(opt.fieldSep)

Of course, all of this is overkill for a string literal. Perhaps when Swift 
gets conditional conformances, we could consider making UnsafePointer 
conform to ExpressibleByStringLiteral. Meanwhile, you can use the type designed 
specifically for this purpose, StaticString 
:

let separator: StaticString = “|”
opt.fieldSep = UnsafeMutablePointer(mutating: separator.utf8start)

Note that you still have to do the init(mutating:) workaround for the fact that 
you’re not allowed to mutate this string.

> 
> Also, why is the conversion to Swift an IUO? NULL is a totally valid value 
> for fieldSep.

You're welcome to mark that field as _Nullable on the C side, but without 
annotations Swift makes very few assumptions about pointers imported from C.

Hope that helps!
Jordan

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

Re: [swift-users] Using withUnsafePointer on char arrays within C structs

2017-03-01 Thread Hooman Mehr via swift-users

Your co-worker needs to get passed the learning curve of these “unsafe” APIs 
and note that Swift arrays are complex data structures. &allZeros does not give 
you a pointer to a bunch of zero bytes, but a pointer to a struct that contains 
the private implementation details of allZeros array. 

Here is the correct way to do it:

func allZerosUUID() -> String {

let allZeros = [UInt8](repeating: 0, count: 32)

return allZeros.withUnsafeBufferPointer { NSUUID(uuidBytes: 
$0.baseAddress).uuidString }
}


> On Mar 1, 2017, at 2:35 PM, Russell Finn via swift-users 
>  wrote:
> 
> Thanks to Joe and Quinn for their answers. I have a related followup — a 
> co-worker learning Swift wrote the following function:
> 
> func allZerosUUID() -> String {
> var allZeros = [UInt8](repeating: 0, count: 32)
> return withUnsafePointer(to: &allZeros) { zerosPtr in
> return NSUUID(uuidBytes: zerosPtr).uuidString
> }
> }
> 
> but was puzzled that Xcode 8.2.1 gave an error "Cannot convert value of type 
> 'UnsafePointer<_>' to expected argument type 'UnsafePointer!'" on the 
> line with the NSUUID initializer.  Their expectation was that `zerosPtr` 
> would be of type `UnsafePointer` because `allZeros` is of type 
> `[UInt8]`.  
> 
> They discovered that they could work around this by adding a call to 
> `withMemoryRebound`:
> 
> func allZerosUUID() -> String {
> var allZeros = [UInt8](repeating: 0, count: 32)
> return withUnsafePointer(to: &allZeros) { zerosPtr in
> zerosPtr.withMemoryRebound(to: UInt8.self, capacity: 
> allZeros.count) { zerosPtr in
> return NSUUID(uuidBytes: zerosPtr).uuidString
> }
> }
> }
> 
> but felt that this should be unnecessary. Perhaps I'm missing something 
> simple, but I was unable to explain this compiler behavior; can anyone on the 
> list do so?
> 
> (Yes, I did point out that they could pass `&allZeros` directly to 
> `NSUUID(uuidBytes:)`.)
> 
> Thanks — Russell
> 
> ___
> 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] Is this really a race condition?

2017-03-01 Thread Guillaume Lessard via swift-users


> On Mar 1, 2017, at 3:21 PM, Edward Connell via swift-users 
>  wrote:
> 
> The thread sanitizer on Linux is reporting that I have race conditions in 
> libswiftcore. I eliminated enough code down to this trivial example. Is there 
> really a race condition here or are these bogus errors?
> 
>   let count = 1000
>   var items = [[UInt8]?](repeating: nil, count: count)
> 
>   DispatchQueue.concurrentPerform(iterations: count) {
>   items[$0] = [UInt8](repeating: 7, count: 10)
>   }
> 
> My real scenario is retrieving data asynchronously, so I just threw in a 
> buffer assignment.

The assignments to array elements are where the race lies.

I don’t know about the libswiftcore part, but: assigning to a shared Array 
concurrently from multiple threads won't work, because of Array's copy-on-write 
behaviour. You could do

let items = UnsafeMutablePointer<[UInt8]?>.allocate(capacity: 1)
items.initialize(to: nil, count: count)

DispatchQueue.concurrentPerform(iterations: count) {
  items[$0].initialize([UInt8](repeating: 7, count: 10))
}

// you’ll be able to see here that they’re all initialized

items.deallocate(capacity: count)

Cheers,
Guillaume Lessard

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

Re: [swift-users] Is this really a race condition?

2017-03-01 Thread Dave Abrahams via swift-users


on Wed Mar 01 2017, Edward Connell  wrote:

> The thread sanitizer on Linux is reporting that I have race conditions in
> libswiftcore. 

The only one we currently know about that's actually in libswiftcore is
the one addressed by https://github.com/apple/swift/pull/7183

> I eliminated enough code down to this trivial example. Is there really
> a race condition here or are these bogus errors?
>
> let count = 1000
> var items = [[UInt8]?](repeating: nil, count: count)
>
> DispatchQueue.concurrentPerform(iterations: count) {
> items[$0] = [UInt8](repeating: 7, count: 10)
> }
>
> My real scenario is retrieving data asynchronously, so I just threw in a
> buffer assignment.


>
> Thanks, Ed
>
> ==
> WARNING: ThreadSanitizer: data race (pid=30720)
>   Read of size 8 at 0x7d908028 by thread T16:
> #0 memcpy  (libtsan.so.0+0x0002617a)
> #1 _TwCcOs31_ClosedRangeIndexRepresentation 
> (libswiftCore.so+0x0027e0fa)
>
>   Previous write of size 8 at 0x7d908028 by main thread:
> #0 memcpy  (libtsan.so.0+0x0002617a)
> #1 _TwCcOs31_ClosedRangeIndexRepresentation 
> (libswiftCore.so+0x0027e0fa)
>
>   Location is heap block of size 8032 at 0x7d908000 allocated by main
> thread:
> #0 malloc  (libtsan.so.0+0x000254a3)
> #1 swift_slowAlloc  (libswiftCore.so+0x002ee3e5)
>
>   Thread T16 (tid=30917, running) created by main thread at:
> #0 pthread_create  (libtsan.so.0+0x00027577)
> #1 manager_workqueue_additem
> /home/buildnode/disk2/workspace/oss-swift-3.0-package-linux-ubuntu-16_04/swift-corelibs-libdispatch/libpwq/src/posix/manager.c:815
> (libdispatch.so+0x0007c6b1)
>
> SUMMARY: ThreadSanitizer: data race ??:0 memcpy
> ==
> ==
> WARNING: ThreadSanitizer: data race (pid=30720)
>   Write of size 8 at 0x7d0c00015d80 by thread T16:
> #0 free  (libtsan.so.0+0x00025819)
> #1 _TwXxOs31_ClosedRangeIndexRepresentation 
> (libswiftCore.so+0x0027e071)
>
>   Previous write of size 8 at 0x7d0c00015d80 by main thread:
> #0 malloc  (libtsan.so.0+0x000254a3)
> #1 swift_slowAlloc  (libswiftCore.so+0x002ee3e5)
>
>   Thread T16 (tid=30917, running) created by main thread at:
> #0 pthread_create  (libtsan.so.0+0x00027577)
> #1 manager_workqueue_additem
> /home/buildnode/disk2/workspace/oss-swift-3.0-package-linux-ubuntu-16_04/swift-corelibs-libdispatch/libpwq/src/posix/manager.c:815
> (libdispatch.so+0x0007c6b1)
>
> SUMMARY: ThreadSanitizer: data race ??:0 __interceptor_free
> ==
> ==
> WARNING: ThreadSanitizer: data race (pid=30720)
>   Write of size 8 at 0x7d90a028 by thread T20:
> #0 free  (libtsan.so.0+0x00025819)
> #1 _TZFSa11_copyBufferfRGVs22_ContiguousArrayBufferx_T_ 
> (libswiftCore.so+0x0010884e)
>
>   Previous read of size 8 at 0x7d90a028 by thread T17:
> #0 memcpy  (libtsan.so.0+0x0002617a)
> #1 _TwCcOs31_ClosedRangeIndexRepresentation 
> (libswiftCore.so+0x0027e0fa)
>
>   Thread T20 (tid=30921, running) created by main thread at:
> #0 pthread_create  (libtsan.so.0+0x00027577)
> #1 manager_workqueue_additem
> /home/buildnode/disk2/workspace/oss-swift-3.0-package-linux-ubuntu-16_04/swift-corelibs-libdispatch/libpwq/src/posix/manager.c:815
> (libdispatch.so+0x0007c6b1)
>
>   Thread T17 (tid=30918, running) created by main thread at:
> #0 pthread_create  (libtsan.so.0+0x00027577)
> #1 manager_workqueue_additem
> /home/buildnode/disk2/workspace/oss-swift-3.0-package-linux-ubuntu-16_04/swift-corelibs-libdispatch/libpwq/src/posix/manager.c:815
> (libdispatch.so+0x0007c6b1)
>
> SUMMARY: ThreadSanitizer: data race ??:0 __interceptor_free
> ==
> ==
> WARNING: ThreadSanitizer: data race (pid=30720)
>   Read of size 8 at 0x7d906028 by thread T23:
> #0 memcpy  (libtsan.so.0+0x0002617a)
> #1 _TwCcOs31_ClosedRangeIndexRepresentation 
> (libswiftCore.so+0x0027e0fa)
>
>   Previous write of size 8 at 0x7d906028 by main thread:
> #0 malloc  (libtsan.so.0+0x000254a3)
> #1 swift_slowAlloc  (libswiftCore.so+0x002ee3e5)
>
>   Location is heap block of size 8032 at 0x7d906000 allocated by main
> thread:
> #0 malloc  (libtsan.so.0+0x000254a3)
> #1 swift_slowAlloc  (libswiftCore.so+0x002ee3e5)
>
>   Thread T23 (tid=30924, running) created by main thread at:
> #0 pthread_create  (libtsan.so.0+0x00027577)
> #1 manager_workqueue_additem
> /home/buildnode/disk2/workspace/oss-swift-3.0-package-linux-ubuntu-16_04/swift-corelibs-libdispatch/libpwq/src/posix/manager.c:815
> (libdispatch.so+0x0007c6b1)
>
> SUMMARY: ThreadSanitizer: data race ??:0 memcpy
> ==
> ==
> WARNING: ThreadSanitizer: data race (pid=30720)
>   Write of size 8 at 0x7d92e000 by thread T19:
> #0 free  (libtsan.so.0+0x00025819)
> #1 _TZFSa11_copyBufferfRGVs22_ContiguousA

Re: [swift-users] Using withUnsafePointer on char arrays within C structs

2017-03-01 Thread Russell Finn via swift-users

Thanks to Joe and Quinn for their answers. I have a related followup — a
co-worker learning Swift wrote the following function:

func allZerosUUID() -> String {
var allZeros = [UInt8](repeating: 0, count: 32)
return withUnsafePointer(to: &allZeros) { zerosPtr in
return NSUUID(uuidBytes: zerosPtr).uuidString
}
}

but was puzzled that Xcode 8.2.1 gave an error "Cannot convert value of
type 'UnsafePointer<_>' to expected argument type 'UnsafePointer!'"
on the line with the NSUUID initializer.  Their expectation was that
`zerosPtr` would be of type `UnsafePointer` because `allZeros` is of
type `[UInt8]`.

They discovered that they could work around this by adding a call to
`withMemoryRebound`:

func allZerosUUID() -> String {
var allZeros = [UInt8](repeating: 0, count: 32)
return withUnsafePointer(to: &allZeros) { zerosPtr in
zerosPtr.withMemoryRebound(to: UInt8.self, capacity:
allZeros.count) { zerosPtr in
return NSUUID(uuidBytes: zerosPtr).uuidString
}
}
}

but felt that this should be unnecessary. Perhaps I'm missing something
simple, but I was unable to explain this compiler behavior; can anyone on
the list do so?

(Yes, I did point out that they could pass `&allZeros` directly to
`NSUUID(uuidBytes:)`.)

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

[swift-users] Ugliness bridging Swift String to char *

2017-03-01 Thread Kenny Leung via swift-users

Hi All.

Swift automatically bridges String to char * when calling C functions. For 
instance, strlen gets translated as:

public func strlen(_ __s: UnsafePointer!) -> UInt

I can call it from Swift like this:

strlen("|")

I’m But, I’m working with a C struct containing a char *:

public struct _PQprintOpt {
public var header: pqbool /* print output field headings and row count 
*/
public var align: pqbool /* fill align the fields */
public var fieldSep: UnsafeMutablePointer! /* field separator */
...
}
public typealias PQprintOpt = _PQprintOpt

When I try to assign to fieldSep like this:

opt.fieldSep = "|"

I get the error:

Cannot assign value of type 'String' to type 'UnsafeMutablePointer!'

I assume that the difference is that strlen declares const char * and fieldSep 
is simply char *, so strlen is non-mutable while fieldSep is mutable. Is this 
correct?

I currently have this ugly hack to get this to work:

var opt :PQprintOpt = PQprintOpt()
guard let fieldSeparator = "|".cString(using: .utf8) else {
throw Errors.databaseConnectionError("Could not set field separator")
}
opt.fieldSep = UnsafeMutablePointer(mutating:fieldSeparator)

Is there a cleaner way this could work, or should this be considered a compiler 
bug?

Also, why is the conversion to Swift an IUO? NULL is a totally valid value for 
fieldSep.

Thanks!

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

[swift-users] Is this really a race condition?

2017-03-01 Thread Edward Connell via swift-users

The thread sanitizer on Linux is reporting that I have race conditions in
libswiftcore. I eliminated enough code down to this trivial example. Is
there really a race condition here or are these bogus errors?

let count = 1000
var items = [[UInt8]?](repeating: nil, count: count)

DispatchQueue.concurrentPerform(iterations: count) {
items[$0] = [UInt8](repeating: 7, count: 10)
}

My real scenario is retrieving data asynchronously, so I just threw in a
buffer assignment.

Thanks, Ed

==
WARNING: ThreadSanitizer: data race (pid=30720)
  Read of size 8 at 0x7d908028 by thread T16:
#0 memcpy  (libtsan.so.0+0x0002617a)
#1 _TwCcOs31_ClosedRangeIndexRepresentation 
(libswiftCore.so+0x0027e0fa)

  Previous write of size 8 at 0x7d908028 by main thread:
#0 memcpy  (libtsan.so.0+0x0002617a)
#1 _TwCcOs31_ClosedRangeIndexRepresentation 
(libswiftCore.so+0x0027e0fa)

  Location is heap block of size 8032 at 0x7d908000 allocated by main
thread:
#0 malloc  (libtsan.so.0+0x000254a3)
#1 swift_slowAlloc  (libswiftCore.so+0x002ee3e5)

  Thread T16 (tid=30917, running) created by main thread at:
#0 pthread_create  (libtsan.so.0+0x00027577)
#1 manager_workqueue_additem
/home/buildnode/disk2/workspace/oss-swift-3.0-package-linux-ubuntu-16_04/swift-corelibs-libdispatch/libpwq/src/posix/manager.c:815
(libdispatch.so+0x0007c6b1)

SUMMARY: ThreadSanitizer: data race ??:0 memcpy
==
==
WARNING: ThreadSanitizer: data race (pid=30720)
  Write of size 8 at 0x7d0c00015d80 by thread T16:
#0 free  (libtsan.so.0+0x00025819)
#1 _TwXxOs31_ClosedRangeIndexRepresentation 
(libswiftCore.so+0x0027e071)

  Previous write of size 8 at 0x7d0c00015d80 by main thread:
#0 malloc  (libtsan.so.0+0x000254a3)
#1 swift_slowAlloc  (libswiftCore.so+0x002ee3e5)

  Thread T16 (tid=30917, running) created by main thread at:
#0 pthread_create  (libtsan.so.0+0x00027577)
#1 manager_workqueue_additem
/home/buildnode/disk2/workspace/oss-swift-3.0-package-linux-ubuntu-16_04/swift-corelibs-libdispatch/libpwq/src/posix/manager.c:815
(libdispatch.so+0x0007c6b1)

SUMMARY: ThreadSanitizer: data race ??:0 __interceptor_free
==
==
WARNING: ThreadSanitizer: data race (pid=30720)
  Write of size 8 at 0x7d90a028 by thread T20:
#0 free  (libtsan.so.0+0x00025819)
#1 _TZFSa11_copyBufferfRGVs22_ContiguousArrayBufferx_T_ 
(libswiftCore.so+0x0010884e)

  Previous read of size 8 at 0x7d90a028 by thread T17:
#0 memcpy  (libtsan.so.0+0x0002617a)
#1 _TwCcOs31_ClosedRangeIndexRepresentation 
(libswiftCore.so+0x0027e0fa)

  Thread T20 (tid=30921, running) created by main thread at:
#0 pthread_create  (libtsan.so.0+0x00027577)
#1 manager_workqueue_additem
/home/buildnode/disk2/workspace/oss-swift-3.0-package-linux-ubuntu-16_04/swift-corelibs-libdispatch/libpwq/src/posix/manager.c:815
(libdispatch.so+0x0007c6b1)

  Thread T17 (tid=30918, running) created by main thread at:
#0 pthread_create  (libtsan.so.0+0x00027577)
#1 manager_workqueue_additem
/home/buildnode/disk2/workspace/oss-swift-3.0-package-linux-ubuntu-16_04/swift-corelibs-libdispatch/libpwq/src/posix/manager.c:815
(libdispatch.so+0x0007c6b1)

SUMMARY: ThreadSanitizer: data race ??:0 __interceptor_free
==
==
WARNING: ThreadSanitizer: data race (pid=30720)
  Read of size 8 at 0x7d906028 by thread T23:
#0 memcpy  (libtsan.so.0+0x0002617a)
#1 _TwCcOs31_ClosedRangeIndexRepresentation 
(libswiftCore.so+0x0027e0fa)

  Previous write of size 8 at 0x7d906028 by main thread:
#0 malloc  (libtsan.so.0+0x000254a3)
#1 swift_slowAlloc  (libswiftCore.so+0x002ee3e5)

  Location is heap block of size 8032 at 0x7d906000 allocated by main
thread:
#0 malloc  (libtsan.so.0+0x000254a3)
#1 swift_slowAlloc  (libswiftCore.so+0x002ee3e5)

  Thread T23 (tid=30924, running) created by main thread at:
#0 pthread_create  (libtsan.so.0+0x00027577)
#1 manager_workqueue_additem
/home/buildnode/disk2/workspace/oss-swift-3.0-package-linux-ubuntu-16_04/swift-corelibs-libdispatch/libpwq/src/posix/manager.c:815
(libdispatch.so+0x0007c6b1)

SUMMARY: ThreadSanitizer: data race ??:0 memcpy
==
==
WARNING: ThreadSanitizer: data race (pid=30720)
  Write of size 8 at 0x7d92e000 by thread T19:
#0 free  (libtsan.so.0+0x00025819)
#1 _TZFSa11_copyBufferfRGVs22_ContiguousArrayBufferx_T_ 
(libswiftCore.so+0x00108859)

  Previous write of size 8 at 0x7d92e000 by thread T20:
#0 malloc  (libtsan.so.0+0x000254a3)
#1 swift_slowAlloc  (libswiftCore.so+0x002ee3e5)

  Thread T19 (tid=30920, running) created by main thread at:
#0 pthread_create  (libtsan.so.0+0x00027577)
#1 manager_workqueue_additem
/home/buildnode/disk2/workspace/oss-

Re: [swift-users] Ugliness bridging Swift String to char *

Re: [swift-users] Ugliness bridging Swift String to char *

Re: [swift-users] Is this really a race condition?

Re: [swift-users] Ugliness bridging Swift String to char *

Re: [swift-users] Using withUnsafePointer on char arrays within C structs

Re: [swift-users] Is this really a race condition?

Re: [swift-users] Is this really a race condition?

Re: [swift-users] Using withUnsafePointer on char arrays within C structs

[swift-users] Ugliness bridging Swift String to char *

[swift-users] Is this really a race condition?

10 matches

Site Navigation

Mail list logo

Footer information