Giter Site home page Giter Site logo

apple / swift-corelibs-libdispatch Goto Github PK

View Code? Open in Web Editor NEW
2.4K 226.0 454.0 4.67 MB

The libdispatch Project, (a.k.a. Grand Central Dispatch), for concurrency on multicore hardware

Home Page: swift.org

License: Apache License 2.0

Shell 0.49% C 86.18% C++ 1.68% Objective-C 3.87% DTrace 0.52% Objective-C++ 0.65% Swift 4.63% CMake 1.99%

swift-corelibs-libdispatch's Introduction

Grand Central Dispatch

Grand Central Dispatch (GCD or libdispatch) provides comprehensive support for concurrent code execution on multicore hardware.

libdispatch is currently available on all Darwin platforms. This project aims to make a modern version of libdispatch available on all other Swift platforms. To do this, we will implement as much of the portable subset of the API as possible, using the existing open source C implementation.

libdispatch on Darwin is a combination of logic in the xnu kernel alongside the user-space Library. The kernel has the most information available to balance workload across the entire system. As a first step, however, we believe it is useful to bring up the basic functionality of the library using user-space pthread primitives on Linux. Eventually, a Linux kernel module could be developed to support more informed thread scheduling.

Project Status

A port of libdispatch to Linux has been completed. On Linux, since Swift 3, swift-corelibs-libdispatch has been included in all Swift releases and is used by other swift-corelibs projects.

Opportunities to contribute and on-going work include:

  1. Develop a test suite for the Swift APIs of libdispatch.
  2. Enhance libdispatch as needed to support Swift language evolution and the needs of the other Core Libraries projects.

Build and Install

For detailed instructions on building and installing libdispatch, see INSTALL.md

Testing

For detailed instructions on testing libdispatch, see TESTING.md

swift-corelibs-libdispatch's People

Contributors

aciidgh avatar adierking avatar al45tair avatar atrick avatar compnerd avatar das avatar dgrove-oss avatar douggregor avatar etcwilde avatar frankeh avatar gonzalolarralde avatar ikesyo avatar jblache avatar jrose-apple avatar katashimonosato avatar ktopley-apple avatar ktoso avatar madcoder avatar millenomi avatar mwwa avatar parkera avatar rintaro avatar seabaylea avatar shahmishal avatar slavapestov avatar spevans avatar tachoknight avatar triplef avatar tristanlabelle avatar weissi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

swift-corelibs-libdispatch's Issues

[SR-2202] asyncAfter(deadline: DispatchTime, ...) has an erroneous parameter label

Previous ID SR-2202
Radar None
Original Reporter @glessard
Type Bug
Environment

Swift Development Snapshot 2016-07-25a

Additional Detail from JIRA
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.

[SR-1106] use of unresolved identifier 'DISPATCH_SOURCE_TYPE_READ'

Previous ID SR-1106
Radar None
Original Reporter s00p3rj03l (JIRA User)
Type Bug
Status Resolved
Resolution Done
Additional Detail from JIRA
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:

[SR-1941] Dispatch object creation can return nil despite non-nil type annotations

Previous ID SR-1941
Radar None
Original Reporter miken (JIRA User)
Type Bug
Additional Detail from JIRA
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

[SR-2309] Linux: libdispatch runtime dependency on blocks runtime

Previous ID SR-2309
Radar None
Original Reporter dgrove-oss (JIRA User)
Type Bug
Status Resolved
Resolution Done
Additional Detail from JIRA
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:

  1. Rely on the end-user installing libblocksruntime on their system via apt get (ie, add as a general pre-req for Swift).

  2. Embed the blocks runtime code into libdispatch.so (as is already done with Foundation).

  3. 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.

[SR-744] QOS is unimplemented on Linux

Previous ID SR-744
Radar None
Original Reporter @drewcrawford
Type Bug
Status Resolved
Resolution Done
Environment

Linux x64
swift-DEVELOPMENT-SNAPSHOT-2016-02-08-a

Additional Detail from JIRA
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.

[SR-1923] Building Foundation with lib dispatch support fails with a glibc module error

Previous ID SR-1923
Radar None
Original Reporter @phausler
Type Bug
Status Resolved
Resolution Done
Additional Detail from JIRA
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;
                ^

[SR-2050] Code crashes with "EXC_BAD_ACCESS" when appending UnsafeBufferPointer to DispatchData

Previous ID SR-2050
Radar rdar://problem/27293973
Original Reporter Ostoich (JIRA User)
Type Bug
Status Resolved
Resolution Done

