apple / swift-corelibs-libdispatch Goto Github PK
View Code? Open in Web Editor NEWThe libdispatch Project, (a.k.a. Grand Central Dispatch), for concurrency on multicore hardware
Home Page: swift.org
License: Apache License 2.0
The libdispatch Project, (a.k.a. Grand Central Dispatch), for concurrency on multicore hardware
Home Page: swift.org
License: Apache License 2.0
Previous ID | SR-2107 |
Radar | None |
Original Reporter | sandmman (JIRA User) |
Type | Bug |
OSX Xcode 8
Votes | 1 |
Component/s | libdispatch |
Labels | Bug, SDKOverlay |
Assignee | None |
Priority | Medium |
md5: 8a4cf83f85fd0da59a4731c667e0be19
Issue Description:
Although the previous iteration of dispatch_io_read() allows you to pass the value SIZE_MAX as the length in order to read the entire file until an EOF character is reached, DispatchIO.read() no longer supports this. Instead giving the value ```Int.max``` leads the channel to wait indefinitely until the max size is available to read.
Previous ID | SR-3335 |
Radar | rdar://problem/29513290 |
Original Reporter | @weissi |
Type | Bug |
Status | Resolved |
Resolution | Done |
Attachment: Download
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, RunTimeCrash |
Assignee | None |
Priority | Medium |
md5: 3292f2ad5755906bf415eb0320ddb747
Issue Description:
I was trying to reproduce some hang I'm sometimes seeing with DispatchIO (still possible to be somewhere in my code). Whilst trying to come up with a repro program I reached a stage of a program, that reliably crashes on macOS and Linux.
* thread #​17: tid = 29284, 0x00007ffff7f17b07 libdispatch.so`_os_object_retain + 23, name = 'repro', stop reason = signal SIGILL: illegal instruction operand
* frame #​0: 0x00007ffff7f17b07 libdispatch.so`_os_object_retain + 23
frame #​1: 0x00007ffff7f13a64 libdispatch.so`dispatch_io_write + 36
frame #​2: 0x00007ffff7f2e170 libdispatch.so`_TFC8Dispatch10DispatchIO5writefT6offsetSi4dataVS_12DispatchData5queueCS_13DispatchQueue9ioHandlerFTSbGSqS1__Vs5Int32_T__T_ + 208
frame #​3: 0x0000000000404548 repro`_TFFFF5repro4mainFT_T_U_FTVs5Int32S0__T_U3_FTSbGSqV8Dispatch12DispatchData_S0__T_U_FT_T_ + 104
frame #​4: 0x00000000004046a7 repro`_TTRXFo___XFdCb___ + 39
frame #​5: 0x00007ffff7f10e37 libdispatch.so`_dispatch_call_block_and_release + 7
frame #​6: 0x00007ffff7f1d2f1 libdispatch.so`_dispatch_queue_serial_drain + 737
frame #​7: 0x00007ffff7f1d931 libdispatch.so`_dispatch_queue_invoke + 849
frame #​8: 0x00007ffff7f1f9a9 libdispatch.so`_dispatch_root_queue_drain + 393
frame #​9: 0x00007ffff7f44408 libdispatch.so`overcommit_worker_main(unused=<unavailable>) + 152 at manager.c:315
frame #​10: 0x00007ffff77dc70a libpthread.so.0`start_thread + 202
frame #​11: 0x00007ffff5d7382d libc.so.6`__clone + 109 at clone.S:109
1. compile and the attached program (swiftc repro.swift && ./repro
)
2. you'll see crashes
$ swift -version
Swift version 3.0-dev (LLVM 56c58af739, Clang 205968da71, Swift e60daaaee1)
Target: x86_64-unknown-linux-gnu
$ swift -version
Apple Swift version 3.0.1 (swiftlang-800.0.58.6 clang-800.0.42.1)
Target: x86_64-apple-macosx10.9
Previous ID | SR-3237 |
Radar | None |
Original Reporter | @norio-nomura |
Type | Bug |
Status | Closed |
Resolution | Done |
Attachment: Download
cb59f92 on swift-corelibs-libdispatch
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, Linux |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
md5: 318e5933452f25454b8195ab348ee2cc
Issue Description:
`/usr/bin/vi` is not installed by default on Ubuntu 16.04.
So, `dispatch_io_net` and `dispatch_select` fail without explicitly installing `/usr/bin/vi`.
Previous ID | SR-1843 |
Radar | None |
Original Reporter | @DevAndArtist |
Type | Bug |
Swift 3 from first Xcode 8 beta.
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, SDKOverlay |
Assignee | mww (JIRA) |
Priority | Medium |
md5: 0a7dbaaa991f1ff9845f0d281525f77f
Issue Description:
Please check this diffs between `DispatchData` and `Data`, not all api parts are identical, where some of them should be. As an example different range types are used or labels and generic type `Result` vs. `ResultType` don't match.
Here is a formatted gist: https://gist.github.com/DevAndArtist/4f1cef7a0d58cc786e6ed1837a107a0c
Here is the raw diff:
- public struct Data : ReferenceConvertible, CustomStringConvertible, Equatable, Hashable, RandomAccessCollection, MutableCollection {
+ public struct DispatchData : RandomAccessCollection {
- public typealias ReferenceType = NSData
- public typealias ReadingOptions = NSData.ReadingOptions
- public typealias WritingOptions = NSData.WritingOptions
- public typealias SearchOptions = NSData.SearchOptions
- public typealias Base64EncodingOptions = NSData.Base64EncodingOptions
- public typealias Base64DecodingOptions = NSData.Base64DecodingOptions
+ public typealias Iterator = DispatchDataIterator
public typealias Index = Int
- public typealias Indices = DefaultRandomAccessIndices<Data>
+ public typealias Indices = DefaultRandomAccessIndices<DispatchData>
+ public static let empty: DispatchData
public enum Deallocator {
- case virtualMemory
- case none
case free
case unmap
- case custom((UnsafeMutablePointer<UInt8>, Int) -> Swift.Void)
+ case custom(DispatchQueue?, @convention(block) () -> Swift.Void)
}
- public init(bytes: UnsafePointer<UInt8>, count: Int)
- public init(bytes: [UInt8])
- public init(bytes: ArraySlice<UInt8>)
- public init?(capacity: Int)
- public init()
- public init(contentsOf url: URL, options: ReadingOptions = default) throws
- public init?(base64Encoded base64String: String, options: Base64EncodingOptions = default)
- public init?(base64Encoded base64Data: Data, options: Base64DecodingOptions = default)
- public init<SourceType>(buffer: UnsafeBufferPointer<SourceType>)
+ public init(bytes buffer: UnsafeBufferPointer<UInt8>)
- public init(bytesNoCopy bytes: UnsafeMutablePointer<UInt8>, count: Int, deallocator: Data.Deallocator)
+ public init(bytesNoCopy bytes: UnsafeBufferPointer<UInt8>, deallocator: DispatchData.Deallocator = default)
- public var count: Int
+ public var count: Int { get }
- public func withUnsafeBytes<ResultType, ContentType>(_ body: @noescape (UnsafePointer<ContentType>) throws -> ResultType) rethrows -> ResultType
+ public func withUnsafeBytes<Result, ContentType>(body: @noescape (UnsafePointer<ContentType>) throws -> Result) rethrows -> Result
- public mutating func withUnsafeMutableBytes<ResultType, ContentType>(_ body: @noescape (UnsafeMutablePointer<ContentType>) throws -> ResultType) rethrows -> ResultType
- public func enumerateBytes(_ block: @noescape (buffer: UnsafeBufferPointer<UInt8>, byteIndex: Index, stop: inout Bool) -> Swift.Void)
+ public func enumerateBytes(block: @noescape (buffer: UnsafeBufferPointer<UInt8>, byteIndex: Int, stop: inout Bool) -> Swift.Void)
public mutating func append(_ bytes: UnsafePointer<UInt8>, count: Int)
- public mutating func append(_ other: Data)
+ public mutating func append(_ other: DispatchData)
public mutating func append<SourceType>(_ buffer: UnsafeBufferPointer<SourceType>)
public func copyBytes(to pointer: UnsafeMutablePointer<UInt8>, count: Int)
- public func copyBytes(to pointer: UnsafeMutablePointer<UInt8>, from range: Range<Index>)
+ public func copyBytes(to pointer: UnsafeMutablePointer<UInt8>, from range: CountableRange<Index>)
- public func copyBytes<DestinationType>(to buffer: UnsafeMutableBufferPointer<DestinationType>, from range: Range<Index>? = default) -> Int
+ public func copyBytes<DestinationType>(to buffer: UnsafeMutableBufferPointer<DestinationType>, from range: CountableRange<Index>? = default) -> Int
- public subscript(index: Index) -> UInt8
+ public subscript(index: Index) -> UInt8 { get }
- public subscript(bounds: Range<Int>) -> MutableRandomAccessSlice<Data>
+ public subscript(bounds: Range<Int>) -> RandomAccessSlice<DispatchData> { get }
- public func subdata(in range: Range<Index>) -> Data
+ public func subdata(in range: CountableRange<Index>) -> DispatchData
+ public func region(location: Int) -> (data: DispatchData, offset: Int)
- public func write(to url: URL, options: WritingOptions = default) throws
- public func range(of dataToFind: Data, options: SearchOptions = default, in range: Range<Index>? = default) -> Range<Index>?
- public mutating func resetBytes(in range: Range<Index>)
- public mutating func replaceBytes(in range: Range<Index>, with data: Data)
- public func base64EncodedString(_ options: Base64EncodingOptions = default) -> String
- public func base64EncodedData(_ options: Base64EncodingOptions = default) -> Data
- public var hashValue: Int { get }
- public var description: String { get }
- public var debugDescription: String { get }
public var startIndex: Index { get }
public var endIndex: Index { get }
public func index(before i: Index) -> Index
public func index(after i: Index) -> Index
public func makeIterator() -> Iterator
}
Previous ID | SR-1923 |
Radar | None |
Original Reporter | @phausler |
Type | Bug |
Status | Resolved |
Resolution | Done |
Votes | 1 |
Component/s | libdispatch |
Labels | Bug |
Assignee | None |
Priority | Medium |
md5: f5f4c29f9470e2d6aab03501b79a0183
Issue Description:
On Ubuntu 15 with the build command of ./swift/utils/build-script -r --foundation --libdispatch
Swift fails to compile modular components for dispatch:
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "dispatch.h"
^
/home/phausler/Documents/Public/swift-corelibs-libdispatch/dispatch/dispatch.h:60:10: note: in file included from /home/phausler/Documents/Public/swift-corelibs-libdispatch/dispatch/dispatch.h:60:
#include <dispatch/io.h>
^
/home/phausler/Documents/Public/swift-corelibs-libdispatch/dispatch/io.h:359:2: error: declaration of 'off_t' must be imported from module 'SwiftGlibc.C.stdio' before it is required
off_t offset,
^
/usr/include/stdio.h:90:17: note: previous declaration is here
typedef __off_t off_t;
^
Previous ID | SR-2067 |
Radar | None |
Original Reporter | @benrimmington |
Type | Bug |
Status | Resolved |
Resolution | Invalid |
Votes | 0 |
Component/s | libdispatch |
Labels | Bug |
Assignee | None |
Priority | Medium |
md5: f10b64976294121428aa121f98d69a24
Issue Description:
The _dispatch_get_host_time_init
function in swift-corelibs-libdispatch/src/time.c contains:
LARGE_INTEGER freq;
dispatch_assume(QueryPerformanceFrequency(&freq));
_dispatch_host_time_data.frac = (long double)NSEC_PER_SEC /
(long double)freq.QuadPart;
_dispatch_host_time_data.ratio_1_to_1 = (freq.QuadPart == 1);
QueryPerformanceFrequency is in Hertz (i.e. counts per second), so (freq.QuadPart == 1)
seems wrong. Should it be (freq.QuadPart == NSEC_PER_SEC)
instead?
Previous ID | SR-1242 |
Radar | None |
Original Reporter | @drewcrawford |
Type | Bug |
Status | Closed |
Resolution | Done |
Attachment: Download
swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a
linux x64
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, BuildScript |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
md5: 5b44bab98d2e303c59f3b525ea5019f3
Issue Description:
When building libdispatch as part of the build-script, I get the following compile failure:
libdispatch: using standard linker
+ [[ ! -f /swift-dev/build/buildbot_linux/libdispatch-linux-x86_64/config.status ]]
+ pushd /swift-dev/build/buildbot_linux/libdispatch-linux-x86_64
/swift-dev/build/buildbot_linux/libdispatch-linux-x86_64 /swift-dev/swift
+ make
Making all in dispatch
make[1]: Entering directory '/swift-dev/build/buildbot_linux/libdispatch-linux-x86_64/dispatch'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/swift-dev/build/buildbot_linux/libdispatch-linux-x86_64/dispatch'
Making all in man
make[1]: Entering directory '/swift-dev/build/buildbot_linux/libdispatch-linux-x86_64/man'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/swift-dev/build/buildbot_linux/libdispatch-linux-x86_64/man'
Making all in os
make[1]: Entering directory '/swift-dev/build/buildbot_linux/libdispatch-linux-x86_64/os'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/swift-dev/build/buildbot_linux/libdispatch-linux-x86_64/os'
Making all in private
make[1]: Entering directory '/swift-dev/build/buildbot_linux/libdispatch-linux-x86_64/private'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/swift-dev/build/buildbot_linux/libdispatch-linux-x86_64/private'
Making all in src
make[1]: Entering directory '/swift-dev/build/buildbot_linux/libdispatch-linux-x86_64/src'
make all-am
make[2]: Entering directory '/swift-dev/build/buildbot_linux/libdispatch-linux-x86_64/src'
make[2]: Nothing to be done for 'all-am'.
make[2]: Leaving directory '/swift-dev/build/buildbot_linux/libdispatch-linux-x86_64/src'
make[1]: Leaving directory '/swift-dev/build/buildbot_linux/libdispatch-linux-x86_64/src'
Making all in tests
make[1]: Entering directory '/swift-dev/build/buildbot_linux/libdispatch-linux-x86_64/tests'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/swift-dev/build/buildbot_linux/libdispatch-linux-x86_64/tests'
make[1]: Entering directory '/swift-dev/build/buildbot_linux/libdispatch-linux-x86_64'
make[1]: Nothing to be done for 'all-am'.
make[1]: Leaving directory '/swift-dev/build/buildbot_linux/libdispatch-linux-x86_64'
+ cd tests
+ make build-tests
/bin/bash ../libtool --tag=CC --mode=link clang -Wall -Wno-deprecated-declarations -fblocks -I/usr/include/kqueue -isystem /usr/include/bsd -DLIBBSD_OVERLAY -g -O2 -o dispatch_apply dispatch_apply.o libbsdtests.la ../src/libdispatch.la -lkqueue -lpthread_workqueue -lbsd -lpthread -lBlocksRuntime
libtool: link: clang -Wall -Wno-deprecated-declarations -fblocks -I/usr/include/kqueue -isystem /usr/include/bsd -DLIBBSD_OVERLAY -g -O2 -o .libs/dispatch_apply dispatch_apply.o ./.libs/libbsdtests.a ../src/.libs/libdispatch.so -lkqueue -lpthread_workqueue -lbsd -lpthread -lBlocksRuntime -Wl,-rpath -Wl,/tmp/install///usr/lib/swift/linux
../src/.libs/libdispatch.so: undefined reference to `pthread_workqueue_signal_np'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:1121: recipe for target 'dispatch_apply' failed
make: *** [dispatch_apply] Error 1
./utils/build-script: command terminated with a non-zero exit status 2, aborting
./utils/build-script: command terminated with a non-zero exit status 1, aborting
root@7ebb6c41d1b4:/swift-dev/swift#
This is new behavior in swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a, and it only reproduces via build script.
I currently work around with the attached patch to disable the test that produces this error.
I encounter this error even with skip-test-libdispatch=1
, which IMO should not even compile these tests.
I'm setting component to libdispatch, although it may be an infrastructure bug.
Previous ID | SR-2905 |
Radar | None |
Original Reporter | fumoboy007 (JIRA User) |
Type | Bug |
Linux, Swift 3.0
Votes | 1 |
Component/s | libdispatch |
Labels | Bug |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
md5: ef7acc516d0911e996748b91cd397e7a
Issue Description:
Consider this code:
for i in 1...100 {
DispatchQueue.global().async {
print(i)
sleep(1000)
}
}
dispatchMain()
Environment: Linux, 8 cores
Expected outcome: The first 8 work items start running. When the threads block on the sleep
system call, the manager creates additional threads so that the number of active threads is always 8.
Actual outcome: The first 8 work items start running. Then every 1 second, one new work item runs. It takes 93 seconds for all the print
statements to run.
There are actually two issues here.
The first issue is, on every run of the manager, the manager only creates 1 additional worker thread even though all of the existing threads are blocked. Instead, it should create min(num_blocked_threads, cpu_count)
worker threads so that we always have cpu_count
active threads.
The second issue is the manager only runs once a second. I assume this is to prevent the manager thread from taking away significant CPU time from other threads. Is it possible to achieve the same result by using thread priorities? In other words, can we set the manager thread priority to a special number such that the thread scheduler will only schedule it when the CPU is idle?
Previous ID | SR-2335 |
Radar | None |
Original Reporter | simplgy (JIRA User) |
Type | Bug |
Status | Closed |
Resolution | Invalid |
Attachment: Download
xcode 8 beta 5 swift playground
Votes | 0 |
Component/s | libdispatch |
Labels | Bug |
Assignee | mww (JIRA) |
Priority | Medium |
md5: 5aa17a8014b440a37a6e61bebde2a063
Issue Description:
I probably have this wrong because concurrent design is new to me, but I'm maintaining another developers code and the threading behavior appears to have changed since upgrading to xcode 8 beta 5.
I have isolated the unexpected behavior from our application into this test case (playground attached):
let q = DispatchQueue(label: "q", attributes: .concurrent)
q.async(flags: .barrier) {
Thread.sleep(forTimeInterval: 0.25)
print("A")
}
q.sync {
print("B")
}
This prints first "B", then "A". I don't believe it used to in xcode 7, or our views would have sometimes not gotten update notifications.
Should this print "A" first or "B" first?
Previous ID | SR-1935 |
Radar | None |
Original Reporter | frankeh (JIRA User) |
Type | Bug |
Status | Resolved |
Resolution | Done |
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, Linux |
Assignee | frankeh (JIRA) |
Priority | Medium |
md5: 9b6f4f5e214d0703592fc4ce8e1083fe
Issue Description:
Current test case dispatch_timer_short exposes the granularity of timers.
On MacOS it resolves into usec level, while libdispatch on linux utilizes kqueue/kevents which only provide a 1msec granularity. Subsequent kevent64 expansion that are not available on linux do provide this granularity.
A simple hack to force libdispatch to sent nsec granularity to kqueue and kqueue interpreting timers with nsec instead of msec granularity lowers the delays from 2msec to 67usec. MacOS achieves 10usec.
Next step is to expand kevent EVFILTER_TIMER with the functionality provided in kevent64 and approach mheilly for comments.
Previous ID | SR-2181 |
Radar | rdar://problem/79952338 |
Original Reporter | @lilyball |
Type | Bug |
swift-DEVELOPMENT-SNAPSHOT-2016-07-25-a-125-g3331dc4
Votes | 0 |
Component/s | libdispatch |
Labels | Bug |
Assignee | None |
Priority | Medium |
md5: fd6368c309cba792844d510ee431fa26
Issue Description:
DispatchTimeInterval
is defined in terms of an Int
. This isn't going to work well on a 32-bit architectures for nanoseconds, because it will only be able to represent just over 2 seconds worth of nanoseconds. There's a reason why the underlying APIs use UInt64
instead of a platform-defined integer.
Previous ID | SR-740 |
Radar | None |
Original Reporter | @drewcrawford |
Type | Bug |
Status | Resolved |
Resolution | Won't Do |
Linux x64
swift-DEVELOPMENT-SNAPSHOT-2016-02-08-a
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, Linux |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
md5: 12999cfe1773782d3e3be803c7f86303
Issue Description:
in Darwin, the following program is legal:
import Dispatch
let a: AnyObject = dispatch_semaphore_create(0)
On Linux, it produces the error:
error: value of type 'dispatch_semaphore_t' (aka 'COpaquePointer') does not conform to specified type 'AnyObject'
Previous ID | SR-1771 |
Radar | rdar://problem/26879337 |
Original Reporter | @glessard |
Type | Bug |
Status | Resolved |
Resolution | Done |
Xcode 8 (beta, 8S128d) with Swift 3.0 preview 1
Votes | 0 |
Component/s | libdispatch |
Labels | Bug |
Assignee | mww (JIRA) |
Priority | Medium |
md5: 52712f7caaefd132adb681de084a9a62
Issue Description:
A workaround is to compare the .rawValue properties – clunky.
Previous ID | SR-2205 |
Radar | rdar://problem/34535228 |
Original Reporter | mominul (JIRA User) |
Type | Bug |
Attachment: Download
DEVELOPMENT-SNAPSHOT-2016-07-25
Ubuntu 16.04
Votes | 15 |
Component/s | libdispatch |
Labels | Bug, Linux |
Assignee | None |
Priority | Medium |
md5: 76b3df295dd2c0f2cbc48f0a20b3a982
is duplicated by:
relates to:
Issue Description:
I come across of this situation when I was trying to compile my code as statically linked with stdlib.
If I compile my code without importing Foundation with -static-stdlib flag, the compilation succeeds.
But the actual error occurs when I try to import Foundation. As the linker fails when linking with Foundation.
/usr/bin/ld.gold: error: cannot find -lFoundation
/tmp/main-0993c4.o:/tmp/main-0993c4.o:function main: error: undefined reference to '_TMaC10Foundation8NSString'
/tmp/main-0993c4.o:/tmp/main-0993c4.o:function main: error: undefined reference to 'TFC10Foundation8NSStringCfT13stringLiteralVs12StaticString_S0'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
<unknown>:0: error: link command failed with exit code 1 (use -v to see invocation)
As I tried to inspect the error with my little knowledge, here is the fact that took my attention:
Without the `-static-stdlib` flag the library search path is set as /path/to/swift/usr/lib/swift/linux
where the shared libraries are stored including Foundation.
But with the `-static-stdlib` flag the library search path is set as /path/to/swift/usr/lib/swift_static/linux
where the static libraries are stored excluding Foundation.
So linker is innocent!
Can it be solved by adding statically linked copy of Foundation?
So is there any solutions? Can I compile my code statically linked with stdlib and Foundation?
To reproduce it, is very easy
import Glibc
//import Foundation
//var str: NSString = "Hello"
//print(str)
print("Hello, world!")
exit(1)
Thanks!
Previous ID | SR-2903 |
Radar | None |
Original Reporter | @rxwei |
Type | Bug |
Status | Closed |
Resolution | Cannot Reproduce |
Fedora 24, release without assertion
Votes | 0 |
Component/s | Compiler, libdispatch |
Labels | Bug, BuildScript, CompilerCrash |
Assignee | @belkadan |
Priority | Medium |
md5: 82be3c5b0d482c093529e4c963ba2b60
Issue Description:
config.status: executing modulemaps commands
+ popd
~/tmp/swiftbuild/swift
+ pushd /mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64
/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64 ~/tmp/swiftbuild/swift
+ make
Making all in dispatch
make[1]: Entering directory '/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/dispatch'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/dispatch'
Making all in man
make[1]: Entering directory '/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/man'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/man'
Making all in os
make[1]: Entering directory '/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/os'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/os'
Making all in private
make[1]: Entering directory '/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/private'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/private'
Making all in src
make[1]: Entering directory '/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/src'
make all-am
make[2]: Entering directory '/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/src'
/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/swift-linux-x86_64/bin/swiftc -frontend -c /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/Block.swift /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/Data.swift /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/Dispatch.swift /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/IO.swift /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/Private.swift /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/Queue.swift /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/Source.swift /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/Time.swift /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/Wrapper.swift -primary-file /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/Block.swift \
-Xcc -fmodule-map-file=/home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/dispatch/module.modulemap -I/home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch -Xcc -fblocks -O -module-name Dispatch -module-link-name dispatch \
-o /mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/src/swift/Block.o -emit-module-path /mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/src/swift/Block.o.~partial.swiftmodule \
-emit-module-doc-path /mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/src/swift/Block.o.~partial.swiftdoc -emit-dependencies-path /mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/src/swift/Block.o.d \
-emit-reference-dependencies-path /mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/src/swift/Block.o.swiftdeps \
-module-cache-path ..
#​0 0x00000000034b2205 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/swift-linux-x86_64/bin/swiftc+0x34b2205)
#​1 0x00000000034b28e6 SignalHandler(int) (/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/swift-linux-x86_64/bin/swiftc+0x34b28e6)
#​2 0x00007fc370aedc10 __restore_rt (/lib64/libpthread.so.0+0x10c10)
#​3 0x0000000000de37e4 swift::serialization::Serializer::writeAST(llvm::PointerUnion<swift::ModuleDecl*, swift::SourceFile*>) (/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/swift-linux-x86_64/bin/swiftc+0xde37e4)
#​4 0x0000000000de70ff swift::serialization::Serializer::writeToStream(llvm::raw_ostream&, llvm::PointerUnion<swift::ModuleDecl*, swift::SourceFile*>, swift::SILModule const*, swift::SerializationOptions const&) (/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/swift-linux-x86_64/bin/swiftc+0xde70ff)
#​5 0x0000000000e0daed void llvm::function_ref<void (llvm::raw_ostream&)>::callback_fn<swift::serialize(llvm::PointerUnion<swift::ModuleDecl*, swift::SourceFile*>, swift::SerializationOptions const&, swift::SILModule const*)::$_3>(long, llvm::raw_ostream&) (/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/swift-linux-x86_64/bin/swiftc+0xe0daed)
#​6 0x0000000000de9167 withOutputFile(swift::ASTContext&, llvm::StringRef, llvm::function_ref<void (llvm::raw_ostream&)>) (/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/swift-linux-x86_64/bin/swiftc+0xde9167)
#​7 0x0000000000de8ed7 swift::serialize(llvm::PointerUnion<swift::ModuleDecl*, swift::SourceFile*>, swift::SerializationOptions const&, swift::SILModule const*) (/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/swift-linux-x86_64/bin/swiftc+0xde8ed7)
#​8 0x000000000083fb8c performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*) (/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/swift-linux-x86_64/bin/swiftc+0x83fb8c)
#​9 0x000000000083b23b swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) (/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/swift-linux-x86_64/bin/swiftc+0x83b23b)
#​10 0x00000000007fe987 main (/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/swift-linux-x86_64/bin/swiftc+0x7fe987)
#​11 0x00007fc36f207731 __libc_start_main (/lib64/libc.so.6+0x20731)
#​12 0x00000000007fbc49 _start (/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/swift-linux-x86_64/bin/swiftc+0x7fbc49)
Stack dump:
0. Program arguments: /mnt/hgfs/rxwei/Development/Swift/swift-linux/build/swift-linux-x86_64/bin/swiftc -frontend -c /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/Block.swift /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/Data.swift /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/Dispatch.swift /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/IO.swift /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/Private.swift /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/Queue.swift /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/Source.swift /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/Time.swift /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/Wrapper.swift -primary-file /home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/src/swift/Block.swift -Xcc -fmodule-map-file=/home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch/dispatch/module.modulemap -I/home/rxwei/tmp/swiftbuild/swift-corelibs-libdispatch -Xcc -fblocks -O -module-name Dispatch -module-link-name dispatch -o /mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/src/swift/Block.o -emit-module-path /mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/src/swift/Block.o.~partial.swiftmodule -emit-module-doc-path /mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/src/swift/Block.o.~partial.swiftdoc -emit-dependencies-path /mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/src/swift/Block.o.d -emit-reference-dependencies-path /mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/src/swift/Block.o.swiftdeps -module-cache-path ..
Makefile:980: recipe for target '/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/src/swift/Block.o' failed
make[2]: *** [/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/src/swift/Block.o] Segmentation fault (core dumped)
make[2]: Leaving directory '/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/src'
Makefile:542: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/libdispatch-linux-x86_64/src'
Makefile:457: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
utils/build-script: fatal error: command terminated with a non-zero exit status 2, aborting
utils/build-script: fatal error: command terminated with a non-zero exit status 1, aborting
Preset:
[preset: debug_linux_all]
build-subdir=debug-linux-all
libdispatch
lldb
debug
#test
#validation-test
llbuild
foundation
xctest
swiftpm
dash-dash
verbose-build=0
install-swift
install-llbuild
install-foundation
install-libdispatch
install-lldb
install-xctest
install-swiftpm
reconfigure
install-prefix=/usr
build-swift-static-stdlib=1
skip-test-lldb=1
Previous ID | SR-2941 |
Radar | None |
Original Reporter | erg (JIRA User) |
Type | Bug |
Status | Resolved |
Resolution | Done |
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, Linux |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
md5: 10e6c90a348bb7f243bf43226a8393c3
Issue Description:
The test needs to be more robust because it's causing CI failures. Also, the fix should go into the swift-3.0-branch once it's merged into master.
https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/8200/console
TOTAL: 3
PASS: 3
SKIP: 0
XFAIL: 0
FAIL: 0
XPASS: 0
test -f 'test/main.c' || echo '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/'
test/main.ctest -f 'test/kevent.c' || echo '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/'
test/kevent.ctest -f 'test/test.c' || echo '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/'
test/test.ctest -f 'test/proc.c' || echo '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/'
test/proc.ctest -f 'test/read.c' || echo '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/'
test/read.ctest -f 'test/signal.c' || echo '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/'
test/signal.ctest -f 'test/timer.c' || echo '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/'
test/timer.ctest -f 'test/vnode.c' || echo '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/'
test/vnode.ctest -f 'test/user.c' || echo '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/'
test/user.cTOTAL: 1
PASS: 0
SKIP: 0
XFAIL: 0
FAIL: 1
XPASS: 0
ERROR: 0
.. contents:: :depth: 2
bind-1: Address already in use
Running 1 iterations
1: test_peer_close_detection()
2: test_kqueue()
3: test_kevent()
4: test_ev_receipt()
unable to bind to port 23456
*** TEST FAILED ***
FAIL kqtest (exit status: 1)
Previous ID | SR-2922 |
Radar | rdar://28725613 |
Original Reporter | erg (JIRA User) |
Type | Bug |
Status | Resolved |
Resolution | Done |
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, Linux |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
md5: d026254f314b5f173b0566d37814f460
Issue Description:
The Swift public CI bots are seeing a problem with incremental builds in libdispatch; Block.o.~partial.swiftmodule
is complaining about Dispatch
being stale.
We are calling reconfigure but it's not enough, apparently:
libdispatch: using gold linker
Reconfiguring libdispatch
+ mkdir -p /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64
+ pushd /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/swift-corelibs-libdispatch
~/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/swift-corelibs-libdispatch ~/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test
+ autoreconf -fvi
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
:0: error: module file was created by an older version of the compiler; rebuild 'Dispatch' and try again: /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Block.o.~partial.swiftmodule
Compile command:
./swift/utils/build-script --assertions --release --test --validation-test --lit-args=-v --build-subdir=buildbot_incremental --llbuild --swiftpm --xctest --foundation --libdispatch --test=0 --validation-test=0 --long-test=1 --test-optimized=0 – --reconfigure
Sample failure log, will eventually rotate away:
Failure log:
Making all in src
make[1]: Entering directory /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src' make all-am make[2]: Entering directory
/home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src'
/home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/swift-linux-x86_64/bin/swiftc -frontend -emit-module /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Block.o.~partial.swiftmodule /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Data.o.~partial.swiftmodule /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Dispatch.o.~partial.swiftmodule /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/IO.o.~partial.swiftmodule /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Private.o.~partial.swiftmodule /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Queue.o.~partial.swiftmodule /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Source.o.~partial.swiftmodule /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Time.o.~partial.swiftmodule /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Wrapper.o.~partial.swiftmodule
-Xcc -fmodule-map-file=/home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/swift-corelibs-libdispatch/dispatch/module.modulemap -I/home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/swift-corelibs-libdispatch -Xcc -fblocks -O -module-cache-path .. -module-link-name dispatch
-o /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Dispatch.swiftmodule -emit-module-doc-path /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Dispatch.swiftdoc
:0: error: module file was created by an older version of the compiler; rebuild 'Dispatch' and try again: /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Block.o.~partial.swiftmodule
make[2]: *** [/home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Dispatch.swiftmodule] Error 1
make[2]: Leaving directory /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src' make[1]: \*\*\* [all] Error 2 make[1]: Leaving directory
/home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src'
make: *** [all-recursive] Error 1
/home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/swift/utils/build-script: fatal error: command terminated with a non-zero exit status 2, aborting
/home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/swift/utils/build-script: fatal error: command terminated with a non-zero exit status 1, aborting
Build step 'Execute shell' marked build as failure
[xUnit] [INFO] - Starting to record.
[xUnit] [INFO] - Processing JUnit
[xUnit] [INFO] - [JUnit] - 1 test report file(s) were found with the pattern 'buildbot_incremental/swift-linux-x86_64/swift-test-results/x86_64-unknown-linux-gnu/lit-tests.xml' relative to '/home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test' for the testing framework 'JUnit'.
[xUnit] [INFO] - Converting '/home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/swift-linux-x86_64/swift-test-results/x86_64-unknown-linux-gnu/lit-tests.xml' .
[xUnit] [INFO] - Check 'Failed Tests' threshold.
[xUnit] [INFO] - Check 'Skipped Tests' threshold.
[xUnit] [INFO] - Setting the build status to FAILURE
[xUnit] [INFO] - Stopping recording.
[BFA] Scanning build for known causes...
[BFA] Found failure cause(s):
[BFA] Compile Error from category Compile
[BFA] Done. 0s
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Last: 414 FAILURE
Current: 415 FAILURE
Current Issue: :0: error: module file was created by an older version of the compiler; rebuild 'Dispatch' and try again: /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Block.o.~partial.swiftmodule
Last Issue: :0: error: module file was created by an older version of the compiler; rebuild 'Dispatch' and try again: /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Block.o.~partial.swiftmodule
Email sending was cancelled by user script.
Finished: FAILURE
Previous ID | SR-2356 |
Radar | None |
Original Reporter | dgrove-oss (JIRA User) |
Type | Bug |
Status | Closed |
Resolution | Done |
Votes | 0 |
Component/s | libdispatch |
Labels | Bug |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
md5: 210ac3ad8105e15721b8ed8ee91b5538
Issue Description:
The Linux Swift dispatch overlay contains about half a dozen temporary APIs in Queue.swift and Block.swift to allow SCL-Foundation to catch up to the final Dispatch APIs. We should remove these from Dispatch before the final Swift 3 GA for Linux.
In particular, the backwards scaffolding for Queue attributes annoyingly makes .concurrent ambiguous.
swiftc -Xcc -fblocks BarrierTest1.swift
BarrierTest1.swift:4:61: error: ambiguous use of 'concurrent'
let queue = DispatchQueue(label: "test queue", attributes: .concurrent)
^
Dispatch.DispatchQueueAttributes:6:23: note: found this candidate
static public var concurrent: Dispatch.DispatchQueueAttributes
^
Dispatch.DispatchQueue:5:27: note: found this candidate
static public var concurrent: Dispatch.DispatchQueue.Attributes
^
Previous ID | SR-3113 |
Radar | rdar://problem/28564226 |
Original Reporter | @weissi |
Type | Bug |
Status | Resolved |
Resolution | Done |
Attachment: Download
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, RunTimeCrash |
Assignee | ktopley-apple (JIRA) |
Priority | Medium |
md5: b7e0af488af89207765090918f413f1b
Issue Description:
A DispatchIO channel opened with DispatchIO(type:path:oflag:mode:queue:cleanupHandler:)
with a file that doesn't exist SEGV
's (NULL
pointer dereference) the program when it calls DispatchIO.read
.
Interestingly, it only seems to happen if the path that isn't found is a relative path... I might be wrong about this one.
Compile the attached program (swiftc -o quick-crash quick-crash.swift
)
Run program: ./quick-crash
Run program again, supplying a path: ./quick-crash some-relative-path
Run program once again: ./quick-crash /some-absolute-path
Step (1) should work fine
Step (2) SEGV
's the program with a NULL pointer dereference in dispatch_io_read
Step (3) SEGV
's the program too (pretty similar to step (2)
Step (4) does not crash the program, the IO handler correctly gets an errno 2 (ENOENT
)
?
on macOS the crash happens in the constructor already
on Linux (crash when reading only), in LLDB, the crash looks like
Process 1020 launched: './qc' (x86_64)
trying path './I'm guessing/this/file/doesn't exist'
chan = Dispatch.DispatchIO
Process 1020 stopped
* thread #​1: tid = 1020, 0x00007ffff7ef8a20 libdispatch.so`dispatch_io_read, name = 'qc', stop reason = signal SIGSEGV: invalid address (fault address: 0x8)
frame #​0: 0x00007ffff7ef8a20 libdispatch.so`dispatch_io_read
libdispatch.so`dispatch_io_read:
-> 0x7ffff7ef8a20 <+0>: movl 0x8(%rdi), %eax
0x7ffff7ef8a23 <+3>: cmpl $0x7fffffff, %eax ; imm = 0x7FFFFFFF
0x7ffff7ef8a28 <+8>: je 0x7ffff7ef8a33 ; <+19>
0x7ffff7ef8a2a <+10>: leaq 0x8(%rdi), %rax
(lldb) bt
* thread #​1: tid = 1020, 0x00007ffff7ef8a20 libdispatch.so`dispatch_io_read, name = 'qc', stop reason = signal SIGSEGV: invalid address (fault address: 0x8)
* frame #​0: 0x00007ffff7ef8a20 libdispatch.so`dispatch_io_read
frame #​1: 0x00007ffff7f199f8 libdispatch.so`_TFC8Dispatch10DispatchIO4readfT6offsetSi6lengthSi5queueCS_13DispatchQueue9ioHandlerFTSbGSqVS_12DispatchData_Vs5Int32_T__T_ + 200
frame #​2: 0x00000000004025cd qc`main + 1949
frame #​3: 0x00007ffff6783830 libc.so.6`__libc_start_main(main=(qc`main), argc=1, argv=0x00007fffffffe498, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007fffffffe488) + 240 at libc-start.c:291
frame #​4: 0x0000000000401d59 qc`_start + 41
Previous ID | SR-2931 |
Radar | None |
Original Reporter | erg (JIRA User) |
Type | Bug |
Status | Resolved |
Resolution | Won't Do |
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, Linux |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
md5: b1a66dd63a8bf2dc1f3bfe6379f2bcb9
is duplicated by:
Issue Description:
`dispatch_suspend_timer` test fails randomly in public CI tests.
Previous patch for a related failure:
https://bugs.swift.org/browse/SR-2856
https://ci.swift.org/view/swift-3.0-branch/job/oss-swift-3.0-incremental-RA-linux-ubuntu-15_10/247/console
https://ci.swift.org/view/swift-3.0-branch/job/oss-swift-3.0-incremental-RA-linux-ubuntu-15_10/249/console
TOTAL: 23
PASS: 22
SKIP: 0
XFAIL: 0
FAIL: 1
XPASS: 0
Makefile:1352: recipe for target 'test-suite.log' failed
make[3]: *** [test-suite.log] Error 1
make[3]: Leaving directory '/home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/libdispatch-linux-x86_64/tests'
Makefile:1458: recipe for target 'check-TESTS' failed
make[2]: *** [check-TESTS] Error 2
make[2]: Leaving directory '/home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/libdispatch-linux-x86_64/tests'
Makefile:1741: recipe for target 'check-am' failed
make[1]: *** [check-am] Error 2
make[1]: Leaving directory '/home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/libdispatch-linux-x86_64/tests'
Makefile:456: recipe for target 'check-recursive' failed
make: *** [check-recursive] Error 1
/home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-15_10/swift/utils/build-script: fatal error: command terminated with a non-zero exit status 2, aborting
/home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-15_10/swift/utils/build-script: fatal error: command terminated with a non-zero exit status 1, aborting
Build step 'Execute shell' marked build as failure
[xUnit] [INFO] - Starting to record.
[xUnit] [INFO] - Processing JUnit
[xUnit] [INFO] - [JUnit] - 1 test report file(s) were found with the pattern 'buildbot_incremental/swift-linux-x86_64/swift-test-results/x86_64-unknown-linux-gnu/lit-tests.xml' relative to '/home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-15_10' for the testing framework 'JUnit'.
[xUnit] [INFO] - Converting '/home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/swift-linux-x86_64/swift-test-results/x86_64-unknown-linux-gnu/lit-tests.xml' .
[xUnit] [INFO] - Check 'Failed Tests' threshold.
[xUnit] [INFO] - Check 'Skipped Tests' threshold.
[xUnit] [INFO] - Setting the build status to FAILURE
[xUnit] [INFO] - Stopping recording.
[BFA] Scanning build for known causes...
[BFA] No failure causes found
[BFA] Done. 0s
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
An attempt to send an e-mail to empty list of recipients, ignored.
Finished: FAILURE
```
Previous ID | SR-1106 |
Radar | None |
Original Reporter | s00p3rj03l (JIRA User) |
Type | Bug |
Status | Resolved |
Resolution | Done |
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, Linux |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
md5: 37f10186f5fd7d2973c29a7a4793548f
Issue Description:
On Linux, when trying to use DISPATCH_SOURCE_TYPE_READ with dispatch_source_create I get a compile error "use of unresolved identifier 'DISPATCH_SOURCE_TYPE_READ'"
dispatch_source_create(DISPATCH_SOURCE_TYPE_READ, UInt(0), 0, nil)
-_docker run -it saltzmanjoelh/swiftubuntu /bin/bash -c "git clone https://github.com/saltzmanjoelh/gcd4/ && cd gcd4 && chmod +x apply_fixes.sh && ./apply_fixes.sh && swift build -Xcc fblocks"_
I updated the docker container to include pull:61 and no longer need the apply_fixes script:
Previous ID | SR-1769 |
Radar | rdar://problem/26879347 |
Original Reporter | @glessard |
Type | Bug |
Status | Resolved |
Resolution | Done |
Xcode 8 (beta, 8S128d) with Swift 3.0 preview 1
Votes | 0 |
Component/s | libdispatch |
Labels | Bug |
Assignee | mww (JIRA) |
Priority | Medium |
md5: 4e42e84469231d8d359f27b0d0008de7
Issue Description:
A frequently-used function alongside libdispatch, qos_class_self() did not get updated with the Dispatch module. An equivalent that returns a DispatchQoS instance would be most welcome.
extension DispatchQoS {
static func current() -> DispatchQoS // equivalent to qos_class_self()
static var main: DispatchQoS // equivalent to qos_class_main()
init(qos: qos_class_t) // perhaps with a relativePriority?
}
Previous ID | SR-737 |
Radar | None |
Original Reporter | @drewcrawford |
Type | Bug |
Status | Resolved |
Resolution | Won't Do |
Linux x64
swift-DEVELOPMENT-SNAPSHOT-2016-02-08-a
Votes | 0 |
Component/s | libdispatch |
Labels | Bug |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
md5: e7691fb73226e77e3cd6b0d9ebce19d7
Issue Description:
dispatch_queue_create
on Linux has return type of COpaquePointer
whereas a return type of dispatch_queue_t!
is expected.
To reproduce in my Docker image:
$ docker run -it --privileged=true drewcrawford/swift:swift-DEVELOPMENT-SNAPSHOT-2016-02-08-a
$ swift -Xcc -fblocks -L/usr/local/lib -I /usr/local/include/dispatch/haxx -lBlocksRuntime -L/usr/lib/x86_64-linux-gnu
Welcome to Swift version 3.0-dev (LLVM a7663bb722, Clang 4ca3c7fa28, Swift c130b422a9). Type :help for assistance.
1> import Dispatch
2> let q = dispatch_queue_create("foo", DISPATCH_QUEUE_SERIAL)
q: dispatch_queue_t = 0x0000000000603050 -> 0x00007ffff442a6a0 libdispatch.so`_dispatch_queue_vtable
3> dispatch_suspend(q)
Expected results: success
Actual results:
repl.swift:3:18: error: cannot convert value of type 'dispatch_queue_t' (aka 'COpaquePointer') to expected argument type 'dispatch_object_t'
dispatch_suspend(q)
Previous ID | SR-2856 |
Radar | rdar://problem/28598500 |
Original Reporter | erg (JIRA User) |
Type | Bug |
Status | Resolved |
Resolution | Done |
Votes | 0 |
Component/s | libdispatch |
Labels | Bug |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
md5: 5383403a9de42fe43ff508c2c62f0e0b
Issue Description:
This fails sometimes in the Ubuntu CI.
https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/8010/console
TOTAL: 22
PASS: 21
SKIP: 0
XFAIL: 0
FAIL: 1
XPASS: 0
ERROR: 0
.. contents:: :depth: 2
[BEGIN] dispatch_source_create
Actual: 0x947180
Expected: 0x947180
[PASS] dispatch_source_create
[BEGIN] dispatch_source_timer_create
Actual: 0x947180
Expected: 0x947180
[PASS] dispatch_source_timer_create
1
2
3
4
5
6
7
[BEGIN] total duration
Actual: 3
Expected: <3
[FAIL] total duration (dispatch_timer_set_time.c:56)
dispatch_timer_set_time.c:56
[BEGIN] Process exited
Actual: 0
Expected: 0
[PASS] Process exited
[PERF] wall time: 0.000113
[PERF] user time: 0.304000
[PERF] system time: 1.084000
[PERF] max resident set size: 19684
[PERF] page faults: 0
[PERF] swaps: 0
[PERF] voluntary context switches: 319840
[PERF] involuntary context switches: 11
FAIL dispatch_timer_set_time (exit status: 1)
TOTAL: 22
PASS: 21
SKIP: 0
XFAIL: 0
FAIL: 1
XPASS: 0
ERROR: 0
```
Previous ID | SR-3110 |
Radar | None |
Original Reporter | @shahmishal |
Type | Bug |
Status | Resolved |
Resolution | Duplicate |
Attachment: Download
Votes | 0 |
Component/s | libdispatch |
Labels | Bug |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
Watchers: @shahmishal
md5: be96691d4fc61dba8b42feb0fb564b98
duplicates:
dispatch_suspend_timer
test needs robustificationIssue Description:
[BEGIN] dispatch_source_timer_create
Actual: 0xe85180
Expected: 0xe85180
[PASS] dispatch_source_timer_create
[BEGIN] dispatch_source_timer_create
Actual: 0xe878a0
Expected: 0xe878a0
[PASS] dispatch_source_timer_create
tweedledee 1 (1)
tweedledee 2 (2)
tweedledee 3 (3)
suspending timer for 3 seconds
resuming timer
[BEGIN] tweedledee tick count
Actual: 3
Expected: 3
[PASS] tweedledee tick count
[BEGIN] tweedledee virtual tick count
Actual: 3
Expected: 3
[PASS] tweedledee virtual tick count
tweedledee 4 (6)
tweedledee 5 (6)
tweedledee 6 (7)
tweedledee 7 (8)
tweedledee 8 (9)
[BEGIN] tweedledee tick count
Actual: 8
Expected: 7
[FAIL] tweedledee tick count (dispatch_suspend_timer.c:96)
dispatch_suspend_timer.c:96
[BEGIN] tweedledee virtual tick count
Actual: 9
Expected: 9
[PASS] tweedledee virtual tick count
[BEGIN] finalizer ran
Actual: 0xe878a0
Expected: 0xe878a0
[PASS] finalizer ran
[BEGIN] Process exited
Actual: 0
Expected: 0
[PASS] Process exited
[PERF] wall time: 0.000089
[PERF] user time: 1.468000
[PERF] system time: 6.444000
[PERF] max resident set size: 17576
[PERF] page faults: 0
[PERF] swaps: 0
[PERF] voluntary context switches: 1482154
[PERF] involuntary context switches: 214
FAIL dispatch_suspend_timer (exit status: 1)
Previous ID | SR-739 |
Radar | None |
Original Reporter | @drewcrawford |
Type | Bug |
Status | Resolved |
Resolution | Won't Do |
Linux x64
swift-DEVELOPMENT-SNAPSHOT-2016-02-08-a
Votes | 0 |
Component/s | libdispatch |
Labels | Bug |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
md5: 7a05c4859f5cb697454da6ee8894f864
Issue Description:
The following program compiles on Darwin:
let t: dispatch_queue_t! = nil
let a: dispatch_object_t! = t
and not on Linux:
error: cannot convert value of type 'dispatch_queue_t!' to specified type 'dispatch_object_t!'
let a: dispatch_object_t! = t
Previous ID | SR-761 |
Radar | None |
Original Reporter | @drewcrawford |
Type | Bug |
Status | Resolved |
Resolution | Done |
Attachment: Download
Linux x64
swift-DEVELOPMENT-SNAPSHOT-2016-02-08-a
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, Linux |
Assignee | frankeh (JIRA) |
Priority | Medium |
md5: b2ed8e5cf6e4eaac3f1ede31d47b998f
Issue Description:
The attached program enqueues 10 blocks of work on the default queue. On Darwin, all blocks run in parallel, and the program completes in 5 seconds:
0.0 block 0 enter
0.0 block 7 enter
0.0 block 1 enter
0.0 block 3 enter
0.0 block 2 enter
0.0 block 4 enter
0.0 block 5 enter
0.0 block 6 enter
0.0 block 8 enter
0.0 block 9 enter
5.0 block 1 leave
5.0 block 6 leave
5.0 block 9 leave
5.0 block 5 leave
5.0 block 3 leave
5.0 block 0 leave
5.0 block 8 leave
5.0 block 4 leave
5.0 block 2 leave
5.0 block 7 leave
5.0 finished
On Linux however, the blocks enter the queue staggered 1 at a time, 1 second apart. This doubles the runtime of the program:
0.0 block 1 enter
0.0 block 0 enter
1.0 block 2 enter
2.0 block 3 enter
3.0 block 4 enter
4.0 block 5 enter
5.0 block 1 leave
5.0 block 0 leave
5.0 block 6 enter
5.0 block 7 enter
5.0 block 8 enter
6.0 block 2 leave
6.0 block 9 enter
7.0 block 3 leave
8.0 block 4 leave
9.0 block 5 leave
10.0 block 6 leave
10.0 block 7 leave
10.0 block 8 leave
11.0 block 9 leave
11.0 finished
In addition to that (rather large) performance regression, the fact that dispatch_async
and/or the default queue has in practice a constant-time overhead of 1 second on Linux breaks a lot of my Darwin code, which expects a Darwin-like overhead for this call.
Previous ID | SR-3002 |
Radar | None |
Original Reporter | @weissi |
Type | Bug |
Status | Resolved |
Resolution | Done |
Attachment: Download
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, Leak, Linux |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
md5: 323c438d5e940e5a5a3e6dc87ed9b40f
is blocked by:
Issue Description:
When using DispatchData.enumerateBytes
on Linux, it leaks the block which leaks to pretty bad memory leaks...
The example program is
import Dispatch
while true {
let d = DispatchData.empty
d.enumerateBytes { _ in }
}
just leave that running on Linux and it'll leak a lot of memory, on Darwin (with the Apple Swift from Xcode it's fine).
If you're lazy, just run the attached test.sh
with bash test.sh
under Linux or Darwin and it'll create, compile, run (for 10s), and print statistics for the test program.
See below for some numbers:
this is created with Swift from https://swift.org/builds/development/ubuntu1604/swift-DEVELOPMENT-SNAPSHOT-2016-10-18-a/swift-DEVELOPMENT-SNAPSHOT-2016-10-18-a-ubuntu16.04.tar.gz but the same problem happens with all Swift versions I have tested.
The kernel is Linux thing 4.4.0-36-generic #​55-Ubuntu SMP Thu Aug 11 18:01:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ bash test.sh
swift source in '/tmp/swift-dispatch-mem-leak_MgQ7Lq/test.swift'
swift binary in '/tmp/swift-dispatch-mem-leak_MgQ7Lq/test'
=====
import Dispatch
while true {
let d = DispatchData.empty
d.enumerateBytes { _ in }
}
=====
Swift version 3.0-dev (LLVM 2f56c9717e, Clang b0df436efa, Swift 25d58f9228)
Target: x86_64-unknown-linux-gnu
=====
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
jweiss 18062 100 62.5 10309652 10253740 pts/3 R+ 18:51 0:10 ./test
test.sh: line 28: 18062 Killed ./test
OK
that's 10253740 kb resident in 10s, that's a 10GB leak.
$ bash test.sh
swift source in '/tmp/swift-dispatch-mem-leak_iorCwW/test.swift'
swift binary in '/tmp/swift-dispatch-mem-leak_iorCwW/test'
=====
import Dispatch
while true {
let d = DispatchData.empty
d.enumerateBytes { _ in }
}
=====
Apple Swift version 3.0 (swiftlang-800.0.46.2 clang-800.0.38)
Target: x86_64-apple-macosx10.9
=====
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
johannes 34757 100.0 0.0 2445456 6832 s002 R+ 6:50pm 0:09.99 ./test
test.sh: line 28: 34757 Killed: 9 ./test
OK
that's 6MB resident in 10s, much better.
$ valgrind --leak-check=full /tmp/swift-dispatch-mem-leak_yqOZxx/test
==18530== Memcheck, a memory error detector
==18530== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==18530== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==18530== Command: /tmp/swift-dispatch-mem-leak_yqOZxx/test
==18530==
^C==18530==
==18530== Process terminating with default action of signal 2 (SIGINT)
==18530== at 0x400C73: main (in /tmp/swift-dispatch-mem-leak_yqOZxx/test)
==18530==
==18530== HEAP SUMMARY:
==18530== in use at exit: 59,364,626 bytes in 1,482,300 blocks
==18530== total heap usage: 1,482,310 allocs, 10 frees, 59,444,330 bytes allocated
==18530==
==18530== 57 (16 direct, 41 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 9
==18530== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18530== by 0x515EBFA: _swift_stdlib_getUnsafeArgvArgc (in /home/jweiss/extsrc/swift-DEVELOPMENT-SNAPSHOT-2016-10-18-a-ubuntu16.04/usr/lib/swift/linux/libswiftCore.so)
==18530== by 0x507139F: globalinit_33_FD9A49A256BEB6AF7C48013347ADC3BA_func3 (in /home/jweiss/extsrc/swift-DEVELOPMENT-SNAPSHOT-2016-10-18-a-ubuntu16.04/usr/lib/swift/linux/libswiftCore.so)
==18530== by 0x5E98AD8: __pthread_once_slow (pthread_once.c:116)
==18530== by 0x515C4A9: swift_once (in /home/jweiss/extsrc/swift-DEVELOPMENT-SNAPSHOT-2016-10-18-a-ubuntu16.04/usr/lib/swift/linux/libswiftCore.so)
==18530== by 0x400C5D: main (in /tmp/swift-dispatch-mem-leak_yqOZxx/test)
==18530==
==18530== 192 bytes in 6 blocks are possibly lost in loss record 5 of 9
==18530== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18530== by 0x514F9E5: swift_slowAlloc (in /home/jweiss/extsrc/swift-DEVELOPMENT-SNAPSHOT-2016-10-18-a-ubuntu16.04/usr/lib/swift/linux/libswiftCore.so)
==18530== by 0x514FA1E: _swift_allocObject_ (in /home/jweiss/extsrc/swift-DEVELOPMENT-SNAPSHOT-2016-10-18-a-ubuntu16.04/usr/lib/swift/linux/libswiftCore.so)
==18530== by 0x4102463: _TFV8Dispatch12DispatchData14enumerateBytesfT5blockFTGSRVs5UInt8_SiRSb_T__T_ (in /home/jweiss/extsrc/swift-DEVELOPMENT-SNAPSHOT-2016-10-18-a-ubuntu16.04/usr/lib/swift/linux/libdispatch.so)
==18530== by 0x400C9B: main (in /tmp/swift-dispatch-mem-leak_yqOZxx/test)
==18530==
==18530== 240 bytes in 5 blocks are possibly lost in loss record 6 of 9
==18530== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18530== by 0x41006D8: _Block_copy_internal (in /home/jweiss/extsrc/swift-DEVELOPMENT-SNAPSHOT-2016-10-18-a-ubuntu16.04/usr/lib/swift/linux/libdispatch.so)
==18530== by 0x41024C0: _TFV8Dispatch12DispatchData14enumerateBytesfT5blockFTGSRVs5UInt8_SiRSb_T__T_ (in /home/jweiss/extsrc/swift-DEVELOPMENT-SNAPSHOT-2016-10-18-a-ubuntu16.04/usr/lib/swift/linux/libdispatch.so)
==18530== by 0x400C9B: main (in /tmp/swift-dispatch-mem-leak_yqOZxx/test)
==18530==
==18530== 59,291,376 (35,574,864 direct, 23,716,512 indirect) bytes in 741,143 blocks are definitely lost in loss record 9 of 9
==18530== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18530== by 0x41006D8: _Block_copy_internal (in /home/jweiss/extsrc/swift-DEVELOPMENT-SNAPSHOT-2016-10-18-a-ubuntu16.04/usr/lib/swift/linux/libdispatch.so)
==18530== by 0x41024C0: _TFV8Dispatch12DispatchData14enumerateBytesfT5blockFTGSRVs5UInt8_SiRSb_T__T_ (in /home/jweiss/extsrc/swift-DEVELOPMENT-SNAPSHOT-2016-10-18-a-ubuntu16.04/usr/lib/swift/linux/libdispatch.so)
==18530== by 0x400C9B: main (in /tmp/swift-dispatch-mem-leak_yqOZxx/test)
==18530==
==18530== LEAK SUMMARY:
==18530== definitely lost: 35,574,880 bytes in 741,144 blocks
==18530== indirectly lost: 23,716,553 bytes in 741,142 blocks
==18530== possibly lost: 432 bytes in 11 blocks
==18530== still reachable: 72,761 bytes in 3 blocks
==18530== suppressed: 0 bytes in 0 blocks
==18530== Reachable blocks (those to which a pointer was found) are not shown.
==18530== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==18530==
==18530== For counts of detected and suppressed errors, rerun with: -v
==18530== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0)
Previous ID | SR-2248 |
Radar | None |
Original Reporter | @lilyball |
Type | Bug |
Status | Closed |
Resolution | Done |
swift-DEVELOPMENT-SNAPSHOT-2016-07-29-a-139-g6b1210e
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, SDKOverlay |
Assignee | @lilyball |
Priority | Medium |
md5: a8c76b3235340891e802dd887881b85b
Issue Description:
We shouldn't be going through the overhead of creating a DispatchWorkItem
(and calling dispatch_block_create_with_qos()
just to submit a barrier block to a queue. In the case of queue.async(flags: .barrier, execute: ...)
we should just call through to dispatch_barrier_async()
.
Not only that, but according to the code, on OS X 10.9 or iOS 7, queue.async(flags: .barrier)
will completely ignore the flags, causing the code to submit a non-barrier block.
Previous ID | SR-2012 |
Radar | None |
Original Reporter | brett (JIRA User) |
Type | Bug |
Status | Resolved |
Resolution | Done |
Swift 3 / Xcode 8 beta 2 / macOS 10.11.5
Votes | 0 |
Component/s | libdispatch |
Labels | Bug |
Assignee | mww (JIRA) |
Priority | Medium |
md5: 25695eaf8f69ea7142f55e8540fb7215
Issue Description:
A DispatchSource.timer that is configured with scheduleRepeating does not seem to repeat in Swift 3. The eventHandler should be called repeatedly, but is only called once.
Example code:
class ViewController: UIViewController {
var timer: DispatchSourceTimer!
override func viewDidAppear(_ animated: Bool) {
super.viewDidAppear(animated)
timer = DispatchSource.timer(queue: DispatchQueue.global(attributes: DispatchQueue.GlobalAttributes(rawValue: DispatchQueueAttributes.qosUserInteractive.rawValue)) )
timer.scheduleRepeating(deadline: DispatchTime.now(), interval: (1.0 / 120.0) * Double(NSEC_PER_SEC), leeway: DispatchTimeInterval.milliseconds(1))
timer.setEventHandler(handler: {
print("timer update")
})
timer.resume()
}
}
Previous ID | SR-2202 |
Radar | None |
Original Reporter | @glessard |
Type | Bug |
Swift Development Snapshot 2016-07-25a
Votes | 0 |
Component/s | libdispatch |
Labels | Bug |
Assignee | None |
Priority | Medium |
md5: 395e15545be80824dafa50c11102d386
Issue Description:
A deadline is the latest possible moment in time at which work can have been completed. (dictionaries concur)
This timestamp is the earliest moment in time at which work can be initiated.
It's completely backwards! I'm puzzled how this could have happened.
This being said, with the new function name, it's not clear that a parameter label is needed at all. The type of the parameter is a timestamp (in both the DispatchTime or the DispatchWallTime versions), so that "dispatch after a timestamp" is completely understandable.
Previous ID | SR-2207 |
Radar | None |
Original Reporter | @glessard |
Type | Improvement |
Xcode 8 beta 3
Votes | 0 |
Component/s | libdispatch |
Labels | Improvement |
Assignee | mww (JIRA) |
Priority | Medium |
md5: 0a7258f71072fa80ec0950f50cd68e37
Issue Description:
The rest of the new Dispatch overlay makes good use of defaults, but this parameter was passed over somehow. It would make sense to have a default of 0, that surely is the most commonly-passed parameter.
public struct DispatchQoS : Equatable {
public init(qosClass: QoSClass, relativePriority: Int = 0) {
self.qosClass = qosClass
self.relativePriority = relativePriority
}
}
Previous ID | SR-744 |
Radar | None |
Original Reporter | @drewcrawford |
Type | Bug |
Status | Resolved |
Resolution | Done |
Linux x64
swift-DEVELOPMENT-SNAPSHOT-2016-02-08-a
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, Linux |
Assignee | None |
Priority | Medium |
md5: e80af79dce0d5276a9822844be18630c
Issue Description:
Darwin documentation for dispatch_get_global_queue
says
* It is recommended to use quality of service class values to identify the
* well-known global concurrent queues:
* - QOS_CLASS_USER_INTERACTIVE
* - QOS_CLASS_USER_INITIATED
* - QOS_CLASS_DEFAULT
* - QOS_CLASS_UTILITY
* - QOS_CLASS_BACKGROUND
This "preferred" code is not platform-independent, because
These symbols are not available on Linux
QOS is not implemented on Linux
I understand that this is not something going to happen in the immediate future, but I'm opening a bug to track this. I'm introducing a bunch of terrible Linux-specific QOS hacks as I port my Darwin code to Linux, and I need to link to a bug in my code comments that explains why the #if os(Linux)
branch is so terrible.
Previous ID | SR-2655 |
Radar | None |
Original Reporter | @weissi |
Type | Bug |
Status | Resolved |
Resolution | Done |
Attachment: Download
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, Linux |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
md5: 071933e7988663468728927c7cfe2cd7
Issue Description:
Certain signals are masked/blocked on libdispatch/libpwq worker threads.
On Darwin, the list of masked signals is the inverse of workq_threadmask
:
#define sigcantmask (sigmask(SIGKILL) | sigmask(SIGSTOP))
#define threadmask (sigmask(SIGILL)|sigmask(SIGTRAP)|\
sigmask(SIGIOT)|sigmask(SIGEMT)|\
sigmask(SIGFPE)|sigmask(SIGBUS)|\
sigmask(SIGSEGV)|sigmask(SIGSYS)|\
sigmask(SIGPIPE)|sigmask(SIGKILL))
#define workq_threadmask (threadmask | sigcantmask)
There is actually a function _dispatch_pthread_sigmask
which given a full sigmask calculates a similiar sigmask which is then used in certain situations.
However, the overcommit_worker_main
function in libpwq
chooses to mask all the signals which doesn't seem correct. To fix this issue, it seems enough to only block the signals _dispatch_pthread_sigmask
elects instead of all.
There is also another place in libpwq
where all signals are blocked on a thread. I'm unsure whether that is correct.
Running the attached test.c
shows the problem:
Darwin jwmbp.local 16.0.0 Darwin Kernel Version 16.0.0: Mon Aug 29 17:56:21 PDT 2016; root:xnu-3789.1.32~3/DEVELOPMENT_X86_64 x86_64
main
====
dispatch
=======
dispatch: SIGHUP is BLOCKED
dispatch: SIGINT is BLOCKED
dispatch: SIGQUIT is BLOCKED
dispatch: SIGALRM is BLOCKED
dispatch: SIGTERM is BLOCKED
dispatch: SIGURG is BLOCKED
dispatch: SIGTSTP is BLOCKED
dispatch: SIGCONT is BLOCKED
dispatch: SIGCHLD is BLOCKED
dispatch: SIGTTIN is BLOCKED
dispatch: SIGTTOU is BLOCKED
dispatch: SIGIO is BLOCKED
dispatch: SIGXCPU is BLOCKED
dispatch: SIGXFSZ is BLOCKED
dispatch: SIGVTALRM is BLOCKED
dispatch: SIGWINCH is BLOCKED
dispatch: SIGUSR1 is BLOCKED
dispatch: SIGUSR2 is BLOCKED
pthread
=======
libdispatch
@ https://github.com/apple/swift-corelibs-libdispatch/tree/7fe8323838b0491691e515a7f826ffe508668856 ish
Linux build 4.4.0-36-generic #​55-Ubuntu SMP Thu Aug 11 18:01:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
main
====
dispatch
=======
dispatch: SIGHUP is BLOCKED
dispatch: SIGINT is BLOCKED
dispatch: SIGQUIT is BLOCKED
dispatch: SIGILL is BLOCKED
dispatch: SIGTRAP is BLOCKED
dispatch: SIGABRT is BLOCKED
dispatch: SIGIOT is BLOCKED
dispatch: SIGFPE is BLOCKED
dispatch: SIGBUS is BLOCKED
dispatch: SIGSEGV is BLOCKED
dispatch: SIGSYS is BLOCKED
dispatch: SIGPIPE is BLOCKED
dispatch: SIGALRM is BLOCKED
dispatch: SIGTERM is BLOCKED
dispatch: SIGURG is BLOCKED
dispatch: SIGTSTP is BLOCKED
dispatch: SIGCONT is BLOCKED
dispatch: SIGCHLD is BLOCKED
dispatch: SIGTTIN is BLOCKED
dispatch: SIGTTOU is BLOCKED
dispatch: SIGIO is BLOCKED
dispatch: SIGXCPU is BLOCKED
dispatch: SIGXFSZ is BLOCKED
dispatch: SIGVTALRM is BLOCKED
dispatch: SIGPROF is BLOCKED
dispatch: SIGWINCH is BLOCKED
dispatch: SIGUSR1 is BLOCKED
dispatch: SIGUSR2 is BLOCKED
pthread
=======
Previous ID | SR-2050 |
Radar | rdar://problem/27293973 |
Original Reporter | Ostoich (JIRA User) |
Type | Bug |
Status | Resolved |
Resolution | Done |
Attachment: Download
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, RunTimeCrash |
Assignee | mww (JIRA) |
Priority | Medium |
md5: 8935edf947be4b32835f5f3227607202
Issue Description:
Swift 3 code on Xcode 8 beta crashes with "EXC_BAD_ACCESS" when using DispatchData object that has been created by appending UnsafeBufferPointers to it.
See the attached playground example.
Previous ID | SR-2656 |
Radar | None |
Original Reporter | helge (JIRA User) |
Type | Bug |
Status | Resolved |
Resolution | Done |
Ubuntu, either 14 or 15, doesn't matter with the final Swift 3.0 drop.
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, Linux |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
md5: 11d534504ba248a72e773044ac6867ff
Issue Description:
Swift 3.0: read()ing from a DispatchIO channel on Linux results in a SIGILL:
thread #6: tid = 1146, 0x00007ffff7efb503 libdispatch.so`_os_object_release + 35, name = 'sockd', stop reason = signal SIGILL: illegal instruction operand
frame #0: 0x00007ffff7efb503 libdispatch.so`_os_object_release + 35
frame #1: 0x00007ffff7ef46b7 libdispatch.so`_dispatch_call_block_and_release + 7
I put up an tiny isolated example over here: https://github.com/helje5/linux-gcd-issue
Works fine on macOS.
Previous ID | SR-1817 |
Radar | rdar://26873952 |
Original Reporter | Hal (JIRA User) |
Type | Improvement |
Status | Resolved |
Resolution | Done |
Votes | 0 |
Component/s | libdispatch |
Labels | Improvement, SDKOverlay |
Assignee | mww (JIRA) |
Priority | Medium |
md5: 6d3e934a4ba92087c10d9c6aa4f0251b
Issue Description:
In a metronome app, I need an AVAudioTime to be able to schedule a beat in the future (with AVAudioPlayerNode.scheduleBuffer). I already need to show a flash on the screen. For that, I'm using GCD and the new DispatchTime class.
Actually, I can use the rawValue method to have an hostTime and the AVAudioTime(hostTime: ) method to convert the DispatchTime to an AVAudioTime.
After a discussion with GCD Apple engineer, the rawValue actually produce a hosttime, but it's not guaranteed to produce that in a future.
He asks me to create a radar to be able to have a way to convert a DispatchTime to an hostTime before the rawValue change its behavior.
Previous ID | SR-438 |
Radar | None |
Original Reporter | @drewcrawford |
Type | Bug |
Status | Closed |
Resolution | Done |
Linux x64
Votes | 0 |
Component/s | libdispatch |
Labels | Bug |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
md5: f73b104e22817c248c75626a4c20c6ba
Issue Description:
Running 'make distcheck' produces an error due to a missing linux_port.h.
I cannot find this file in the repository, so I'm not really sure what is intended to happen here.
/bin/bash ../libtool --tag=CC --mode=compile clang -DHAVE_CONFIG_H -I. -I../../tests -I../config -I.. -I../.. -Wall -Wno-deprecated-declarations -fblocks -I/usr/include/kqueue -isystem /usr/include/bsd -DLIBBSD_OVERLAY -g -O2 -c -o dispatch_test.lo ../../tests/dispatch_test.c
libtool: compile: clang -DHAVE_CONFIG_H -I. -I../../tests -I../config -I.. -I../.. -Wall -Wno-deprecated-declarations -fblocks -I/usr/include/kqueue -isystem /usr/include/bsd -DLIBBSD_OVERLAY -g -O2 -c ../../tests/dispatch_test.c -fPIC -DPIC -o .libs/dispatch_test.o
In file included from ../../tests/dispatch_test.c:21:
../../tests/dispatch_test.h:26:10: fatal error: 'linux_port.h' file not found
#include <linux_port.h>
^
1 error generated.
Previous ID | SR-1770 |
Radar | rdar://problem/26879343 |
Original Reporter | @glessard |
Type | Bug |
Status | Closed |
Resolution | Done |
Xcode 8 (beta, 8S128d) with Swift 3.0 preview 1
Votes | 0 |
Component/s | libdispatch |
Labels | Bug |
Assignee | mww (JIRA) |
Priority | Medium |
md5: b72edfc14216b508eb2396a9de513141
Issue Description:
DispatchQoS is used as a parameter on DispatchQueue.async and others, but can't be used as a parameter to initialize or obtain DispatchQueue instances. On the other hand, DispatchQueueAttributes contains some DispatchQoS information, but one cannot be initialized using a DispatchQoS instance.
DispatchQueue.global() and DispatchQueue.init() should have overloads with DispatchQoS parameters.
DispatchQueueAttributes.init() should have an overload that accepts a DispatchQoS parameter:
extension DispatchQueue {
init(qos: DispatchQoS, attributes: DispatchQueueAttributes)
class func global(qos: DispatchQoS, attributes: DispatchQueue.GlobalAttributes) -> DispatchQueue
}
extension DispatchQueueAttributes {
// replacing dispatch_queue_attr_make_with_qos_class
init(qos: DispatchQoS, attributes: DispatchQueueAttributes)
}
Previous ID | SR-1101 |
Radar | None |
Original Reporter | vivkong (JIRA User) |
Type | Bug |
Status | Resolved |
Resolution | Done |
Linux on System z
Votes | 0 |
Component/s | libdispatch |
Labels | Bug |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
md5: a7951153e57029c0fb082e9d3b092d9d
Issue Description:
Trying to compile libdispatch using Clang 3.9 (trunk) and ran into these errors:
In file included from allocator.c:21:
In file included from ./internal.h:824:
./inline_internal.h:500:2: error: invalid application of 'typeof' to bit-field
dispatch_assert(dq->dq_is_thread_bound);
^
./internal.h:401:10: note: expanded from macro 'dispatch_assert'
typeof(e) _e = fastpath(e); /* always eval 'e' */ \
^
queue.c:3071:6: error: invalid application of 'typeof' to bit-field
if (slowpath(dq->dq_is_thread_bound) ||
^
./internal.h:320:29: note: expanded from macro 'slowpath'
#define slowpath(x) ((typeof(x))__builtin_expect((long)(x), 0l))
source.c:624:2: error: invalid application of 'typeof' to bit-field
dispatch_assert_zero(ds->ds_is_installed);
^
./internal.h:423:10: note: expanded from macro 'dispatch_assert_zero'
typeof(e) _e = slowpath(e); /* always eval 'e' */ \
^
source.c:624:2: error: invalid application of 'typeof' to bit-field
./internal.h:423:19: note: expanded from macro 'dispatch_assert_zero'
typeof(e) _e = slowpath(e); /* always eval 'e' */ \
^
./internal.h:320:29: note: expanded from macro 'slowpath'
#define slowpath(x) ((typeof(x))__builtin_expect((long)(x), 0l))
^
We need to use Clang 3.9 as we encountered some bugs in Clang 3.6 that has been fixed in trunk. The restriction on applying typeof to a bit-field was added last November:
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151109/142911.html
Previous ID | SR-2036 |
Radar | None |
Original Reporter | fumoboy007 (JIRA User) |
Type | Bug |
Status | Resolved |
Resolution | Done |
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, SDKOverlay |
Assignee | None |
Priority | Medium |
md5: 8436718ce74bfc22c5a82e791a10defc
Issue Description:
The API Design Guidelines mandate that factory methods begin with the prefix “make”.
Consider DispatchSource.read(fileDescriptor:queue:)
. Indeed, DispatchSource.read
might mislead people to think that a read will be performed by this method. A clearer name would be DispatchSource.makeReadSource(fileDescriptor:queue:)
.
Ditto for the other factory methods.
Old Name | New Name |
---|---|
.machSend(port:eventMask:queue:) |
.makeMachSendSource(port:eventMask:queue:) |
.machReceive(port:queue:) |
.makeMachReceiveSource(port:queue:) |
.memoryPressure(eventMask:queue:) |
.makeMemoryPressureSource(eventMask:queue:) |
.process(identifier:eventMask:queue:) |
.makeProcessSource(identifier:eventMask:queue:) |
.read(fileDescriptor:queue:) |
.makeReadSource(fileDescriptor:queue:) |
.signal(signal:queue:) |
.makeSignalSource(signal:queue:) |
.timer(flags:queue:) |
.makeTimerSource(flags:queue:) |
.userDataAdd(queue:) |
.makeUserDataAddSource(queue:) |
.userDataOr(queue:) |
.makeUserDataOrSource(queue:) |
.fileSystemObject(fileDescriptor:eventMask:queue:) |
.makeFileSystemObjectSource(fileDescriptor:eventMask:queue:) |
.write(fileDescriptor:queue:) |
.makeWriteSource(fileDescriptor:queue:) |
Previous ID | SR-2309 |
Radar | None |
Original Reporter | dgrove-oss (JIRA User) |
Type | Bug |
Status | Resolved |
Resolution | Done |
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, Linux |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
md5: f2c4c608d93c907594116fa473b1e39e
Issue Description:
libdispatch uses the blocks language feature and therefore has a runtime dependency on libBlocksRuntime.so As we enable libdispatch by default on Linux and start depending on it in Foundation, xctest, etc. we need to decide how best to satisfy this dependency.
There are thee obvious options:
Rely on the end-user installing libblocksruntime on their system via apt get (ie, add as a general pre-req for Swift).
Embed the blocks runtime code into libdispatch.so (as is already done with Foundation).
Build one copy of the blocks runtime as part of building the Swift toolchain and have both dispatch and Foundation link to it.
Ultimately, the third option is probably the best final solution. It minimizes duplicated code and also would allow us to develop a single variant of the blocks runtime that implemented Swift retain/release operations and and avoid needing to "wrap" Swift blocks using @convention(block) when calling into C-code that was compiled to expect C blocks.
The first solution is trivial, but requires additional system libraries to be installed and thus creates a (small) additional barrier to entry.
The second solution is straightforward and can be implemented entirely within libdispatch by copying in the code from compiler-rt/lib/BlocksRuntime and tweaking the libdispatch build.
Previous ID | SR-3199 |
Radar | None |
Original Reporter | tylercloutier (JIRA User) |
Type | Bug |
Votes | 0 |
Component/s | Foundation, libdispatch |
Labels | Bug |
Assignee | mww (JIRA) |
Priority | Medium |
md5: 1641e42bfc66b37d5426aff6370cf49c
Issue Description:
It appears that the cancel handler is never invoked after calling cancel on a DispatchSource in Swift 3 on macOS.
This issue can be replicated by following steps with Swift 3.0.1.
You should see that although the cancel in invoked, the test completes without ever invoking the cancel handler configured on line 47.
Shouldn't the listeningSource maintain a strong reference to the handler and submit it to the main queue (in this case) to be run when cancel is invoked or am I misunderstanding something about the contract of cancel?
Note: This is on macOS. I have not tested this for Linux.
Previous ID | SR-1859 |
Radar | None |
Original Reporter | Andreas Grosam (JIRA User) |
Type | Bug |
Status | Closed |
Resolution | Won't Do |
Votes | 0 |
Component/s | libdispatch, Standard Library |
Labels | Bug, RunTimeCrash |
Assignee | Andreas Grosam (JIRA) |
Priority | Medium |
md5: 731bcc2142f4e03e3ff0ffc5490a8cc6
Issue Description:
With Swift 3, setting the target queue of an existing dispatch queue fails in the Simulator for iOS and tvOS. It does not fail on macOS. (watchOS not tested, and not tested on actual devices).
This did not fail with Swift 2.2.
The code below shows the issue:
func testSetTargetQueue() {
let queue = DispatchQueue(label: "queue", attributes: DispatchQueueAttributes.serial)
let syncQueue = DispatchQueue(label: "sync_queue", attributes: DispatchQueueAttributes.serial)
queue.setTarget(queue: syncQueue) // EXC_BAD_INSTRUCTION. Error: "Cannot change the target of this queue after it has been activated"
}
Previous ID | SR-1081 |
Radar | None |
Original Reporter | @drewcrawford |
Type | Bug |
Status | Resolved |
Resolution | Cannot Reproduce |
Linux x64
swift-DEVELOPMENT-SNAPSHOT-2016-03-24-a
Votes | 0 |
Component/s | libdispatch |
Labels | Bug |
Assignee | dgrove-oss (JIRA) |
Priority | Medium |
md5: 224425fb888ea5f30178d91784111d68
Issue Description:
The libdispatch tests hang here:
make[2]: Entering directory '/swift-dev/build/buildbot_linux/libdispatch-linux-x86_64/tests'
make[3]: Entering directory '/swift-dev/build/buildbot_linux/libdispatch-linux-x86_64/tests'
FAIL: dispatch_apply
PASS: dispatch_api
PASS: dispatch_c99
PASS: dispatch_debug
PASS: dispatch_queue_finalizer
This has never worked, I just haven't gotten around to filing the bug yet.
Previous ID | SR-2246 |
Radar | None |
Original Reporter | @lilyball |
Type | Bug |
Status | Resolved |
Resolution | Done |
Xcode 8 beta 4
Apple Swift version 3.0 (swiftlang-800.0.41.2 clang-800.0.36)
OS X 10.11.6 (15G31)
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, SDKOverlay |
Assignee | @lilyball |
Priority | Medium |
md5: ff61bb039a743599a3c83b4cefb47e4d
Issue Description:
dispatchQueue.async(flags: .barrier, execute: …)
does not work. When executed on a concurrent queue, it executes as a normal block instead of a barrier block.
Here's some code that reproduces the issue:
import Foundation
let timeout: Double = 5
class Test {
var value = 0
let queue = DispatchQueue(label: "test queue", attributes: .concurrent)
func runTest() {
let deadline = Date(timeIntervalSinceNow: timeout)
DispatchQueue.global(qos: .userInitiated).async {
while Date() < deadline {
self.queue.async(flags: .barrier, execute: {
self.value = 1
Thread.sleep(forTimeInterval: 0.1)
self.value = 0
})
Thread.sleep(forTimeInterval: 0.01)
}
}
while Date() < deadline {
queue.sync {
if self.value == 1 {
print("Barrier violation!")
exit(0)
}
}
}
print("deadline elapsed")
}
}
Test().runTest()
Previous ID | SR-3097 |
Radar | None |
Original Reporter | @karwa |
Type | Bug |
Swift 3
Votes | 0 |
Component/s | libdispatch |
Labels | Bug, RunTimeCrash |
Assignee | mww (JIRA) |
Priority | Medium |
md5: b81d63c73d62a0030cc60459e73a98fc
relates to:
Issue Description:
I have an API which accepts a Foundation Data, and I'm trying to feed it the bytes I read from DispatchIO.read (which come packaged as a DispatchData). The following code (which is the best solution I could find to bridge from DispatchData to Foundation's Data without copying) crashes in Swift 3 when the data is empty:
let dispatchData = DispatchData.empty
dispatchData.withUnsafeBytes { (ptr: UnsafePointer<Int8>) -> Void in
// We make the pointer mutating, but the Data is a `let` so we won't mutate the bytes
let foundationData = Data(bytesNoCopy: UnsafeMutableRawPointer(mutating: ptr), count: dispatchData.count, deallocator: .none)
print("\(foundationData)")
}
The root of the problem seems to be that the Swift dispatch overlay is returning a null-pointer as non-optional, and it gets dereferenced somewhere.
* thread #​1: tid = 0xda386b, 0x000000010067c557 libswiftDispatch.dylib`Dispatch.DispatchData.withUnsafeBytes <A, B> (body : (Swift.UnsafePointer<B>) throws -> A) throws -> A + 215, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
* frame #​0: 0x000000010067c557 libswiftDispatch.dylib`Dispatch.DispatchData.withUnsafeBytes <A, B> (body : (Swift.UnsafePointer<B>) throws -> A) throws -> A + 215
frame #​1: 0x00000001006f80f2 $__lldb_expr38`main + 242 at repl.swift:42
frame #​2: 0x0000000100001420 repl_swift`_mh_execute_header + 5152
frame #​3: 0x00000001000014c8 repl_swift`main + 168 at main.swift:46
frame #​4: 0x00007fffea293255 libdyld.dylib`start + 1
frame #​5: 0x00007fffea293255 libdyld.dylib`start + 1
Previous ID | SR-449 |
Radar | None |
Original Reporter | @drewcrawford |
Type | Bug |
OSX 10.11.2 (15C50)
Votes | 0 |
Component/s | libdispatch |
Labels | Bug |
Assignee | None |
Priority | Medium |
md5: c2d3e7f105ad4e500d99318787216438
Issue Description:
$ brew install libtool automake autoconf
$./autogen.sh
$ ./configure
$ make
/bin/sh ../libtool --tag=CC --mode=compile clang -DHAVE_CONFIG_H -I. -I../config -I.. -I.. -I../private -I../os -Wall -fvisibility=hidden -momit-leaf-frame-pointer -fblocks -g -O2 -c -o allocator.lo allocator.c
libtool: compile: clang -DHAVE_CONFIG_H -I. -I../config -I.. -I.. -I../private -I../os -Wall -fvisibility=hidden -momit-leaf-frame-pointer -fblocks -g -O2 -c allocator.c -fno-common -DPIC -o .libs/allocator.o
In file included from allocator.c:21:
In file included from ./internal.h:138:
../private/voucher_activity_private.h:493:10: fatal error: 'os/lock_private.h' file not found
#include <os/lock_private.h>
^
1 error generated.
make[2]: *** [allocator.lo] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
Previous ID | SR-3028 |
Radar | None |
Original Reporter | michael-yuji (JIRA User) |
Type | Bug |
Status | Closed |
Resolution | Invalid |
OS X 10.12
Votes | 0 |
Component/s | libdispatch |
Labels | Bug |
Assignee | None |
Priority | Medium |
md5: 13ab7af38c18a6a0a6f154f8ac1b81f0
Issue Description:
Basically, when use DispatchSource(tested Timer and FileSystem) within a do-catch block will break the GCD source.
Consider the code below, it works fine without do-catch block but stop working when the block is present. Since explicitly referencing source inside the eventhandler will solve the program despite nested in do-catch block.
My educational guess is that somehow the do-catch block is breaking the dispatch_retain / dispatch_release cycle.
// main.swift
import Dispatch
do { // remove the try-catch block the timer works fine
let source = DispatchSource.makeTimerSource()
source.setEventHandler {
/* uncomment the next line, explicitly reference `source` will resolve the issue as well */
// _ = source
print("hello world")
}
source.scheduleRepeating(deadline: DispatchTime.now(), interval: DispatchTimerInterval.seconds(1))
source.resume()
} catch {}
dispatchMain()
Previous ID | SR-1941 |
Radar | None |
Original Reporter | miken (JIRA User) |
Type | Bug |
Votes | 0 |
Component/s | libdispatch |
Labels | Bug |
Assignee | mww (JIRA) |
Priority | Medium |
md5: d1490ba04e755f83c340b8874532c6bf
Issue Description:
Attempting to create a dispatch source or I/O channel is a fallible operation. In Swift 2.2 the functions used for creating them are annotated as returning implicitly-unwrapped optionals, and nil is returned when creation fails. This can be checked for and handled appropriately.
In Swift 2.3 and 3.0 the functions/initializers are annotated as returning non-nil values, but nil can still be returned. This can be reproduced by providing invalid parameters.
The code below will run successfully under Swift 2.2, but will crash at runtime under 2.3 and 3.0 despite the lack of any forced or implicit unwrapping.
#if swift(>=3.0)
let channel = DispatchIO(type: .stream, path: "../bad.path", oflag: O_RDONLY, mode: S_IRUSR, queue: .main) { (error) in
print(error)
}
print(channel) // Crash
let source = DispatchSource.signal(signal: Int32.min)
print(source) // Crash
#elseif swift(>=2.3)
let channel = dispatch_io_create_with_path(DISPATCH_IO_STREAM, "../bad.path", O_RDONLY, S_IRUSR, dispatch_get_main_queue()) { (error) in
print(error)
}
print(channel) // Crash
let source = dispatch_source_create(DISPATCH_SOURCE_TYPE_SIGNAL, UInt.max, 0, dispatch_get_main_queue())
print(source) // Crash
#else
let channel = dispatch_io_create_with_path(DISPATCH_IO_STREAM, "../bad.path", O_RDONLY, S_IRUSR, dispatch_get_main_queue()) { (error) in
print(error)
}
print(channel ?? "Nil") // Nil
let source = dispatch_source_create(DISPATCH_SOURCE_TYPE_SIGNAL, UInt.max, 0, dispatch_get_main_queue())
print(source ?? "Nil") // Nil
#endif
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.