Dive into the world of programming languages used for app development.

All subtopics
Posts under Programming Languages topic

Post

Replies

Boosts

Views

Activity

App sometimes crashes when inserting String into Set with assertion ELEMENT_TYPE_OF_SET_VIOLATES_HASHABLE_REQUIREMENTS
Xcode downloaded a crash report for my app that crashed when trying to insert a String into a Set<String>. Apparently there was an assertion failure ELEMENT_TYPE_OF_SET_VIOLATES_HASHABLE_REQUIREMENTS. I assume that this assertion failure happened because the hash of the new element didn't match the hash of an equal already inserted element, but regardless, I don't understand how inserting a simple string could trigger this assertion. Here is essentially the code that leads to the crash. path is any file system directory, and basePath is a directory higher in the hierarchy, or path itself. var scanErrorPaths = Set<String>() func main() { let path = "/path/to/directory" let basePath = "/path" let fileDescriptor = open(path, O_RDONLY) if fileDescriptor < 0 { if (try? URL(fileURLWithPath: path, isDirectory: false).checkResourceIsReachable()) == true { scanErrorPaths.insert(path.relativePath(from: basePath)!) return } } extension String { func relativePath(from basePath: String) -> String? { if basePath == "" { return self } guard let index = range(of: basePath, options: .anchored)?.upperBound else { return nil } return if index == endIndex || basePath == "/" { String(self[index...]) } else if let index = self[index...].range(of: "/", options: .anchored)?.upperBound { String(self[index...]) } else { nil } } } crash.crash
7
0
947
Oct ’25
What is the future of Objective-C?
Will Apple continue to support it, or will we wake up one day to find that Swift is the only viable language?It's a serious question. Careers depend on it. I don't accept the "No comment" approach that Apple usually takes. It's cruel.I'm willing to put the time into learning Swift if I have to. I'm not going to do it if I don't. I want to know.Frank
23
1
34k
Oct ’25
Crash with Progress type, Swift 6, iOS 18
We are getting a crash _dispatch_assert_queue_fail when the cancellationHandler on NSProgress is called. We do not see this with iOS 17.x, only on iOS 18. We are building in Swift 6 language mode and do not have any compiler warnings. We have a type whose init looks something like this: init( request: URLRequest, destinationURL: URL, session: URLSession ) { progress = Progress() progress.kind = .file progress.fileOperationKind = .downloading progress.fileURL = destinationURL progress.pausingHandler = { [weak self] in self?.setIsPaused(true) } progress.resumingHandler = { [weak self] in self?.setIsPaused(false) } progress.cancellationHandler = { [weak self] in self?.cancel() } When the progress is cancelled, and the cancellation handler is invoked. We get the crash. The crash is not reproducible 100% of the time, but it happens significantly often. Especially after cleaning and rebuilding and running our tests. * thread #4, queue = 'com.apple.root.default-qos', stop reason = EXC_BREAKPOINT (code=1, subcode=0x18017b0e8) * frame #0: 0x000000018017b0e8 libdispatch.dylib`_dispatch_assert_queue_fail + 116 frame #1: 0x000000018017b074 libdispatch.dylib`dispatch_assert_queue + 188 frame #2: 0x00000002444c63e0 libswift_Concurrency.dylib`swift_task_isCurrentExecutorImpl(swift::SerialExecutorRef) + 284 frame #3: 0x000000010b80bd84 MyTests`closure #3 in MyController.init() at MyController.swift:0 frame #4: 0x000000010b80bb04 MyTests`thunk for @escaping @callee_guaranteed @Sendable () -&gt; () at &lt;compiler-generated&gt;:0 frame #5: 0x00000001810276b0 Foundation`__20-[NSProgress cancel]_block_invoke_3 + 28 frame #6: 0x00000001801774ec libdispatch.dylib`_dispatch_call_block_and_release + 24 frame #7: 0x0000000180178de0 libdispatch.dylib`_dispatch_client_callout + 16 frame #8: 0x000000018018b7dc libdispatch.dylib`_dispatch_root_queue_drain + 1072 frame #9: 0x000000018018bf60 libdispatch.dylib`_dispatch_worker_thread2 + 232 frame #10: 0x00000001012a77d8 libsystem_pthread.dylib`_pthread_wqthread + 224 Any thoughts on why this is crashing and what we can do to work-around it? I have not been able to extract our code into a simple reproducible case yet. And I mostly see it when running our code in a testing environment (XCTest). Although I have been able to reproduce it running an app a few times, it's just less common.
24
7
3.1k
Apr ’25
App sometimes crashes when inserting String into Set with assertion ELEMENT_TYPE_OF_SET_VIOLATES_HASHABLE_REQUIREMENTS
Xcode downloaded a crash report for my app that crashed when trying to insert a String into a Set<String>. Apparently there was an assertion failure ELEMENT_TYPE_OF_SET_VIOLATES_HASHABLE_REQUIREMENTS. I assume that this assertion failure happened because the hash of the new element didn't match the hash of an equal already inserted element, but regardless, I don't understand how inserting a simple string could trigger this assertion. Here is essentially the code that leads to the crash. path is any file system directory, and basePath is a directory higher in the hierarchy, or path itself. var scanErrorPaths = Set<String>() func main() { let path = "/path/to/directory" let basePath = "/path" let fileDescriptor = open(path, O_RDONLY) if fileDescriptor < 0 { if (try? URL(fileURLWithPath: path, isDirectory: false).checkResourceIsReachable()) == true { scanErrorPaths.insert(path.relativePath(from: basePath)!) return } } extension String { func relativePath(from basePath: String) -> String? { if basePath == "" { return self } guard let index = range(of: basePath, options: .anchored)?.upperBound else { return nil } return if index == endIndex || basePath == "/" { String(self[index...]) } else if let index = self[index...].range(of: "/", options: .anchored)?.upperBound { String(self[index...]) } else { nil } } } crash.crash
Replies
7
Boosts
0
Views
947
Activity
Oct ’25
Link shared library with Swift
I have a s hared library in C++ that was built with GNU Libtool, and I want to bundle it with my Swift app and call it from the app. How can I bundle it and call it?
Replies
9
Boosts
0
Views
349
Activity
Jun ’25
What is the future of Objective-C?
Will Apple continue to support it, or will we wake up one day to find that Swift is the only viable language?It's a serious question. Careers depend on it. I don't accept the "No comment" approach that Apple usually takes. It's cruel.I'm willing to put the time into learning Swift if I have to. I'm not going to do it if I don't. I want to know.Frank
Replies
23
Boosts
1
Views
34k
Activity
Oct ’25
Crash with Progress type, Swift 6, iOS 18
We are getting a crash _dispatch_assert_queue_fail when the cancellationHandler on NSProgress is called. We do not see this with iOS 17.x, only on iOS 18. We are building in Swift 6 language mode and do not have any compiler warnings. We have a type whose init looks something like this: init( request: URLRequest, destinationURL: URL, session: URLSession ) { progress = Progress() progress.kind = .file progress.fileOperationKind = .downloading progress.fileURL = destinationURL progress.pausingHandler = { [weak self] in self?.setIsPaused(true) } progress.resumingHandler = { [weak self] in self?.setIsPaused(false) } progress.cancellationHandler = { [weak self] in self?.cancel() } When the progress is cancelled, and the cancellation handler is invoked. We get the crash. The crash is not reproducible 100% of the time, but it happens significantly often. Especially after cleaning and rebuilding and running our tests. * thread #4, queue = 'com.apple.root.default-qos', stop reason = EXC_BREAKPOINT (code=1, subcode=0x18017b0e8) * frame #0: 0x000000018017b0e8 libdispatch.dylib`_dispatch_assert_queue_fail + 116 frame #1: 0x000000018017b074 libdispatch.dylib`dispatch_assert_queue + 188 frame #2: 0x00000002444c63e0 libswift_Concurrency.dylib`swift_task_isCurrentExecutorImpl(swift::SerialExecutorRef) + 284 frame #3: 0x000000010b80bd84 MyTests`closure #3 in MyController.init() at MyController.swift:0 frame #4: 0x000000010b80bb04 MyTests`thunk for @escaping @callee_guaranteed @Sendable () -&gt; () at &lt;compiler-generated&gt;:0 frame #5: 0x00000001810276b0 Foundation`__20-[NSProgress cancel]_block_invoke_3 + 28 frame #6: 0x00000001801774ec libdispatch.dylib`_dispatch_call_block_and_release + 24 frame #7: 0x0000000180178de0 libdispatch.dylib`_dispatch_client_callout + 16 frame #8: 0x000000018018b7dc libdispatch.dylib`_dispatch_root_queue_drain + 1072 frame #9: 0x000000018018bf60 libdispatch.dylib`_dispatch_worker_thread2 + 232 frame #10: 0x00000001012a77d8 libsystem_pthread.dylib`_pthread_wqthread + 224 Any thoughts on why this is crashing and what we can do to work-around it? I have not been able to extract our code into a simple reproducible case yet. And I mostly see it when running our code in a testing environment (XCTest). Although I have been able to reproduce it running an app a few times, it's just less common.
Replies
24
Boosts
7
Views
3.1k
Activity
Apr ’25