Attachment: Download

Additional Detail from JIRA
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.

[SR-2012] Repeating DispatchSource timers are not repeating

Previous ID SR-2012
Radar None
Original Reporter brett (JIRA User)
Type Bug
Status Resolved
Resolution Done
Environment

Swift 3 / Xcode 8 beta 2 / macOS 10.11.5

Additional Detail from JIRA
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()
    }
}

[SR-2856] libdispatch dispatch_timer_set_time test is flaky

Previous ID SR-2856
Radar rdar://problem/28598500
Original Reporter erg (JIRA User)
Type Bug
Status Resolved
Resolution Done
Additional Detail from JIRA
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

```
PASS: dispatch_starfish
PASS: dispatch_data
PASS: dispatch_io_net
PASS: dispatch_select

libdispatch 1.3: tests/test-suite.log

  1. TOTAL: 22

  2. PASS: 21

  3. SKIP: 0

  4. XFAIL: 0

  5. FAIL: 1

  6. XPASS: 0

  7. ERROR: 0

.. contents:: :depth: 2

FAIL: dispatch_timer_set_time

==================================================
[TEST] Dispatch Update Timer
[PID] 41980

[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)

============================================================================
Testsuite summary for libdispatch 1.3

  1. TOTAL: 22

  2. PASS: 21

  3. SKIP: 0

  4. XFAIL: 0

  5. FAIL: 1

  6. XPASS: 0

  7. ERROR: 0
    ```

[SR-2335] Did `queue.async(flags: .barrier)` stop working or change behavior?

Previous ID SR-2335
Radar None
Original Reporter simplgy (JIRA User)
Type Bug
Status Closed
Resolution Invalid

Attachment: Download

Environment

xcode 8 beta 5 swift playground

Additional Detail from JIRA
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?

[SR-1081] libdispatch tests hang

Previous ID SR-1081
Radar None
Original Reporter @drewcrawford
Type Bug
Status Resolved
Resolution Cannot Reproduce
Environment

Linux x64
swift-DEVELOPMENT-SNAPSHOT-2016-03-24-a

Additional Detail from JIRA
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.

[SR-2356] Remove temporary libdispatch APIs before Swift 3 GA

Previous ID SR-2356
Radar None
Original Reporter dgrove-oss (JIRA User)
Type Bug
Status Closed
Resolution Done
Additional Detail from JIRA
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
                          ^

[SR-739] dispatch_queue_t is not upcastable to dispatch_object_t

Previous ID SR-739
Radar None
Original Reporter @drewcrawford
Type Bug
Status Resolved
Resolution Won't Do
Environment

Linux x64
swift-DEVELOPMENT-SNAPSHOT-2016-02-08-a

Additional Detail from JIRA
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

[SR-3097] Empty DispatchData returns a nil pointer in withUnsafeBytes

Previous ID SR-3097
Radar None
Original Reporter @karwa
Type Bug
Environment

Swift 3

Additional Detail from JIRA
Votes 0
Component/s libdispatch
Labels Bug, RunTimeCrash
Assignee mww (JIRA)
Priority Medium

md5: b81d63c73d62a0030cc60459e73a98fc

relates to:

  • SR-2976 [Swift 4] Add an UnsafeBufferPointer.empty API

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 #&#8203;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 #&#8203;0: 0x000000010067c557 libswiftDispatch.dylib`Dispatch.DispatchData.withUnsafeBytes <A, B> (body : (Swift.UnsafePointer<B>) throws -> A) throws -> A + 215
    frame #&#8203;1: 0x00000001006f80f2 $__lldb_expr38`main + 242 at repl.swift:42
    frame #&#8203;2: 0x0000000100001420 repl_swift`_mh_execute_header + 5152
    frame #&#8203;3: 0x00000001000014c8 repl_swift`main + 168 at main.swift:46
    frame #&#8203;4: 0x00007fffea293255 libdyld.dylib`start + 1
    frame #&#8203;5: 0x00007fffea293255 libdyld.dylib`start + 1

