About cpu_resource_fatal

Question

ToshiyukiTakeda OP

Created 3w

Replies 1

Boosts 0

Participants 2

PLATFORM AND VERSION

iOS Development environment: Xcode 15.0, macOS 14.4.1, Objective-C

Run-time configuration: iOS 17.2.1,

DESCRIPTION OF PROBLEM

What is the general approach to analyzing cpu_resource_fatal.ips? Is there a standard way to analyze it? (Instruments are not available in this analysis, because this is only occurs on the customer's iPhone.)

Also, can this file be symbolicate?

Attachment file is a sample ips file.

FjSoftPhone.cpu_resource_fatal-2024-06-21-150321.ips

Answered by DTS Engineer in 793610022

What is the general approach to analyzing cpu_resource_fatal.ips?

In terms of how the log is structured and how it can be interpreted, my response to this thread on "wakeups" is a good summary of what's actually in the data. The cause is obviously different, but the collection method and data format are exactly the same.

Is there a standard way to analyze it?

Yes and no. Going through the process above can tell you want the stack shows, but how useful/helpful it will be is hard to predict. The reality is that the kernel is sampling a tiny portion of your overall runtime and there isn't anyway to know exactly what's "missing".

One point to make on the termination reason itself:

9 seconds cpu time over 9 seconds (100% cpu average), exceeding limit of 60% cpu over 15 second

Any responsible background app needs to keep in mind that it's operating in a shared in environment and that it needs to contrains it's activities to account for that, particularly high priority categories like "voip". The limits the system has defined should NOT be treated as the acceptable limit you can/should grow toward, but as a hard limit that your app shouldn't be getting anywhere near. A background app hitting "60% CPU over 15s" (and you hit 100%) is NOT well behaved.

The first thing you should actually look at here is what you're "normal" usage load actually looks like and how close to those thresholds you actually are. While it's likely that there are specific factors that pushed you over the limit, those factors don't really matter very much if your app regularly "hovers" at 50%+ load.

Also, can this file be symbolicate?

Sure. This is covered in detail in "Adding identifiable symbol names to a crash report", just make sure you scroll past the initial sections on xcode and get to command line symbolication.

Pulling an example from your log, here is one of the stack frames and the library load entry:

      2  ??? (FjSoftPhone + 2223612) [0x104eb2dfc]
... 
     0x104c94000 -                ???  com.fujitsu.FjSoftPhoneC 1.8.2 (2405291953) <674C4E6B-A64F-3910-A1C4-FDC3DFC8D7E1>  /private/var/containers/Bundle/Application/8950123C-ADCF-4727-BA4B-5D1746A4FA29/FjSoftPhone.app/FjSoftPhone

The atos command line format is:

% atos -arch arm64 -o <symbol file path> -l <library load address> <execution address>

Which would make the frame above:

% atos -arch arm64 -o <symbol file path> -l 0x104c94000 0x104eb2dfc

or (if atos wants a 64 bit execution address)

% atos -arch arm64 -o <symbol file path> -l 0x104c94000 0x0000000104eb2dfc

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Boost

Answer 1

DTS Engineer OP

Apple

2w

Recommended

What is the general approach to analyzing cpu_resource_fatal.ips?

In terms of how the log is structured and how it can be interpreted, my response to this thread on "wakeups" is a good summary of what's actually in the data. The cause is obviously different, but the collection method and data format are exactly the same.

Is there a standard way to analyze it?

Yes and no. Going through the process above can tell you want the stack shows, but how useful/helpful it will be is hard to predict. The reality is that the kernel is sampling a tiny portion of your overall runtime and there isn't anyway to know exactly what's "missing".

One point to make on the termination reason itself:

9 seconds cpu time over 9 seconds (100% cpu average), exceeding limit of 60% cpu over 15 second

Any responsible background app needs to keep in mind that it's operating in a shared in environment and that it needs to contrains it's activities to account for that, particularly high priority categories like "voip". The limits the system has defined should NOT be treated as the acceptable limit you can/should grow toward, but as a hard limit that your app shouldn't be getting anywhere near. A background app hitting "60% CPU over 15s" (and you hit 100%) is NOT well behaved.

The first thing you should actually look at here is what you're "normal" usage load actually looks like and how close to those thresholds you actually are. While it's likely that there are specific factors that pushed you over the limit, those factors don't really matter very much if your app regularly "hovers" at 50%+ load.

Also, can this file be symbolicate?

Sure. This is covered in detail in "Adding identifiable symbol names to a crash report", just make sure you scroll past the initial sections on xcode and get to command line symbolication.

Pulling an example from your log, here is one of the stack frames and the library load entry:

      2  ??? (FjSoftPhone + 2223612) [0x104eb2dfc]
... 
     0x104c94000 -                ???  com.fujitsu.FjSoftPhoneC 1.8.2 (2405291953) <674C4E6B-A64F-3910-A1C4-FDC3DFC8D7E1>  /private/var/containers/Bundle/Application/8950123C-ADCF-4727-BA4B-5D1746A4FA29/FjSoftPhone.app/FjSoftPhone

The atos command line format is:

% atos -arch arm64 -o <symbol file path> -l <library load address> <execution address>

Which would make the frame above:

% atos -arch arm64 -o <symbol file path> -l 0x104c94000 0x104eb2dfc

or (if atos wants a 64 bit execution address)

% atos -arch arm64 -o <symbol file path> -l 0x104c94000 0x0000000104eb2dfc

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0