Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-2807] Dispatch{Wall,}Time behave unexpectedly #45411

Closed
liscio opened this issue Sep 30, 2016 · 8 comments
Closed

[SR-2807] Dispatch{Wall,}Time behave unexpectedly #45411

liscio opened this issue Sep 30, 2016 · 8 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. crash Bug: A crash, i.e., an abnormal termination of software run-time crash Bug → crash: Swift code crashed during execution SDKOverlay standard library Area: Standard library umbrella

Comments

@liscio
Copy link

liscio commented Sep 30, 2016

Previous ID SR-2807
Radar rdar://problem/28814085
Original Reporter @liscio
Type Bug
Status Resolved
Resolution Done
Environment

OS X 10.12, Xcode 8.0 and 8.1b both exhibit this behaviour.

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

md5: 99417332db9394130db3b9856aea74ff

Issue Description:

I was trying to build a test scheduler using DispatchTime and DispatchWallTime as the base type, and started out by creating (what I thought was) a zero-valued timestamp.

During this exercise, I found out that the following are problematic:

1: DispatchWallTime appears to crash during a comparison. See the below REPL session:

  1> import Foundation
  2> let wt = DispatchWallTime.now()
  3. let result = wt < ( wt + .milliseconds(1) )
  4.
wt: DispatchWallTime = {
  rawValue = <extracting data from value failed>

}
result: Bool = {
  _value = <extracting data from value failed>

}
Execution interrupted. Enter code to recover and continue.

2: Constructing a DispatchTime using an uptime value of 0 causes unexpected results. See the following REPL session:

  7> let zero = DispatchTime(uptimeNanoseconds: 0)
  8. let result2 = ( (zero + .milliseconds(1)) == (zero + .milliseconds(1) ) )
zero: DispatchTime = {
  rawValue = 0
}
result2: Bool = false

Hopefully this is enough to explain what's going on!

@belkadan
Copy link
Contributor

cc mww (JIRA User)

@lilyball
Copy link
Mannequin

lilyball mannequin commented Sep 30, 2016

I'm already working on the crash portion of this.

@lilyball
Copy link
Mannequin

lilyball mannequin commented Sep 30, 2016

Crash portion submitted as PR #5708.

@lilyball
Copy link
Mannequin

lilyball mannequin commented Sep 30, 2016

Regarding the second half, the problem with DispatchTime(uptimeNanoseconds: 0) is DISPATCH_TIME_NOW is defined with the value 0ull, so the dispatch_time APIs treat a value of zero as meaning now. This means that saying zero + anyDuration behaves identically to saying DispatchTime.now() + anyDuration.

@swift-ci
Copy link
Collaborator

swift-ci commented Oct 3, 2016

Comment by Daniel A. Steffen (JIRA)

internally to libdispatch we represent the 0 value for DispatchTime as 1ns for this reason

@lilyball
Copy link
Mannequin

lilyball mannequin commented Oct 14, 2016

Crash portion merged in 301510e.

@swift-ci
Copy link
Collaborator

Comment by Myke Olson (JIRA)

@swift-cicreate

@Dante-Broggi
Copy link
Contributor

If this is fixed, it should be closed.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@AnthonyLatsis AnthonyLatsis added the crash Bug: A crash, i.e., an abnormal termination of software label Dec 12, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. crash Bug: A crash, i.e., an abnormal termination of software run-time crash Bug → crash: Swift code crashed during execution SDKOverlay standard library Area: Standard library umbrella
Projects
None yet
Development

No branches or pull requests

5 participants