[SR-1242] undefined reference to `pthread_workqueue_signal_np'

Previous ID SR-1242
Radar None
Original Reporter @drewcrawford
Type Bug
Status Closed
Resolution Done

Attachment: Download

Environment

swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a
linux x64

Additional Detail from JIRA
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.

[SR-2905] Linux libpwq: Dispatch queues + blocking tasks = poor performance

Previous ID SR-2905
Radar None
Original Reporter fumoboy007 (JIRA User)
Type Bug
Environment

Linux, Swift 3.0

Additional Detail from JIRA
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?

[SR-1817] Need of a way to convert DispatchTime to AVAudioTime and AVAudioTime to DispatchTime

Previous ID SR-1817
Radar rdar://26873952
Original Reporter Hal (JIRA User)
Type Improvement
Status Resolved
Resolution Done
Additional Detail from JIRA
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.

[SR-3113] Reading from a DispatchIO channel which is a non-existent relative file path, crashes the program.

Previous ID SR-3113
Radar rdar://problem/28564226
Original Reporter @weissi
Type Bug
Status Resolved
Resolution Done

Attachment: Download

Additional Detail from JIRA
Votes 0
Component/s libdispatch
Labels Bug, RunTimeCrash
Assignee ktopley-apple (JIRA)
Priority Medium

md5: b7e0af488af89207765090918f413f1b

Issue Description:

Summary

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.

Steps To Reproduce

  1. Compile the attached program (swiftc -o quick-crash quick-crash.swift)

  2. Run program: ./quick-crash

  3. Run program again, supplying a path: ./quick-crash some-relative-path

  4. Run program once again: ./quick-crash /some-absolute-path

Results

  • 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)

Regression:

?

Notes:

  • 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 #&#8203;1: tid = 1020, 0x00007ffff7ef8a20 libdispatch.so`dispatch_io_read, name = 'qc', stop reason = signal SIGSEGV: invalid address (fault address: 0x8)
    frame #&#8203;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 #&#8203;1: tid = 1020, 0x00007ffff7ef8a20 libdispatch.so`dispatch_io_read, name = 'qc', stop reason = signal SIGSEGV: invalid address (fault address: 0x8)
  * frame #&#8203;0: 0x00007ffff7ef8a20 libdispatch.so`dispatch_io_read
    frame #&#8203;1: 0x00007ffff7f199f8 libdispatch.so`_TFC8Dispatch10DispatchIO4readfT6offsetSi6lengthSi5queueCS_13DispatchQueue9ioHandlerFTSbGSqVS_12DispatchData_Vs5Int32_T__T_ + 200
    frame #&#8203;2: 0x00000000004025cd qc`main + 1949
    frame #&#8203;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 #&#8203;4: 0x0000000000401d59 qc`_start + 41

[SR-2246] dispatchQueue.async(flags: .barrier) does not work

Previous ID SR-2246
Radar None
Original Reporter @lilyball
Type Bug
Status Resolved
Resolution Done
Environment

Xcode 8 beta 4
Apple Swift version 3.0 (swiftlang-800.0.41.2 clang-800.0.36)
OS X 10.11.6 (15G31)

Additional Detail from JIRA
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()

[SR-3028] do-catch block break nested DispatchSource workitem

Previous ID SR-3028
Radar None
Original Reporter michael-yuji (JIRA User)
Type Bug
Status Closed
Resolution Invalid
Environment

OS X 10.12

Additional Detail from JIRA
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()

[SR-2931] libdispatch `dispatch_suspend_timer` test needs robustification

Previous ID SR-2931
Radar None
Original Reporter erg (JIRA User)
Type Bug
Status Resolved
Resolution Won't Do
Additional Detail from JIRA
Votes 0
Component/s libdispatch
Labels Bug, Linux
Assignee dgrove-oss (JIRA)
Priority Medium

md5: b1a66dd63a8bf2dc1f3bfe6379f2bcb9

is duplicated by:

  • SR-3110 libdispatch - FAIL dispatch_suspend_timer (exit status: 1)

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

