What Condition Can Cause System Reboot

Hello, everyone, I'm facing a weird problem. Does anyone know what kind of problem can trigger a system reboot?


Summary:

Our App uses a custom video player.

When playing some special video and seeking the progress frequently, iPhone 8, iPhone 8 plus and iPhone X will reboot suddenly.


Steps to Reproduce:

1.Using our video player to play some special online video, like the link given below.

http://mvvideo2.meitudata.com/590c07c3578517383.mp4?k=131ded4907914fd730fe05bde95da2ad&t=5a253dcd


2.Keep seeking the progress of the video.


Expected Results:

The video just plays normally.


Actual Results:

The iPhone reboots after a while, with a log containing a few lines.


Version/Build:

iOS 11 +

iPhone 8, 8 plus, X


What I want to ask is, what is the condition that can trigger system rebooting?

TIA

Replies

Can you detail the iOS versions in play, exactly, thanks.

What I want to ask is, what is the condition that can trigger system rebooting?

On iOS the system will automatically reboot if the kernel panics, which seems like the most likely cause of the problem you’re seeing.

Kernel panics are always bugworthy. It sounds like this panic is relatively easy to reproduce, and such bug reports are especially useful. Please do file a bug report about this, and post your bug number, just for the record.

Besides, we've got two log file after the devices rebooted.

The second log is interesting because it actually contains a traditional kernel panic log. I undid the JSON encoding and pasted the resulting log in at the end of this post.

I’m not familiar with this panic myself but the main message, “mbuf_watchdog: 8 waiters stuck for 10 secs”, is relatively easy to understand. In the context of the kernel, an

mbuf
is a memory buffer used by the networking subsystem. It seems that something has run the kernel out of these buffers, to the point where 8 threads have been waiting for memory buffers for 10 seconds. This is clearly too long, and so a watchdog has panicked the system.

The underlying cause of this could be a leak in the kernel, or there could be a bug that’s causing the kernel to over commit to work coming in from user space. Regardless, kernel panics are most definitely Apple’s problem to resolve.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"
panic(cpu 1 caller 0xfffffff01b276c90): mbuf_watchdog: 8 waiters stuck for 10 secs
2432/2432 mbufs in use:
    2432 mbufs allocated to data
820/832 mbuf 2KB clusters in use
168/168 mbuf 4KB clusters in use
1366/1366 mbuf 16KB clusters in use
25141 KB allocated to network (approx. 99% in use)
0 KB returned to the system
VM allocation failures: contiguous 0, normal 0, one page 0
worker thread runs: 99, expansions: 0, cl 7/2506, bigcl 0/0, 16k 91/1951
worker thread last run time: 118 (11 seconds ago)

mbuf leak detection table:
    total captured: 323 (one per 500)
    total allocs outstanding: 12
    new hash recorded: 257 allocs, 234 traces
    hash collisions: 4 allocs, 54 traces
    overwrites: 76 allocs, 0 traces
    lock conflicts: 0

top 5 outstanding traces:
[1] 5 outstanding alloc(s), 63 hit(s), 53 collision(s)
[2] 1 outstanding alloc(s), 1 hit(s), 0 collision(s)
[3] 1 outstanding alloc(s), 2 hit(s), 0 collision(s)
[4] 1 outstanding alloc(s), 1 hit(s), 0 collision(s)
[5] 1 outstanding alloc(s), 1 hit(s), 0 collision(s)

    trace [1]           trace [2]           trace [3]               trace [4]           trace [5]      
    ------------------  ------------------  ------------------      ------------------  ------------------ 
 1: 0xfffffff007475338  0xfffffff007475338  0xfffffff007475338  0xfffffff007475338  0xfffffff007475338  
 2: 0xfffffff0074509ac  0xfffffff0074509ac  0xfffffff0074508d0  0xfffffff0074509ac  0xfffffff0074509ac  
 3: 0xfffffff007473a5c  0xfffffff00747863c  0xfffffff00747b5d0  0xfffffff007473a5c  0xfffffff007473a5c  
 4: 0xfffffff007450658  0xfffffff00730b6d4  0xfffffff00744a448  0xfffffff007450658  0xfffffff007450658  
 5: 0xfffffff00747a5c4  0xfffffff00746e9a0  0xfffffff006c7ae54  0xfffffff00747a5c4  0xfffffff00747b5d0  
 6: 0xfffffff007484e98  0xfffffff007321a98  0xfffffff006c7ac14  0xfffffff007484ef0  0xfffffff00744a448  
 7: 0xfffffff00745b974  0xfffffff00746e208  0xfffffff006c84210  0xfffffff00745b974  0xfffffff006c7ae54  
 8: 0xfffffff007454490  0xfffffff0073efde0  0xfffffff006c83ef4  0xfffffff007454490  0xfffffff006c7ac14  
 9: 0xfffffff00745429c  0xfffffff00711dc98  0xfffffff00755e3c0  0xfffffff00745429c  0xfffffff006c84210  
