Hey @Douglas_Gregor, it's been almost a week since your message about the possibility of an Xcode bugfix release - could we please get an update on that?
FYI - I think it's incredibly unlikely that Douglas will be able or allowed to speak to any timeframes in terms of Xcode releases, and recognize that WWDC is about 3 weeks away: so I'd expect that even with the swift team's they're all-hands-on-deck for stabilization, lock-down, and bugfixes for the variety of topics that are historically released at a WWDC.
I think a reasonable expectation is that you won't hear anything until at least WWDC at this point.
I know the usual spiel about not being able to comment on future anything. Yet the post I was replying to was already kind of in that territory, so I'd say there's no harm in asking.
Based on dates from https://xcodereleases.com, it took between 4 days (13.2 -> 13.2.1) and a month (13.3 -> 13.3.1) to release Xcode 13 and 14 patch releases. Here we went two weeks from the first post to the issue being acknowledged. Doug's fix was merged the following day. I suppose it might not be seen as a high enough priority given that it is limited to a subset of older iOS versions, but people still use them. I'm not even asking for the fix to be released ASAP, just for information about whether we should be expecting it or not, because that difference could easily be measured in months, given, as you point out, how close WWDC is. Doug wrote it is being considered, which kind of left us hanging.
It's true that I missed the part about the toolchain and especially the edit with the link, though there I'm in the same boat as @august. Doug wrote:
All you really need from it are the
libswiftCompatibility56.a
files, where the bug fix is
I've never downloaded or used a custom toolchain, but I do know you can't use them to deploy to the App Store, so this doesn't help with that
Another follow-up on this, I'm seeing a similar crash to this on later versions of iOS 15 (I see 15.5 and 15.6.1) - presumably this must be a different issue as it isn't in the range affected but I wonder if there could be another similar bug to this out there.
This one is a bit more specific, in that it is crashing in LPMetadataProvider
which is part of the LinkPresentation framework, but it still seems to be related to libDispatch. Example stack trace:
EXC_BAD_ACCESS
image >
Attempted to dereference garbage pointer 0x210.
libdispatch
+0x0e54c
_dispatch_lane_push
System
LinkPresentation
+0x57748
fitImageInSize
System
LinkPresentation
+0x75a84
__80-[LPMetadataProvider _internalPostProcessResolvedMetadataWithCompletionHandler:]_block_invoke
System
LinkPresentation
+0x75844
-[LPMetadataProvider _internalPostProcessResolvedMetadataWithCompletionHandler:]
System
LinkPresentation
+0x7555c
__72-[LPMetadataProvider _postProcessResolvedMetadataWithCompletionHandler:]_block_invoke
System
libdispatch
+0x01e68
_dispatch_call_block_and_release
System
libdispatch
+0x03a2c
_dispatch_client_callout
System
libdispatch
+0x06ee8
_dispatch_continuation_pop
System
libdispatch
+0x065ec
_dispatch_async_redirect_invoke
System
libdispatch
+0x15160
_dispatch_root_queue_drain
System
libdispatch
+0x15968
_dispatch_worker_thread2
System
libsystem_pthread
+0x0107c
_pthread_wqthread
We are using the automatic completion handler to async API bridging so this does seem like another potential concurrency bug.
Filed a feedback: FB12188979
Must admit I was very confused - I've never come across [x, y)
syntax before.
I'll admit I thought it was a typo, and that it meant [15.0, 15.2] (but not 15.1...)
Yeah, I figured a lot of people wouldn't have seen it.
The most common notation used by mathematicians uses [a,b] to indicate a closed interval (points a and b are contained in the interval, (a,b) for an open interval (a and b are not included), and a mix of parentheses and square brackets for a half-open interval: [a,b) means it includes a but not b and (a,b] includes b but not a.
There's an Xcode 14.3.1 RC out. The release notes have (of course) not been updated yet, but I assume it ships the fix for this bug and perhaps others.
Release notes are up, this is one of the issues fixed.
Just circling back to this memory watchdog termination issue, I looked back through our logs and discovered:
- All of the watchdog termination errors for the latest release of our app which was built with Xcode 14.3 are on iOS 15, 15.1 and 15.1.1 - I donāt think itās a coincidence that this correlates with the concurrency bug affected versions.
- Any watchdog termination errors for higher iOS versions are actually from versions of our app that pre-date this bug and are therefore not relevant and are likely due to some genuine memory leak bugs in older versions of our app.
The vast majority of these crashes are of the first type coming from the latest version of our app so it does look like this was another side effect of this bug. We have just shipped a new update built with 14.3.1 but as we didnāt know when this fix would ship we took the decision to bump our minimum supported iOS version to 15.2 anyway.
Hey Dough, did a fast test with a new beta and there are no more crashes on the simulator. Wait for a release to do a real test. Thanks
Hi,
thanks a lot for the quick fix but ...
we still have a new crash, on iOS 16.0.0 and iPadOS 16.0.0 only apparently.
Are you aware of this issue ? Same reason, root cause ?
Crashed: com.apple.main-thread
0 libswiftCore.dylib 0x3d6648 swift_task_exitThreadLocalContext + 52
1 XXX 0x17e0c40 swift::AsyncTask::waitFuture(swift::AsyncTask*, swift::AsyncContext*, void (swift::AsyncContext* swift_async_context) swiftasynccall*, swift::AsyncContext*, swift::OpaqueValue*) + 231988
2 XXX 0x17e0e90 swift::swift56override_swift_task_future_wait_throwing(swift::OpaqueValue*, swift::AsyncContext*, swift::AsyncTask*, void (swift::AsyncContext* swift_async_context, void* swift_context) swiftasynccall*, swift::AsyncContext*, void (swift::OpaqueValue*, swift::AsyncContext* swift_async_context, swift::AsyncTask*, void* swift_context, swift::AsyncContext*) swiftasynccall*) + 232580
3 libswift_Concurrency.dylib 0x41e9c swift::runJobInEstablishedExecutorContext(swift::Job*) + 420
4 libswift_Concurrency.dylib 0x42da8 swift_job_runImpl(swift::Job*, swift::ExecutorRef) + 72
5 libdispatch.dylib 0x12800 _dispatch_main_queue_drain + 756
6 libdispatch.dylib 0x124fc _dispatch_main_queue_callback_4CF + 44
7 CoreFoundation 0x5097c CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 16
8 CoreFoundation 0xb4d0 __CFRunLoopRun + 2036
9 CoreFoundation 0x1ebac CFRunLoopRunSpecific + 612
10 GraphicsServices 0x1360 GSEventRunModal + 164
11 UIKitCore 0x40aa34 -[UIApplication _run] + 888
12 UIKitCore 0x210e04 UIApplicationMain + 340
We also experience some crashes after upgrading to Xcode 14.3.1 on iOS 16.0
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000010
Crashed: com.apple.root.user-initiated-qos.cooperative
0 libswiftCore.dylib 0x3d6648 swift_task_exitThreadLocalContext + 52
1 Production 0x13194 swift::AsyncTask::waitFuture(swift::AsyncTask*, swift::AsyncContext*, void (swift::AsyncContext* swift_async_context) swiftasynccall*, swift::AsyncContext*, swift::OpaqueValue*) + 41892
2 Production 0x133e4 swift::swift56override_swift_task_future_wait_throwing(swift::OpaqueValue*, swift::AsyncContext*, swift::AsyncTask*, void (swift::AsyncContext* swift_async_context, void* swift_context) swiftasynccall*, swift::AsyncContext*, void (swift::OpaqueValue*, swift::AsyncContext* swift_async_context, swift::AsyncTask*, void* swift_context, swift::AsyncContext*) swiftasynccall*) + 42484
3 libswift_Concurrency.dylib 0x41e9c swift::runJobInEstablishedExecutorContext(swift::Job*) + 420
4 libswift_Concurrency.dylib 0x42da8 swift_job_runImpl(swift::Job*, swift::ExecutorRef) + 72
5 libdispatch.dylib 0x15b24 _dispatch_root_queue_drain + 396
6 libdispatch.dylib 0x16330 _dispatch_worker_thread2 + 164
7 libsystem_pthread.dylib 0xdbc _pthread_wqthread + 228
8 libsystem_pthread.dylib 0xb98 start_wqthread + 8
@agergely @StephaneG Same error. Did you solve it?
Hi! Crashing on iOS 16.0.0 only.
Why is this happening and how can I fix it?
Crashed: com.apple.root.default-qos.cooperative
0 libswiftCore.dylib 0x3d6648 swift_task_exitThreadLocalContext + 52
1 {app_name} 0xd16b7c swift::AsyncTask::waitFuture(swift::AsyncTask*, swift::AsyncContext*, void (swift::AsyncContext* swift_async_context) swiftasynccall*, swift::AsyncContext*, swift::OpaqueValue*) + 358 (TaskPrivate.h:358)
2 {app_name} 0xd281b4 swift::swift56override_swift_task_future_wait_throwing(swift::OpaqueValue*, swift::AsyncContext*, swift::AsyncTask*, void (swift::AsyncContext* swift_async_context, void* swift_context) swiftasynccall*, swift::AsyncContext*, void (swift::OpaqueValue*, swift::AsyncContext* swift_async_context, swift::AsyncTask*, void* swift_context, swift::AsyncContext*) swiftasynccall*) + 220 (Task.cpp:220)
3 libswift_Concurrency.dylib 0x41e9c swift::runJobInEstablishedExecutorContext(swift::Job*) + 420
4 libswift_Concurrency.dylib 0x42da8 swift_job_runImpl(swift::Job*, swift::ExecutorRef) + 72
5 libdispatch.dylib 0x15b24 _dispatch_root_queue_drain + 396
6 libdispatch.dylib 0x16330 _dispatch_worker_thread2 + 164
7 libsystem_pthread.dylib 0xdbc _pthread_wqthread + 228
8 libsystem_pthread.dylib 0xb98 start_wqthread + 8
Unfortunately the answer is no, as this crash was occurring in specific code added for Third party product evaluation only, we have decided to exclude 16.0 from our test. the volume of 16.0 was not very significant around 100k on our side, but noisy and crashy.
Are you able to reproduce the crash locally? If so, what is this awaiting when it crashes? Is it an actor hop, an async-let, a detached task? I havenāt been able to reproduce it locally so Iām not sure what is causing it.
I can't reproduce it locally either :(
If you have a link to an app or some way for me to get to the actual executable binary that is failing, that would be helpful.