```
PASS: dispatch_timer
PASS: dispatch_timer_short
PASS: dispatch_timer_timeout
PASS: dispatch_sema
FAIL: dispatch_suspend_timer
PASS: dispatch_timer_bit31
PASS: dispatch_timer_bit63
PASS: dispatch_timer_set_time
PASS: dispatch_starfish
PASS: dispatch_cascade
PASS: dispatch_data
PASS: dispatch_io_net
PASS: dispatch_select

Testsuite summary for libdispatch 1.3

  1. TOTAL: 23

  2. PASS: 22

  3. SKIP: 0

  4. XFAIL: 0

  5. FAIL: 1

  6. XPASS: 0

  7. ERROR: 0

    See tests/test-suite.log
    Please report to https://bugs.swift.org

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

[SR-2248] dispatchQueue.async(flags: .barrier) shouldn't create a DispatchWorkItem

Previous ID SR-2248
Radar None
Original Reporter @lilyball
Type Bug
Status Closed
Resolution Done
Environment

swift-DEVELOPMENT-SNAPSHOT-2016-07-29-a-139-g6b1210e

Additional Detail from JIRA
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.

[SR-1843] Libdispatch: DispatchData api inconsistency

Previous ID SR-1843
Radar None
Original Reporter @DevAndArtist
Type Bug
Environment

Swift 3 from first Xcode 8 beta.

Additional Detail from JIRA
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
}

[SR-1770] DispatchQoS can't be used to initialize a DispatchQueue

Previous ID SR-1770
Radar rdar://problem/26879343
Original Reporter @glessard
Type Bug
Status Closed
Resolution Done
Environment

Xcode 8 (beta, 8S128d) with Swift 3.0 preview 1

Additional Detail from JIRA
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)
}

[SR-2205] Linker fails when linking to Foundation if -static-stdlib flag is present

Previous ID SR-2205
Radar rdar://problem/34535228
Original Reporter mominul (JIRA User)
Type Bug

Attachment: Download

Environment

DEVELOPMENT-SNAPSHOT-2016-07-25
Ubuntu 16.04

Additional Detail from JIRA
Votes 15
Component/s libdispatch
Labels Bug, Linux
Assignee None
Priority Medium

md5: 76b3df295dd2c0f2cbc48f0a20b3a982

is duplicated by:

  • SR-6434 libdispatch.a missing on Linux

relates to:

  • SR-10625 tests for -static-*
  • SR-9289 libFoundation.a is missing from swift development snapshots

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!

[SR-3237] Tests `dispatch_io_net` and `dispatch_select` in swift-corelibs-libdispatch fail when `/usr/bin/vi` does not exist.

Previous ID SR-3237
Radar None
Original Reporter @norio-nomura
Type Bug
Status Closed
Resolution Done

Attachment: Download

Environment

cb59f92 on swift-corelibs-libdispatch

Additional Detail from JIRA
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`.

[SR-2903] Serializer::writeAST crashes when building libdispatch

Previous ID SR-2903
Radar None
Original Reporter @rxwei
Type Bug
Status Closed
Resolution Cannot Reproduce
Environment

Fedora 24, release without assertion

Additional Detail from JIRA
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 ..
#&#8203;0 0x00000000034b2205 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/swift-linux-x86_64/bin/swiftc+0x34b2205)
#&#8203;1 0x00000000034b28e6 SignalHandler(int) (/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/swift-linux-x86_64/bin/swiftc+0x34b28e6)
#&#8203;2 0x00007fc370aedc10 __restore_rt (/lib64/libpthread.so.0+0x10c10)
#&#8203;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)
#&#8203;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)
#&#8203;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)
#&#8203;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)
#&#8203;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)
#&#8203;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)
#&#8203;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)
#&#8203;10 0x00000000007fe987 main (/mnt/hgfs/rxwei/Development/Swift/swift-linux/build/swift-linux-x86_64/bin/swiftc+0x7fe987)
#&#8203;11 0x00007fc36f207731 __libc_start_main (/lib64/libc.so.6+0x20731)
#&#8203;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

[SR-438] 'make distcheck' fails due to `fatal error: 'linux_port.h' file not found`

Previous ID SR-438
Radar None
Original Reporter @drewcrawford
Type Bug
Status Closed
Resolution Done
Environment

Linux x64

Additional Detail from JIRA
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.

[SR-449] swift-corelibs-libdispatch doesn't build on El Capitan

Previous ID SR-449
Radar None
Original Reporter @drewcrawford
Type Bug
Environment

OSX 10.11.2 (15C50)

Additional Detail from JIRA
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

[SR-2107] LIBDispatch DispatchIO read Max Int not reading until EOF

Previous ID SR-2107
Radar None
Original Reporter sandmman (JIRA User)
Type Bug
Environment

OSX Xcode 8

Additional Detail from JIRA
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.

[SR-2655] in libdispatch/libpwq worker threads, too many signals are blocked on Linux

Previous ID SR-2655
Radar None
Original Reporter @weissi
Type Bug
Status Resolved
Resolution Done

Attachment: Download

Additional Detail from JIRA
Votes 0
Component/s libdispatch
Labels Bug, Linux
Assignee dgrove-oss (JIRA)
Priority Medium

md5: 071933e7988663468728927c7cfe2cd7

Issue Description:

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.

Repro