10: 0xfffffff0071e5344                      0xfffffff00755dcf4  0xfffffff0071e5344  0xfffffff006c83ef4  
11: 0xfffffff0070cc1e0                                          0xfffffff0070cc1e0  0xfffffff00755e3c0  
12:                                                                                 0xfffffff00755dcf4  
13:                                                                                                     
14:                                                                                                     
15:                                                                                                     
16:                                                                                                     

Debugger message: panic
Memory ID: 0x6
OS version: 15B93
Kernel version: Darwin Kernel Version 17.2.0: Fri Sep 29 18:14:51 PDT 2017; root:xnu-4570.20.62~4/RELEASE_ARM64_T8015
KernelCache UUID: FCA87F3FF353542AC8D28C3CC0E066DC
iBoot version: iBoot-4076.20.48
secure boot?: YES
Paniclog version: 8
Kernel slide:     0x0000000013e00000
Kernel text base: 0xfffffff01ae04000
Epoch Time:        sec       usec
  Boot    : 0x5a1d0932 0x0001bc4b
  Sleep   : 0x00000000 0x00000000
  Wake    : 0x00000000 0x00000000
  Calendar: 0x5a1d09aa 0x0008fdd2

Panicked task 0xffffffe00078b610: 15244 pages, 263 threads: pid 0: kernel_task
Panicked thread: 0xffffffe000bb8a40, backtrace: 0xffffffe0e6f7ae20, tid: 643
          lr: 0xfffffff01afe4d94  fp: 0xffffffe0e6f7af60
          lr: 0xfffffff01aecc1e0  fp: 0xffffffe0e6f7af70
          lr: 0xfffffff01aefa78c  fp: 0xffffffe0e6f7b2e0
          lr: 0xfffffff01aefaa9c  fp: 0xffffffe0e6f7b320
          lr: 0xfffffff01aefa93c  fp: 0xffffffe0e6f7b340
          lr: 0xfffffff01b276c90  fp: 0xffffffe0e6f7b530
          lr: 0xfffffff01b274230  fp: 0xffffffe0e6f7b600
          lr: 0xfffffff01b250658  fp: 0xffffffe0e6f7b6b0
          lr: 0xfffffff01b2739dc  fp: 0xffffffe0e6f7b780
          lr: 0xfffffff01b250658  fp: 0xffffffe0e6f7b830
          lr: 0xfffffff01b27b5d0  fp: 0xffffffe0e6f7b910
          lr: 0xfffffff01b24a448  fp: 0xffffffe0e6f7b940
          lr: 0xfffffff019f50f54  fp: 0xffffffe0e6f7b9a0
          lr: 0xfffffff01aa8aa94  fp: 0xffffffe0e6f7ba10
          lr: 0xfffffff01aa8a97c  fp: 0xffffffe0e6f7baa0
          lr: 0xfffffff01b360f34  fp: 0xffffffe0e6f7bb10
          lr: 0xfffffff01a1b8f54  fp: 0xffffffe0e6f7bb30
          lr: 0xfffffff01a6729d4  fp: 0xffffffe0e6f7bb90
          lr: 0xfffffff01a6723ac  fp: 0xffffffe0e6f7bbf0
          lr: 0xfffffff01b35f8f4  fp: 0xffffffe0e6f7bc30
          lr: 0xfffffff01b35e3c0  fp: 0xffffffe0e6f7bc60
          lr: 0xfffffff01b35dcf4  fp: 0xffffffe0e6f7bc90
          lr: 0xfffffff01aed4600  fp: 0x0000000000000000

Thank you so much, Eskimo!


I filed a bug report four days ago. The report number is 35714054.


We hope this problem could be solve as soon as possible.😉 May I ask how long will it take to solve this kind of problem? And could you notify me after the problem is solved, please?

Finally, Shall we submit a Technical Support Incident after filing a bug report?


Thank you in advance.

I filed a bug report four days ago. The report number is 35714054.

Thanks for that.

May I ask how long will it take to solve this kind of problem?

You can ask but I don’t have an answer for you. Kernel panics are a serious problem and usually get a relatively high priority, but it’s hard to translate that simple statement into a specific schedule.

One thing you can do to improve the chances of getting this resolved is to attach a minimal project that reproduces the issue to your bug report. Reproducible test cases are like gold in this context. Moreover the act of distilling this down to a minimal test project may help you find an acceptable workaround.

And could you notify me after the problem is solved, please?

I can’t help you with that personally, but in general the bug folks will email you when a problem is resolved (specifically, when we start seeding a release that includes the proposed fix). You can also monitor the high-level status of your issue via Apple Bug Reporter.

Finally, Shall we submit a Technical Support Incident after filing a bug report?

That’s really up to you. However, just to set expectations:

  • DTS isn’t able to help you boost the priority of your bug; iOS Engineering has a bunch of competing demands on their time and they set their own priorities when it comes to issues like this.

  • We might be able to help you find a workaround, but even that would be challenging. There’s clearly no direct workaround available here (the problem, lack of mbufs, is far too removed from the symptoms).

  • There might be an indirect workaround — that is, tweak your code until it stops triggering the panic — but you’re just as likely to uncover that as we are.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"