4 Replies
      Latest reply on Oct 28, 2019 8:51 PM by JoeyBlue_
      JoeyBlue_ Level 1 Level 1 (0 points)

        Our user reported lately that their devices were rebooted automatically after using our app for more than 2 hours , at the beginnig I cannot , I never seen an app will make the iOS system get rebooted, until our user send me a video prove it what they said is true.


        And after that I asked them for the panic-full logs in their devices which indicate the device was rebooted unusually, the log shows that it's exactly our app's process leads to the reboot, OMG, I got shocked...


        Our app is a live broadcasting app, most of our users encountered the reboot problem are when they finished broadcasting a live for a long time (maybe more than 2 hours) and close the room button, another infomation is that we add WebRTC.framework to our app lately, Our user's devices and system version vary, so maybe there is no relation with these factors.


        I reproduce this problem once on my iPhone 7P (I boradcasted for 2 hours, my phone rebooted exactly after I clicked the close button of my live room), and the panic log in my phone is very similar with logs from our users. Here is part of my log, I put the full on pastebin: https://pastebin.com/Hh9TqZgh


            "build":"iPhone OS 12.3.1 (16F203)",
            "kernel":"Darwin Kernel Version 18.6.0: Thu Apr 25 22:14:06 PDT 2019; root:xnu-4903.262.2~2/RELEASE_ARM64_T8010",
            "date":"2019-10-09 14:03:49.04 +0800",
            "panicString":"panic(cpu 0 caller 0xfffffff021e53bd0): Kernel data abort. (saved state: 0xffffffe050fbaf80)   x0: 0x0000000000000000  x1:  0x000f076700041104  x2:  0xfffffffffffffffb  x3:  0xffffffe04a4be81b   x4: 0x0000000000000000  x5:  0x0000000000000020  x6:  0x0000000000000000  x7:  0xfffffff0221fc940   x8: 0x139a6525663e0012  x9:  0x139a6525663e0012  x10: 0x0000000000000000  x11: 0x0200000010000860   x12: 0x0000000000000000 x13: 0x3a3a79726f6d654d  x14: 0x656e72654b746567  x15: 0x002928617461446c   x16: 0xfffffff021cb2df7 x17: 0x0000000000000020  x18: 0xfffffff021d31000  x19: 0xffffffe006609000   x20: 0xffffffe007192880 x21: 0x0000000281f9e760  x22: 0x0000000008600000  x23: 0x0000000000000006   x24: 0x000000000000000c x25: 0xffffffe0070b4600  x26: 0x0000000085020080  x27: 0x0000000000000018   x28: 0x0000000000000000 fp:  0xffffffe050fbb350  lr:  0xfffffff020f9ed74  sp:  0xffffffe050fbb2d0   pc:  0xfffffff020f9ed74 cpsr: 0x60400304         esr: 0x96000006          far: 0x0000000000000000 Debugger message: panic Memory ID: 0x1 OS version: 16F203 Kernel version: Darwin Kernel Version 18.6.0: Thu Apr 25 22:14:06 PDT 2019; root:xnu-4903.262.2~2/RELEASE_ARM64_T8010 KernelCache UUID: 2AEBFD081F36C4C81402573F19F4DEE7 Kernel UUID: 897227C4-A9D9-3E80-AA04-C1C2029A8430 iBoot version: iBoot-4513.260.81 secure boot?: YES Paniclog version: 12 Kernel slide:     0x000000001ac54000 Kernel text base: 0xfffffff021c58000 Epoch Time:        sec       usec   Boot    : 0x5d9c64c8 0x000468bc   Sleep   : 0x5d9d3a6c 0x000d0471   Wake    : 0x5d9d3aa5 0x00014f47   Calendar: 0x5d9d7819 0x0007c4af Panicked task 0xffffffe00634f2a0: 43873 pages, 21 threads: pid 339: EXXXLXXX Panicked thread: 0xffffffe001324000, backtrace: 0xffffffe050fba710, tid: 121839   lr: 0xfffffff021d661c4  fp: 0xffffffe050fba7a0   lr: 0xfffffff021e54538  fp: 0xffffffe050fba8e0   lr: 0xfffffff021d31610  fp: 0xffffffe050fba8f0   lr: 0xfffffff021d65768  fp: 0xffffffe050fbac60   lr: 0xfffffff021d65ae0  fp: 0xffffffe050fbaca0   lr: 0xfffffff021d65934  fp: 0xffffffe050fbacc0   lr: 0xfffffff021e53bd0  fp: 0xffffffe050fbae20   lr: 0xfffffff021e54c5c  fp: 0xffffffe050fbaf60   lr: 0xfffffff021d31610  fp: 0xffffffe050fbaf70   lr: 0xfffffff020f9ed74  fp: 0xffffffe050fbb350   lr: 0xfffffff020f9d590  fp: 0xffffffe050fbb3a0   lr: 0xfffffff020f9d39c  fp: 0xffffffe050fbb410   lr: 0xfffffff020f9c5f0  fp: 0xffffffe050fbb470   lr: 0xfffffff022217ee0  fp: 0xffffffe050fbb580   lr: 0xfffffff02221f8d4  fp: 0xffffffe050fbb710   lr: 0xfffffff021e2b128  fp: 0xffffffe050fbb820   lr: 0xfffffff021d49c90  fp: 0xffffffe050fbb9b0   lr: 0xfffffff021d5c17c  fp: 0xffffffe050fbbb40   lr: 0xfffffff021e54d28  fp: 0xffffffe050fbbc80   lr: 0xfffffff021d31610  fp: 0xffffffe050fbbc90   lr: 0x00000001a343b0f4  fp: 0x0000000000000000 ",
            "otherString":" ** Stackshot Succeeded ** Bytes Traced 357072 ** ",


        I have no idea about what to do next to resolve this problem, any suggestions will help, thanks!


        • Re: iOS system panic, panic string Kernel data abort
          eskimo Apple Staff Apple Staff (12,435 points)

          Kernel panics are always bugworthy.  You should file a bug with whatever helpful info you have.  At a minimum, include the panic log you have, but it’d be great if you could also include:

          • Steps to reproduce

          • A sysdiagnose log taken immediately after the panic caused a reboot

          Please post your bug number, just for the record.

          Looking at your panic log with internal tools, it looks like this is being triggered by the graphics accelleration subsystem.  In my experience this is one of the most common causes of app-triggered panics.  If you were using a low-level API like Metal directly, it’s possible that you might eb able to tiptoe around whatever causes this panic.  However, if you’re using high-level APIs (I’m not familiar with the WebRFC framework, but it seems likely it’d be based on AVFoundation rather than Metal directly), your options are rather limited.

          Share and Enjoy

          Quinn “The Eskimo!”
          Apple Developer Relations, Developer Technical Support, Core OS/Hardware
          let myEmail = "eskimo" + "1" + "@apple.com"

            • Re: iOS system panic, panic string Kernel data abort
              JoeyBlue_ Level 1 Level 1 (0 points)

              Thank you very much!


              What you say reminds me a thing, when I run my project with Xcode 11, my app will crash when I start to broadcast, and this line get output in the console, this log is also related to Metal:


              validateNewTexture:89: failed assertion `BytesPerRow of a buffer-backed texture with pixelFormat(MTLPixelFormatBGRA8Unorm) must be aligned to 64 bytes, found bytesPerRow(4976)'


              When I disbale Metal API Validation in Debug options configuration, the crash disappeared.

              I'll check where we use Metal incorrectly. Any suggestions or clues are appreciated. Thanks!

                • Re: iOS system panic, panic string Kernel data abort
                  eskimo Apple Staff Apple Staff (12,435 points)

                  Any suggestions or clues are appreciated.

                  I’m not an expert on Metal, so apologies if this is obvious but…

                  Do these Metal API validation errors show up in the Runtime tab of the issue navigator (View > Navigators > Show Issue Navigator)?  If so, that should give you a backtrace.

                  Share and Enjoy

                  Quinn “The Eskimo!”
                  Apple Developer Relations, Developer Technical Support, Core OS/Hardware
                  let myEmail = "eskimo" + "1" + "@apple.com"

                • Re: iOS system panic, panic string Kernel data abort
                  JoeyBlue_ Level 1 Level 1 (0 points)

                  I have committed a bug, bug number: FB7415440

                  (It's not easy for our users to press the buttons to generate diagnose log, so it's a few days late)