Running the attached test.c shows the problem:

Darwin
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
=======
Linux

libdispatch @ https://github.com/apple/swift-corelibs-libdispatch/tree/7fe8323838b0491691e515a7f826ffe508668856 ish

Linux build 4.4.0-36-generic #&#8203;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
=======

[SR-2036] Naming of DispatchSource factory methods

Previous ID SR-2036
Radar None
Original Reporter fumoboy007 (JIRA User)
Type Bug
Status Resolved
Resolution Done
Additional Detail from JIRA
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:)

[SR-1771] DispatchTime should be Comparable

Previous ID SR-1771
Radar rdar://problem/26879337
Original Reporter @glessard
Type Bug
Status Resolved
Resolution Done
Environment

Xcode 8 (beta, 8S128d) with Swift 3.0 preview 1

Additional Detail from JIRA
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.

[SR-2207] DispatchQoS.init(qosClass: DispatchQoS.QoSClass, relativePriority: Int) should have a default relative priority

Previous ID SR-2207
Radar None
Original Reporter @glessard
Type Improvement
Environment

Xcode 8 beta 3

Additional Detail from JIRA
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
    }
}

[SR-2067] GCD (libdispatch) for Windows has misuse of QueryPerformanceFrequency

Previous ID SR-2067
Radar None
Original Reporter @benrimmington
Type Bug
Status Resolved
Resolution Invalid
Additional Detail from JIRA
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?

[SR-1935] Timer granularity too coarse for test cases

Previous ID SR-1935
Radar None
Original Reporter frankeh (JIRA User)
Type Bug
Status Resolved
Resolution Done
Additional Detail from JIRA
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.

[SR-1101] invalid application of 'typeof' to bit-field when compiled with Clang 3.9

Previous ID SR-1101
Radar None
Original Reporter vivkong (JIRA User)
Type Bug
Status Resolved
Resolution Done
Environment

Linux on System z

Additional Detail from JIRA
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

[SR-3110] libdispatch - FAIL dispatch_suspend_timer (exit status: 1)

Previous ID SR-3110
Radar None
Original Reporter @shahmishal
Type Bug
Status Resolved
Resolution Duplicate

Attachment: Download

Additional Detail from JIRA
Votes 0
Component/s libdispatch
Labels Bug
Assignee dgrove-oss (JIRA)
Priority Medium

Watchers: @shahmishal

md5: be96691d4fc61dba8b42feb0fb564b98

duplicates:

  • SR-2931 libdispatch dispatch_suspend_timer test needs robustification

Issue Description:

==================================================
[TEST] Dispatch Suspend Timer
[PID] 28804

[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)

[SR-2941] [libdispatch] kqtest fails randomly with ``bind-1: Address already in use``

Previous ID SR-2941
Radar None
Original Reporter erg (JIRA User)
Type Bug
Status Resolved
Resolution Done
Additional Detail from JIRA
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

