Overlapping Accesses to 'Urlcomponents', But Modification Requires Exclusive Access

Overlapping accesses to 'urlComponents', but modification requires exclusive access

I guess you need to set first to a local variable and then change it , try this:

var urlComponents = URLComponents(url: mutableURLRequest.url!, resolvingAgainstBaseURL: false) 
var localVariable = urlComponents
urlComponents?.queryItems = (localVariable?.queryItems ?? []) + queryItems

Overlapping accesses to result , but modification requires exclusive access; consider copying to a local variable in xcode 10

That is a consequence of SE-0176 Enforce Exclusive Access to Memory, which was implemented in Swift 4
and is more strict in Swift 4.2.

The solution is to assign the count to a separate variable:

let count = result.count
let status = result.withUnsafeMutableBytes {
(passwDataBytes: UnsafeMutablePointer<UInt8>) -> CCCryptorStatus in
return CCKeyDerivationPBKDF(..., count)
}

or to capture the count in a capture list:

let status = result.withUnsafeMutableBytes { [ count = result.count ]
(passwDataBytes: UnsafeMutablePointer<UInt8>) -> CCCryptorStatus in
return CCKeyDerivationPBKDF(..., count)
}

See also Overlapping access warning in withUnsafeMutableBytes in the Swift forum

hamishknight:

withUnsafeMutableBytes(_:) is a mutating method on Data, therefore it requires write access to data for the duration of the call. By accessing data.count in the closure, you’re starting a new read on data which conflicts with the current write access.

Joe_Groff:

You could also capture a copy of data or its count in the closure’s capture list: ...

The capture list gets evaluated and the results captured by value when the closure is formed, before the exclusive access begins, avoiding the overlapping access.

and this comment in
the corresponding pull request:

Here an appropriate fix is to copy the count of buffer outside of the closure and pass that to inet_ntop() instead.

Update for Swift 5:

let status = result.withUnsafeMutableBytes { [ count = result.count ]
(bufferPointer) -> CCCryptorStatus in
let passwDataBytes = bufferPointer.bindMemory(to: UInt8.self).baseAddress
return CCKeyDerivationPBKDF(..., passwDataBytes, count)
}

Overlapping accesses to 'salt', but modification requires exclusive access; consider copying to a local variable

Finally, I resolved my issue modifying my code like this :

salt.withUnsafeMutableBytes { (saltBuffer: UnsafeMutableRawBufferPointer) in  
let saltBytes = saltBuffer.bindMemory(to: UInt8.self)
let saltStatus = SecRandomCopyBytes(kSecRandomDefault, saltBytes.count, saltBytes.baseAddress!)
if saltStatus == errSecSuccess {
let passwordData = password.data(using: .utf8)!
key.withUnsafeMutableBytes { (keyBuffer: UnsafeMutableRawBufferPointer) in
let keyBytes = keyBuffer.bindMemory(to: UInt8.self)
let derivationStatus = CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2), password, passwordData.count, saltBytes.baseAddress!, saltBytes.count, CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA512), 14271, keyBytes.baseAddress!, keyBytes.count)
if derivationStatus != Int32(kCCSuccess) {
setupSuccess = false
}
}
} else {
setupSuccess = false
}

}

Why does optional chaining cause an overlapping accesses error?

Structs are value types, so when you do let foo = someOptional?.foo, the value of someOptional?.foo is copied into the local variable foo. Hence in your next line, someOptional?.bar = foo you don't access someOptional to get the value of foo anymore, but you access the value of the local variable directly.

This is why someOptional?.bar = someOptional?.foo is not equivalent to the above solution and why saving the value to a local variable resolves the overlapping accesses error.

The cause of the error is also the fact that you are using value types. In the line someOptional?.bar = someOptional?.foo you are mutating an instance property of someOptional and hence mutating the instance someOptional as well, while at the exact same time accessing another instance property of someOptional.

If someOptional was a reference type, you wouldn't get that error, see below:

class SomeClass {
var foo: NSString? // `NSString` is a reference type
var bar: NSString?
}

let someOptionalClass: SomeClass? = SomeClass()
someOptionalClass?.bar = someOptionalClass?.foo

let fooRef = someOptionalClass?.foo
someOptionalClass?.bar = fooRef

SwiftUI @AppStroage - 'Simultaneous accesses to *, but modification requires exclusive access'

I am going to attribute this to a SwiftUI bug. I have submitted it to Apple (FB9975464). The issue seemed to be in the CrashSetting initializer, but it actually occurs without it. I believe the issue is using the dot (.) character in the AppStorage key. It has also caused [error] precondition failure: setting value during update: 5848. I haven't been able to produce a small demo with that crash, but removing the "." from my keys also solves it. If you experience any of the above, specifically while transitioning/navigating views, it's worth checking your AppStorage keys.

Simplest Crash Demo

  1. Build on iPad mini
  2. Tap Back button
import SwiftUI

@main
struct AppStorage_Key_IssueApp: App {
var body: some Scene {
WindowGroup {
ContentView()
}
}
}

struct ContentView: View {
// Using the "." character results in many hard to track crashes
@AppStorage("a.b")
var val = ""

var body: some View {
NavigationView {
PrimaryView()
Color.blue
}
}
}

struct PrimaryView: View {
var body: some View {
List {
NavigationLink {
Color.red
} label: {
Text("crashes")
}
}
.listStyle(InsetGroupedListStyle())
}
}

Simultaneous accesses to 0x6040000155d8, but modification requires exclusive access

You should try updating this line

createGameModel?.createGameOptions?.removeSubrange(2...((createGameModel?.createGameOptions?.count)! - 2))

To

let count = (createGameModel?.createGameOptions?.count)!
createGameModel?.createGameOptions?.removeSubrange(2...(count - 2))

Try and share the results

Simultaneous accesses to 0x14572f2a0, but modification requires exclusive access

This is what you get for testing the code in a playground — there's no debugger! If you try that code in a real app, the debugger tells you exactly what the problem is.

The problem is here:

public func withdraw(amount: Float) -> Bool {
return state.withdraw(amount: amount) // <-- *
}

The withdraw state's withdraw method sets the state property of its context, which is this ATM instance. So the call to state.withdraw means that we both mutate this ATM's state value directly, by replacing it with a different state object, and call its mutating method withdraw, in a single move. You can't do that, because the double mutation, to a property of the struct and to a reference to the struct as a whole, is incoherent. You have to proceed in stages, like this:

public func withdraw(amount: Float) -> Bool {
// fetch
var theState = self.state
// mutate
return theState.withdraw(amount: amount)
}

The alternative would be to make all of the state types classes instead of structs. A class, unlike a struct, is mutable in place. That would require considerably more rewriting, however, so that is left as an exercise for the reader.



Related Topics



Leave a reply



Submit