Task not executing at all

I have an 8th generation iPad, now updated with iPadOS 16.2 (20C65) and I have an issue that I also saw on earlier 16.* betas.

Task is not executing at all.

This is so frustrating because I have adopted async/await in my app, I support iOS 15+, everything was working fine but now that stuff inside Task { } is not executed my app seems to be broken. (Note: my main device is an iPhone 11, still on iOS 16.0, and it works fine there.)

It is also frustrating to see no other developers are complaining about this, like it happens only with my app. I have debugged with print statements and breakpoints and I can say for sure that stuff is not executing.

Does anybody have any ideas? Anything else I can try?

FB11866066

@DTS Engineer resurfacing this conversation since I didn't hear from you again since I posted my backtrace.

I pretty much assumed there was a concurrency issue in MediaPlayer's MPMediaItemArtwork and worked around it by not calling it from an async context.

Since then I have migrated a lot of my MediaPlayer code to MusicKit. I'm seeing the same issue every now and then: the cooperative threads seem to get locked. See new attached backtrace. It seems to get into the same underlying code as in the MediaPlayer scenario.

This is how I get artwork now:

let (imageData, _) = try await URLSession.shared.data(for: urlRequest)

where urlRequest points to the URL that I obtained from MusicKit's Artwork.url(width:height:) method.

Would you be able to take a look at the new backtrace to see if you can provide further insight?

Sorry I didn’t reply earlier. Your thread slipped through the cracks )-:

Thanks for the backtrace. In that backtrace I see lots of threads that look like this:

  thread #6, queue = 'com.apple.root.user-initiated-qos.cooperative'
    frame #0: 0x00000001edb75b70 libsystem_kernel.dylib`__ulock_wait + 8
    frame #1: 0x0000000103683298 libdispatch.dylib`_dlock_wait + 56
    frame #2: 0x000000010368304c libdispatch.dylib`_dispatch_thread_event_wait_slow + 56
    frame #3: 0x00000001036942d8 libdispatch.dylib`__DISPATCH_WAIT_FOR_QUEUE__ + 384
    frame #4: 0x0000000103693c10 libdispatch.dylib`_dispatch_sync_f_slow + 184
    frame #5: 0x00000001ca6cd200 MusicLibrary`-[ML3ArtworkConfiguration supportedSizesForMediaType:artworkType:…
    frame #6: 0x00000001b030a464 MediaPlayer`-[MPArtworkConfiguration supportedSizesForMediaType:artworkType:] …
    frame #7: 0x00000001b0309848 MediaPlayer`-[MPMediaLibraryArtwork validSizes] + 120
    frame #8: 0x00000001b03094ac MediaPlayer`-[MPMediaLibraryArtworkDataSource _existingRepresentationForArtwor…
    frame #9: 0x00000001b02e3364 MediaPlayer`-[MPMediaLibraryArtworkDataSource existingRepresentationForArtwork…
    frame #10: 0x00000001b02e00c0 MediaPlayer`-[MPArtworkCatalog _existingRepresentationOfKind:] + 104
    frame #11: 0x00000001b04791d0 MediaPlayer`-[MPArtworkCatalog _requestBestRepresentationOfKind:completionHan…
    frame #12: 0x00000001b047a72c MediaPlayer`-[MPArtworkCatalog requestImageWithCompletion:] + 124
    frame #13: 0x000000023434cb90 MusicKit`-[NSObject(MusicKit_SoftLinking_MPArtworkCatalog) musicKit_requestIm…
    frame #14: 0x00000002348b9c0c MusicKit`___lldb_unnamed_symbol47643 + 208
    frame #15: 0x00000002348ba38c MusicKit`___lldb_unnamed_symbol47665
    frame #16: 0x00000002344dd940 MusicKit`___lldb_unnamed_symbol27765
    frame #17: 0x00000002346e8bdc MusicKit`___lldb_unnamed_symbol36311
    frame #18: 0x00000002346e9fa8 MusicKit`___lldb_unnamed_symbol36330
    frame #19: 0x0000000234395460 MusicKit`___lldb_unnamed_symbol21900
    frame #20: 0x000000023436a9b0 MusicKit`___lldb_unnamed_symbol21218

The queue is listed as com.apple.root.user-initiated-qos.cooperative, indicating that these are Swift concurrency cooperative threads. There’s a limited pool of those threads — typically one per CPU core — and your app seem to have blocked them all in code like this.

Annoyingly, the bounce through MusicKit seems to have obscured the origin of that call. That is, there’s nothing above frame 20 showing you how you got into this situation.

It’s possible that Xcode might be able to show you more info here. If you pick one of those stuck threads and look at the backtrace in the Debug navigator, does it show you who called MusicKit?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Task not executing at all
 
 
Q