============================================================================
Testsuite summary for libpthread_workqueue 0.9.4

  1. TOTAL: 3

  2. PASS: 3

  3. SKIP: 0

  4. XFAIL: 0

  5. FAIL: 0

  6. XPASS: 0

  7. ERROR: 0

    make[3]: Leaving directory '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/libdispatch-linux-x86_64/libpwq'
    make[2]: Leaving directory '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/libdispatch-linux-x86_64/libpwq'
    make[1]: Leaving directory '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/libdispatch-linux-x86_64/libpwq'
    Making check in libkqueue
    make[1]: Entering directory '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/libdispatch-linux-x86_64/libkqueue'
    make kqtest
    make[2]: Entering directory '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/libdispatch-linux-x86_64/libkqueue'
    /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/llvm-linux-x86_64/bin/clang -DHAVE_CONFIG_H -I. -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue -g -O0 -Wall -Werror -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/include -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/test -I. -g -O2 -MT test/kqtest-main.o -MD -MP -MF test/.deps/kqtest-main.Tpo -c -o test/kqtest-main.o test -f 'test/main.c' || echo '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/'test/main.c
    mv -f test/.deps/kqtest-main.Tpo test/.deps/kqtest-main.Po
    /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/llvm-linux-x86_64/bin/clang -DHAVE_CONFIG_H -I. -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue -g -O0 -Wall -Werror -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/include -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/test -I. -g -O2 -MT test/kqtest-kevent.o -MD -MP -MF test/.deps/kqtest-kevent.Tpo -c -o test/kqtest-kevent.o test -f 'test/kevent.c' || echo '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/'test/kevent.c
    mv -f test/.deps/kqtest-kevent.Tpo test/.deps/kqtest-kevent.Po
    /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/llvm-linux-x86_64/bin/clang -DHAVE_CONFIG_H -I. -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue -g -O0 -Wall -Werror -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/include -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/test -I. -g -O2 -MT test/kqtest-test.o -MD -MP -MF test/.deps/kqtest-test.Tpo -c -o test/kqtest-test.o test -f 'test/test.c' || echo '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/'test/test.c
    mv -f test/.deps/kqtest-test.Tpo test/.deps/kqtest-test.Po
    /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/llvm-linux-x86_64/bin/clang -DHAVE_CONFIG_H -I. -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue -g -O0 -Wall -Werror -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/include -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/test -I. -g -O2 -MT test/kqtest-proc.o -MD -MP -MF test/.deps/kqtest-proc.Tpo -c -o test/kqtest-proc.o test -f 'test/proc.c' || echo '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/'test/proc.c
    mv -f test/.deps/kqtest-proc.Tpo test/.deps/kqtest-proc.Po
    /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/llvm-linux-x86_64/bin/clang -DHAVE_CONFIG_H -I. -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue -g -O0 -Wall -Werror -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/include -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/test -I. -g -O2 -MT test/kqtest-read.o -MD -MP -MF test/.deps/kqtest-read.Tpo -c -o test/kqtest-read.o test -f 'test/read.c' || echo '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/'test/read.c
    mv -f test/.deps/kqtest-read.Tpo test/.deps/kqtest-read.Po
    /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/llvm-linux-x86_64/bin/clang -DHAVE_CONFIG_H -I. -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue -g -O0 -Wall -Werror -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/include -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/test -I. -g -O2 -MT test/kqtest-signal.o -MD -MP -MF test/.deps/kqtest-signal.Tpo -c -o test/kqtest-signal.o test -f 'test/signal.c' || echo '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/'test/signal.c
    mv -f test/.deps/kqtest-signal.Tpo test/.deps/kqtest-signal.Po
    /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/llvm-linux-x86_64/bin/clang -DHAVE_CONFIG_H -I. -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue -g -O0 -Wall -Werror -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/include -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/test -I. -g -O2 -MT test/kqtest-timer.o -MD -MP -MF test/.deps/kqtest-timer.Tpo -c -o test/kqtest-timer.o test -f 'test/timer.c' || echo '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/'test/timer.c
    mv -f test/.deps/kqtest-timer.Tpo test/.deps/kqtest-timer.Po
    /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/llvm-linux-x86_64/bin/clang -DHAVE_CONFIG_H -I. -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue -g -O0 -Wall -Werror -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/include -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/test -I. -g -O2 -MT test/kqtest-vnode.o -MD -MP -MF test/.deps/kqtest-vnode.Tpo -c -o test/kqtest-vnode.o test -f 'test/vnode.c' || echo '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/'test/vnode.c
    mv -f test/.deps/kqtest-vnode.Tpo test/.deps/kqtest-vnode.Po
    /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/llvm-linux-x86_64/bin/clang -DHAVE_CONFIG_H -I. -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue -g -O0 -Wall -Werror -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/include -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/test -I. -g -O2 -MT test/kqtest-user.o -MD -MP -MF test/.deps/kqtest-user.Tpo -c -o test/kqtest-user.o test -f 'test/user.c' || echo '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/'test/user.c
    mv -f test/.deps/kqtest-user.Tpo test/.deps/kqtest-user.Po
    /bin/bash ./libtool --tag=CC --mode=link /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/llvm-linux-x86_64/bin/clang -g -O0 -Wall -Werror -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/include -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/test -I. -g -O2 -o kqtest test/kqtest-main.o test/kqtest-kevent.o test/kqtest-test.o test/kqtest-proc.o test/kqtest-read.o test/kqtest-signal.o test/kqtest-timer.o test/kqtest-vnode.o test/kqtest-user.o -lpthread -lrt libkqueue.la
    libtool: link: /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/llvm-linux-x86_64/bin/clang -g -O0 -Wall -Werror -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/include -I/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift-corelibs-libdispatch/libkqueue/test -I. -g -O2 -o kqtest test/kqtest-main.o test/kqtest-kevent.o test/kqtest-test.o test/kqtest-proc.o test/kqtest-read.o test/kqtest-signal.o test/kqtest-timer.o test/kqtest-vnode.o test/kqtest-user.o ./.libs/libkqueue.a -lpthread -lrt
    make[2]: Leaving directory '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/libdispatch-linux-x86_64/libkqueue'
    make check-TESTS
    make[2]: Entering directory '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/libdispatch-linux-x86_64/libkqueue'
    make[3]: Entering directory '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/libdispatch-linux-x86_64/libkqueue'
    FAIL: kqtest

    libkqueue 2.1.0: ./test-suite.log

  8. TOTAL: 1

  9. PASS: 0

  10. SKIP: 0

  11. XFAIL: 0

  12. FAIL: 1

  13. XPASS: 0

  14. ERROR: 0

