Why can’t I find my crash log?

When I am working hard (paddling), there is always a colleague to come up and drop me: classmate, WHEN I open the home page crashed, you help me see why there is no crash log on the mobile phone? At this point, I always want to say WTF? Of course, I still have to say, for the case of not finding the crash log, let me slowly explain

How do I get my crash log

Under normal circumstances, we can find the matching binary file name of our APP in System Settings -> Privacy -> Analysis -> Analysis and Data (different iOS systems have different names), as shown in the picture below. When wechat crashes, the corresponding crash log file name is as follows. Click in, In the upper right corner you can share the crash log to our developer debug solved 😯. Unfortunately, you can’t always find the crash log. Here are a few cases where you can’t get a log.

!

There are no clues

  • The privacy switch for sharing iPhone analytics and sharing with app developers was not turned on. You don’t even agree. Find the yarn! Find it!

  • The same APP crashed more than 25 times that day (the threshold may vary from system to system, but the author has generally encountered 25 times so far). At this time you can connect your iPhone device to the computer, open the console application, crash when there will be a crash limit prompt 😯.

  • After the APP release certificate expires, a startup crash occurs and no logs are logged. This includes but is not limited to the expiration of TF version and the expiration of APP certificate installed by enterprise certificate. However, on iOS with a higher version, the expiration of certificate will be prompted when you click open APP. The following figure is the log captured by me in the console background after the TF version of Tieba expired.

  • Keep the background alive over 30 seconds; Typically iOS applications use apis when they perform background tasksUIApplication.beginBackgroundTask(expirationHander)withUIApplication.endBackgroundTask(_:)To perform background tasks, but if you do not finish your background tasks within 30 seconds, your APP will quietly Say Bye to you 😯.

There’s a clue

  • OOM crashes. When the memory usage of the application exceeds the threshold, Apple’s Jestems mechanism will take effect (the threshold of foreground and background is different, but both trigger). Normally you can find JetsamEvent logs in System Settings -> Privacy -> Analysis -> Analysis & Data, as shown below

  • Crashes caused by various system resource limits
    • A crash caused by threads switching too much in a short period of time
    • A crash caused by CPU overload for a long time
    • IO (Disk write operation) Crash caused by too much write in a certain period of time
    • Fence-hang: a crash added by apple after iOS14, no more info yet.

Crashes that some SDKS on the market cannot catch

  • SIGKILL collapse

    • 0x8BadF00D: The Watch Dog crashes
    • 0xC00010FF: The device is overheated
    • 0 xdead10cc: deadlocks
    • 0 xbaadca11: The operating system terminated the app for failing to report a CallKit call in response to a PushKit notification.
    • 0xBAD22222: Voip function is called too frequently
    • 0xC51BAD01: watchOS CPU usage is too high
    • 0 xc51bad02: watchOS terminated the app because it failed to complete a background task within the allocated time. Decrease the amount of work that the app performs while running in the background to resolve this crash.
    • 0xc51bad03:watchOS terminated the app because it failed to complete a background task within the allocated time, but the system was sufficiently busy overall that the app may not have received much CPU time to perform the background task. Although you may be able to avoid the issue by reducing the amount of work your app performs in background tasks, 0xc51bad03 doesn’t indicate that the app did anything wrong. More likely, the app wasn’t able to complete its work because of overall system load.

  • SIGQUIT: Generally, the priority of other processes is higher than that of the current process. It’s not usually considered a crash

  • EXC_GUARD: Crash caused by illegal operations on some protective files

    • CLOSE. The process attempted to invoke close() on a guarded file descriptor.
    • DUP. The process attempted to invoke dup(), dup2(), or fcntl() with the F_DUPFD or F_DUPFD_CLOEXEC commands on a guarded file descriptor.
    • NOCLOEXEC. The process attempted to remove the FD_CLOEXEC flag from a guarded file descriptor.
    • SOCKET_IPC. The process attempted to send a guarded file descriptor through a socket.
    • FILEPORT. The process attempted to obtain a Mach send right for a guarded file descriptor.
    • WRITE. The process attempted to write to a guarded file descriptor.

  • Stack overflow: Stack overflow

    • Requesting too much memory on the stack

      A stack overflow occurs when the data we define consumes more memory than the size of the stack.

    • Recursively call the function multiple times

      A function call itself is called recursion. When the level of recursion is too high, a stack overflow occurs in the program.

The resources

  • Understanding the Exception Types in a Crash Report