Ho appena chiesto una domanda simile ; il mio riguardava il modo in cui Apple risolverà questo problema, non necessariamente quello che fa il bug che causa il crash del telefono.
Come suggerito da @LvB, sembra essere un bug nell'elaborazione del testo di notifica SpringBoard, in cui il programma legge in modo infinito la stringa Unicode in memoria, occupando tutta la memoria disponibile. Quindi, SpringBoard genera un errore di segmentazione nel tentativo di allocare la memoria di proprietà del kernel. Sembra un riavvio "veloce" perché viene riavviato solo SpringBoard.
Apple non ha rilasciato alcun dettaglio, ma questo è il mio output da Settings/Privacy/Diagnostics & Usage/Diagnostics & Usages Data/LatestCrash.ips :
Hardware Model: iPhone4,1
Process: SpringBoard [395]
Path: /System/Library/CoreServices/SpringBoard.app/SpringBoard
Identifier: com.apple.springboard
Version: 50 (1.0)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2015-05-27 13:59:33.737 -0400
Launch Time: 2015-05-27 13:36:16.197 -0400
OS Version: iOS 8.3 (12F70)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x403c0a40
Triggered by Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 CoreText 0x28bf2264 0x28b54000 + 647780
1 CoreText 0x28bc2e64 0x28b54000 + 454244
2 CoreText 0x28bc37f8 0x28b54000 + 456696
3 CoreText 0x28b8fb9c 0x28b54000 + 244636
4 CoreText 0x28b91350 0x28b54000 + 250704
5 CoreText 0x28b64716 0x28b54000 + 67350
6 CoreText 0x28b644f6 0x28b54000 + 66806
7 CoreText 0x28b64372 0x28b54000 + 66418
8 UIFoundation 0x332561ca 0x331fb000 + 373194
9 UIFoundation 0x332585ec 0x331fb000 + 382444
10 SpringBoard 0x00320f9c 0x89000 + 2719644
11 SpringBoard 0x00321084 0x89000 + 2719876
12 SpringBoard 0x003212e0 0x89000 + 2720480
13 SpringBoard 0x002bbb6c 0x89000 + 2304876
14 SpringBoard 0x003020a8 0x89000 + 2592936
15 SpringBoard 0x00301052 0x89000 + 2588754
16 SpringBoard 0x0025d472 0x89000 + 1918066
17 SpringBoard 0x0025d374 0x89000 + 1917812
18 SpringBoard 0x0025d3e6 0x89000 + 1917926
19 SpringBoard 0x0025d724 0x89000 + 1918756
20 SpringBoard 0x0025d52a 0x89000 + 1918250
21 SpringBoard 0x0025c2ba 0x89000 + 1913530
22 CoreFoundation 0x2823b850 0x2812d000 + 1108048
23 CoreFoundation 0x28165fe8 0x2812d000 + 233448
24 libdispatch.dylib 0x36831c80 0x36830000 + 7296
25 libdispatch.dylib 0x36831c6c 0x36830000 + 7276
26 libdispatch.dylib 0x3683d54e 0x36830000 + 54606
27 CoreFoundation 0x281fc884 0x2812d000 + 850052
28 CoreFoundation 0x281fafa4 0x2812d000 + 843684
29 CoreFoundation 0x2814699c 0x2812d000 + 104860
30 CoreFoundation 0x281467ae 0x2812d000 + 104366
31 GraphicsServices 0x2f91f1a4 0x2f916000 + 37284
32 UIKit 0x2b8d1690 0x2b862000 + 456336
33 SpringBoard 0x000908b4 0x89000 + 30900
34 libdyld.dylib 0x3686faac 0x3686e000 + 6828
Questo è solo attraverso il thread 0 (quello che si è arrestato in modo anomalo) perché il resto non è molto importante.
Dal registro degli arresti anomali si può vedere che l'app che si è arrestata in modo anomalo era SpringBoard e la causa è un SIGSEGV (errore di segmentazione). Quindi, la traccia di stack (ignorare la chiamata di sistema sulla linea 34) suggerisce che è stata causata da:
33 SpringBoard 0x000908b4 0x89000 + 30900
Prendi questo con un granello di sale. Poiché non so quale sia il codice sorgente e Apple ha oscurato i registri degli arresti anomali con gli indirizzi anziché i nomi delle funzioni (era solito fornire i nomi delle funzioni), è possibile solo supporre dalla traccia dello stack e dal comportamento dello schianto.
Potrebbe anche esserci un problema con il modo in cui CoreText elabora la stringa prima passandola a SpringBoard, non lo sappiamo perché non abbiamo progettato le app interne in CoreServices.