.. contents:: :depth: 2

FAIL: kqtest

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)

============================================================================
Testsuite summary for libkqueue 2.1.0

  1. TOTAL: 1
  2. PASS: 0
  3. SKIP: 0
  4. XFAIL: 0
  5. FAIL: 1
  6. XPASS: 0
  7. ERROR: 0

    See ./test-suite.log

    Makefile:1235: recipe for target 'test-suite.log' failed
    make[3]: *** [test-suite.log] Error 1
    make[3]: Leaving directory '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/libdispatch-linux-x86_64/libkqueue'
    Makefile:1341: recipe for target 'check-TESTS' failed
    make[2]: *** [check-TESTS] Error 2
    make[2]: Leaving directory '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/libdispatch-linux-x86_64/libkqueue'
    Makefile:1547: recipe for target 'check-am' failed
    make[1]: *** [check-am] Error 2
    make[1]: Leaving directory '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/libdispatch-linux-x86_64/libkqueue'
    Makefile:456: recipe for target 'check-recursive' failed
    make: *** [check-recursive] Error 1
    /home/buildnode/jenkins/workspace/oss-swift-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-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-incremental-RA-linux-ubuntu-15_10' for the testing framework 'JUnit'.
    [xUnit] [INFO] - Converting '/home/buildnode/jenkins/workspace/oss-swift-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
    Last: 8199 SUCCESS
    Current: 8200 FAILURE
    Finished: FAILURE

[SR-3335] Crash in _os_object_retain called by dispatch_io_write (by DispatchIO.write)

Previous ID SR-3335
Radar rdar://problem/29513290
Original Reporter @weissi
Type Bug
Status Resolved
Resolution Done

Attachment: Download

Additional Detail from JIRA
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 #&#8203;17: tid = 29284, 0x00007ffff7f17b07 libdispatch.so`_os_object_retain + 23, name = 'repro', stop reason = signal SIGILL: illegal instruction operand
  * frame #&#8203;0: 0x00007ffff7f17b07 libdispatch.so`_os_object_retain + 23
    frame #&#8203;1: 0x00007ffff7f13a64 libdispatch.so`dispatch_io_write + 36
    frame #&#8203;2: 0x00007ffff7f2e170 libdispatch.so`_TFC8Dispatch10DispatchIO5writefT6offsetSi4dataVS_12DispatchData5queueCS_13DispatchQueue9ioHandlerFTSbGSqS1__Vs5Int32_T__T_ + 208
    frame #&#8203;3: 0x0000000000404548 repro`_TFFFF5repro4mainFT_T_U_FTVs5Int32S0__T_U3_FTSbGSqV8Dispatch12DispatchData_S0__T_U_FT_T_ + 104
    frame #&#8203;4: 0x00000000004046a7 repro`_TTRXFo___XFdCb___ + 39
    frame #&#8203;5: 0x00007ffff7f10e37 libdispatch.so`_dispatch_call_block_and_release + 7
    frame #&#8203;6: 0x00007ffff7f1d2f1 libdispatch.so`_dispatch_queue_serial_drain + 737
    frame #&#8203;7: 0x00007ffff7f1d931 libdispatch.so`_dispatch_queue_invoke + 849
    frame #&#8203;8: 0x00007ffff7f1f9a9 libdispatch.so`_dispatch_root_queue_drain + 393
    frame #&#8203;9: 0x00007ffff7f44408 libdispatch.so`overcommit_worker_main(unused=<unavailable>) + 152 at manager.c:315
    frame #&#8203;10: 0x00007ffff77dc70a libpthread.so.0`start_thread + 202
    frame #&#8203;11: 0x00007ffff5d7382d libc.so.6`__clone + 109 at clone.S:109

Repro

1. compile and the attached program (swiftc repro.swift && ./repro)
2. you'll see crashes

Notes

Linux

