Crashes in ImageCaptureCore framework

Developer Tools & Services Xcode
bims OP
Created Sep ’23
Replies 6
Boosts 0
Views 1.2k
Participants 3

Hello there :)

We have an iOS/iPadOS app that uses the ImageCaptureCore framework for PTP communication with cameras. In general, it is working just fine.

But in "Xcode > Organizer > ’our app’ > Crashes" we get a good amount of different – yet similar – crashes in this framework. So we can just observe that a good amount of end-users get those crashes. But we are not able to reproduce them ourselves...

I've checked the stack traces of the other threads but nothing suspicious got my attention.

Any good idea of how to address these crashes shown below?

Happens on iOS 15–17.

Thanks!

Answered by DTS Engineer in 766022022

Thanks for the crash reports.

I ran these through an internal system and AFAIK these crashes are very specific to your app. That suggests one of two things:

  • There’s a bug in your code that’s causing this.

  • There’s a very obscure bug in the system that only your app manages to trigger.

In situation like this I normally favour the first option, but the API you’re using is fairly obscure.

The other thing about the crash reports is that they all suggest a memory management issue. A typical backtrace looks like this:

Thread 51 name:
Thread 51 Crashed:
0  libobjc.A.dylib         … objc_msgSend + 8 (:-1)
1  ImageCaptureCore        … __47-[ICCameraDevice remoteCameraWithFailureBlock:]_block_invoke + 188 (ICCameraDe…
2  Foundation              … __NSXPCCONNECTION_IS_CALLING_OUT_TO_ERROR_BLOCK__ + 24 (NSXPCConnection.m:217)
3  Foundation              … __88-[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:w…
4  libxpc.dylib            … _xpc_connection_reply_callout + 124 (serializer.c:119)
5  libxpc.dylib            … _xpc_connection_call_reply_async + 88 (connection.c:891)
6  libdispatch.dylib       … _dispatch_client_callout3 + 20 (object.m:586)
7  libdispatch.dylib       … _dispatch_mach_msg_async_reply_invoke + 344 (mach.c:3102)
8  libdispatch.dylib       … _dispatch_lane_serial_drain + 372 (queue.c:3885)
9  libdispatch.dylib       … _dispatch_lane_invoke + 436 (queue.c:3976)
10 libdispatch.dylib       … _dispatch_workloop_worker_thread + 648 (queue.c:6507)
11 libsystem_pthread.dylib … _pthread_wqthread + 288 (pthread.c:2618)
12 libsystem_pthread.dylib … start_wqthread + 8 (:-1)

Frames 12 through 6 are standard Dispatch run-a-block-on-a-queue code. Frames 5 and 4 are core XPC code, processing a reply callback. Frames 3 and 2 are the NSXPCConnection code layered on top of that. Frame 1 is a reply block within -[ICCameraDevice remoteCameraWithFailureBlock:]. Frame 0 is the Objective-C runtime crashing. The runtime is essentially bug free, which means that the only way it can crash is if it was passed a bogus object.

That doesn’t tell us where the bogus object came from, alas. In situations like this I usually prescribe a course of the standard memory debugging tools. If you’re lucky these will make the problem more reproducible, which will allow you to debug it further.

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

Replies  6
Boosts  0
Views  1.2k
Participants  3
DTS Engineer OP
Apple
Sep ’23

Please post a full Apple crash report for this, using the advice from Posting a Crash Report.

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

0
bims OP
Sep ’23

Hey Quinn and thanks million!

Wauw, I didn't even know that you could see the crash-log-files in Xcode by right-clicking and choose 'Show in Finder' 😅

(As explained we are unable to reproduce this by ourselves. So we only have crash-reports from end-users.)

Here's five from the 'remoteCameraWithFailureBlock' type...

Cheers!

  1. 2023-09-15_11-30-06.8328_-0700-2d7d19b4b44c0ea3103ecdf7cfd26b1e7ef1a6f8.crash
  2. 2023-09-15_17-26-21.4373_+0800-19859941dca81973829d2a5442f13bc22b0dfa4c.crash
  3. 2023-09-17_12-28-10.4574_+0900-780b6a777e9ebef887a60c4a98828348208a93e7.crash
  4. 2023-09-20_13-33-32.3042_+1000-1be91b2f3a0a083a3f85e788ea63beb396f1475c.crash
  5. 2023-09-13_19-02-17.9793_-0500-b0abc39ce89f7436a9be550d4046b278ca499416.crash
0
DTS Engineer OP
Apple
Sep ’23
Accepted Answer

Thanks for the crash reports.

I ran these through an internal system and AFAIK these crashes are very specific to your app. That suggests one of two things:

  • There’s a bug in your code that’s causing this.

  • There’s a very obscure bug in the system that only your app manages to trigger.

In situation like this I normally favour the first option, but the API you’re using is fairly obscure.

The other thing about the crash reports is that they all suggest a memory management issue. A typical backtrace looks like this:

Thread 51 name:
Thread 51 Crashed:
0  libobjc.A.dylib         … objc_msgSend + 8 (:-1)
1  ImageCaptureCore        … __47-[ICCameraDevice remoteCameraWithFailureBlock:]_block_invoke + 188 (ICCameraDe…
2  Foundation              … __NSXPCCONNECTION_IS_CALLING_OUT_TO_ERROR_BLOCK__ + 24 (NSXPCConnection.m:217)
3  Foundation              … __88-[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:w…
4  libxpc.dylib            … _xpc_connection_reply_callout + 124 (serializer.c:119)
5  libxpc.dylib            … _xpc_connection_call_reply_async + 88 (connection.c:891)
6  libdispatch.dylib       … _dispatch_client_callout3 + 20 (object.m:586)
7  libdispatch.dylib       … _dispatch_mach_msg_async_reply_invoke + 344 (mach.c:3102)
8  libdispatch.dylib       … _dispatch_lane_serial_drain + 372 (queue.c:3885)
9  libdispatch.dylib       … _dispatch_lane_invoke + 436 (queue.c:3976)
10 libdispatch.dylib       … _dispatch_workloop_worker_thread + 648 (queue.c:6507)
11 libsystem_pthread.dylib … _pthread_wqthread + 288 (pthread.c:2618)
12 libsystem_pthread.dylib … start_wqthread + 8 (:-1)

Frames 12 through 6 are standard Dispatch run-a-block-on-a-queue code. Frames 5 and 4 are core XPC code, processing a reply callback. Frames 3 and 2 are the NSXPCConnection code layered on top of that. Frame 1 is a reply block within -[ICCameraDevice remoteCameraWithFailureBlock:]. Frame 0 is the Objective-C runtime crashing. The runtime is essentially bug free, which means that the only way it can crash is if it was passed a bogus object.

That doesn’t tell us where the bogus object came from, alas. In situations like this I usually prescribe a course of the standard memory debugging tools. If you’re lucky these will make the problem more reproducible, which will allow you to debug it further.

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

0
IvanPN OP
Oct ’23

Hi @eskimo ,

I have the crash issue too in ImageCaptureCore framework. In our app, we executed a looping async-await process by using requestSendPTPCommand(_:outData:completion:).

The crash occurred if the application keep executed the looping async-await process in some minutes (in my case is about 15 minutes). The crash log has been obtained from the crashed device, but I have problem when I uploaded it as attachment, it keeps raise me error with message "An error occured while uploading this log. Please try again later."

So that, herewith I attach some images instead:

There is "remoteCameraWithFailureBlock" mentioned in Thread 4 block, same with @bims case.

Any help to find the cause would be very helpful and appreciated. Why the crash only happen for a while? Not explicitly reproduced in an exact event.

0
DTS Engineer OP
Apple
Oct ’23

I have problem when I uploaded it as attachment

Bummer. I’ve just updated Posting a Crash Report with some advice as to what to do in this case.

Also, honestly, I suspect that this was a transient error and, if you retry now, it’ll just work.

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

0
bims OP
Feb ’24

Hi @eskimo :)

Problem solved!

At some point I changed from using a delegate-based version of requestSendPTPCommand (ImageCaptureCore) to use block-based version. The reason for this change was to support iOS 15.0 in addition to macOS. And the delegate-based version wasn't support in iOS back then (first introduced in iOS 15.2).

But now I realized that the method was called from an C++ object and not Objective C object! (In a .m-file mixed with both C++ and Objective C classes 🥹.)

Changing it to delegate-based version where the delegate was an Objective C object made it work again smoothly :)

Thanks again for your help and time on this!

1
Crashes in ImageCaptureCore framework
First post date Last post date
 
 
Q