$ swift -version
Swift version 3.0-dev (LLVM 56c58af739, Clang 205968da71, Swift e60daaaee1)
Target: x86_64-unknown-linux-gnu

macOS

$ swift -version
Apple Swift version 3.0.1 (swiftlang-800.0.58.6 clang-800.0.42.1)
Target: x86_64-apple-macosx10.9

[SR-2181] DispatchTimeInterval.nanoseconds won't work well on 32-bit architectures

Previous ID SR-2181
Radar rdar://problem/79952338
Original Reporter @lilyball
Type Bug
Environment

swift-DEVELOPMENT-SNAPSHOT-2016-07-25-a-125-g3331dc4

Additional Detail from JIRA
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.

[SR-3002] using DispatchData.enumerateBytes on Linux leaks the block

Previous ID SR-3002
Radar None
Original Reporter @weissi
Type Bug
Status Resolved
Resolution Done

Attachment: Download

Additional Detail from JIRA
Votes 0
Component/s libdispatch
Labels Bug, Leak, Linux
Assignee dgrove-oss (JIRA)
Priority Medium

md5: 323c438d5e940e5a5a3e6dc87ed9b40f

is blocked by:

  • SR-2313 Add withoutActuallyEscaping

Issue Description:

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.

Numbers

See below for some numbers:

Linux

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 #&#8203;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.

Darwin

$ 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 output

$ 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)

[SR-2656] Linux Swift 3.0 crashes in DispatchIO.read()

Previous ID SR-2656
Radar None
Original Reporter helge (JIRA User)
Type Bug
Status Resolved
Resolution Done
Environment

Ubuntu, either 14 or 15, doesn't matter with the final Swift 3.0 drop.

Additional Detail from JIRA
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.

[SR-2922] libdispatch depdencies are stale, "module file was created by an older version of the compiler"

Previous ID SR-2922
Radar rdar://28725613
Original Reporter erg (JIRA User)
Type Bug
Status Resolved
Resolution Done
Additional Detail from JIRA
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:

https://ci.swift.org/view/swift-3.0-branch/job/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/415/consoleFull#-964214433ee1a197b-acac-4b17-83cf-a53b95139a76

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

[SR-1769] qos_class_self() doesn't interoperate with DispatchQoS

Previous ID SR-1769
Radar rdar://problem/26879347
Original Reporter @glessard
Type Bug
Status Resolved
Resolution Done
Environment

Xcode 8 (beta, 8S128d) with Swift 3.0 preview 1

Additional Detail from JIRA
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?
}

[SR-740] dispatch_semaphore_t is not convertible to AnyObject

Previous ID SR-740
Radar None
Original Reporter @drewcrawford
Type Bug
Status Resolved
Resolution Won't Do
Environment

Linux x64
swift-DEVELOPMENT-SNAPSHOT-2016-02-08-a

Additional Detail from JIRA
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'

[SR-737] [dispatch] dispatch_queue_create has wrong return type

Previous ID SR-737
Radar None
Original Reporter @drewcrawford
Type Bug
Status Resolved
Resolution Won't Do
Environment

Linux x64
swift-DEVELOPMENT-SNAPSHOT-2016-02-08-a

Additional Detail from JIRA
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)

[SR-1859] DispatchQueue setTarget fails with EXC_BAD_INSTRUCTION

Previous ID SR-1859
Radar None
Original Reporter Andreas Grosam (JIRA User)
Type Bug
Status Closed
Resolution Won't Do
Additional Detail from JIRA
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"     
}

[SR-761] dispatch_async is "not very concurrent" and has a 1s overhead on Linux

Previous ID SR-761
Radar None
Original Reporter @drewcrawford
Type Bug
Status Resolved
Resolution Done

Attachment: Download

Environment

Linux x64
swift-DEVELOPMENT-SNAPSHOT-2016-02-08-a

Additional Detail from JIRA
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.

[SR-3199] Cancel handler is never called on DispatchSource after invoking `.cancel()`

Previous ID SR-3199
Radar None
Original Reporter tylercloutier (JIRA User)
Type Bug
Additional Detail from JIRA
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.

  1. Clone https://github.com/SwiftOnEdge/Edge.git
  2. Check out the commit 1bc2552c3f7cb0d33080d65b1290008ac5342cdf
  3. Comment out line 125 of /Sources/TCP/Server.swift and insert print statement there.
  4. Insert a print statement in the cancelHandler on line 47 of the same file
  5. Run the test RouterTests.testMiddleware

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.