1. 首頁
  2. 問答
  3. iOS應用程序崩潰，xcode在調試時說'與X的iPhone無法連接'

iOS應用程序崩潰，xcode在調試時說'與X的iPhone無法連接'

2014-09-24 85 views
62

我的應用程序崩潰了，我需要一些建議來查找和解決問題。這不是設備或電纜問題，因爲它發生在所有設備上，而不僅僅是在調試時。 Xcode不會停止在異常斷點上，該應用程序只是簡單地停止運行而沒有錯誤信息。當調試xcode時只會說'丟失與X的iPhone的連接'。我有以下日誌可從設備，看到MY_CRASHING_APP：iOS應用程序崩潰，xcode在調試時說'與X的iPhone無法連接'

Incident Identifier: 85730E97-BA21-4C72-8AD1-02075A8FD9A7 
CrashReporter Key: d9e9eb14ac1801fea11e662a394244d7caf29154 
Hardware Model:  iPhone4,1 
OS Version:   iPhone OS 8.0 (12A365) 
Kernel Version:  Darwin Kernel Version 14.0.0: Tue Aug 19 15:08:02 PDT 2014; root:xnu-2783.1.72~8/RELEASE_ARM_S5L8940X 
Date:    2014-09-24 15:02:41 +0200 
Time since snapshot: 325 ms 

Free pages:        20793 
Active pages:       20412 
Inactive pages:       10678 
Speculative pages:      1757 
Throttled pages:       55906 
Purgeable pages:       699 
Wired pages:        21196 
File-backed pages:      30263 
Anonymous pages:       2584 
Compressions:       76385 
Decompressions:       3948 
Compressor Size:       81 
Uncompressed Pages in Compressor:  61 
Page Size:        4096 
Largest process: MY_CRASHING_APP 

Processes 
    Name  |   <UUID>    |  CPU Time|  rpages|  purgeable| recent_max| lifetime_max| fds | [reason]   | (state) 

     coreduetd <675ac3d39b193f9bba42896818431859>   0.049   124    0   -   391 50  [vnode-limit]  (daemon) (idle) 
      homed <77bcbc47e2723e269b0ff9d115658259>   0.052   146    0   -   458 50  [vnode-limit]  (daemon) (idle) 
      gamed <a51b1ad16b693a75aeaaf2166e7b1b0b>   0.049   38    0   -   74 50  [vnode-limit]  (daemon) (idle) 
      lsd <72b4494834d3357bb8aa32fd5b5c8e83>   0.068   161    0   -   368 50  [vnode-limit]  (daemon) 
    InCallService <88e149874b1c35f2b8adbeee958d7258>  18.461  1289    0   -   3238 50  [vnode-limit]  (resume) (continuous) 
MY_CRASHING_APP <1542054cd5393df29827ca1a6bd34e04>  59.116  24504    600   -   29490 1600  [vnode-limit]  (frontmost) (resume) 
      ptpd <c0bc1e573edb3bcebea0f3140a139421>   3.442   878    0   -   1634 50      (daemon) 
     BTServer <1b7372b3ae393847b1c3ccaa720e991e>   3.057   393    0   -   1437 50      (daemon) 
     lockdownd <bb602fb4b5ac3b51af2d22c4fdce9778>  11.306   271    0   -   761 50      (daemon) 
     imagent <01ebc2c08d7f36059714967efaa86e78>  19.892   585    0   -   1286 50      (daemon) 
     locationd <9727e24fbe4f357cb27d7bc8cf882c93>  489.694  1665    0   -   3586 50      (daemon) 
identityservices <13c2b979d6433252a011087be05e1aa5>  22.999   696    0   +2   1585 50      (daemon) 
     discoveryd <dff5d0d2edf43b45b0c7fbd4a3e1b677>  93.758   589    0   -   1077 100      (daemon) 
      wifid <5fb79228aa653a9bb725217b9cb891e6>  63.420   571    0   -   1098 50      (daemon) 
    iaptransportd <ae70565455de38f3aab8993e9d109207>   7.713   306    0   -   579 50      (daemon) 
    mediaserverd <b5ba58774a853d43a17559ae76a6f918>  649.476  1025    64   -   6134 50      (daemon) 
     syslogd <a5a138dc01cd34d19bbe336c03099ce7>  40.100   201    0   -   384 50      (daemon) 
      powerd <b3163caaebd53f7aa42634836472ea04>  43.199   231    0   -   474 50      (daemon) 
      apsd <17af2320ccfb3e668b6455b95b4612ce>  37.461   631    0   -   1445 50      (daemon) 
     networkd <a657abe0ce803333b886876a8f7a36e0>  77.271   596    0   -   1297 50      (daemon) 
    dataaccessd <db655c44d5c830dc9e5f34f7edcb17a4>  243.259  1777    0   -   3097 100      (daemon) 
      vmd <88cebb23d0f1344db23e1896b1787f2d>   0.505   204    0   -   617 50      (daemon) 
      iapd <e84bb9b7cf7530babc36c6ca37b7f345>  11.963   453    0   -   1673 50      (daemon) 
    syslog_relay <9e18dbcbcc07374e9d14c732b8dabad2>   1.424   98    0   -   189 50      (daemon) 
      voiced <2d24fa3e32533f2f8298743eaf348d63>   0.179   210    0   -   581 50      (daemon) 
    itunesstored <d50d5b1c3f693694a2eee878aae8facf>   0.573   908    0   -   1759 50      (daemon) 
    SpringBoard <3e0aacaca7103aa09a71e5c9fee3e012>  841.081  7088    29   -   16912 50      
     backboardd <117d65aca8ce3ba68c7fd87d9ab81da6>  3424.058  6678    625   -   4409 50      (daemon) 
    UserEventAgent <2f6c74a697943aed899faebac621e4c3>  316.816   848    0   -   2101 200      (daemon) 
     configd <64e4db8bced23463b446c4b7c868fcfa>  31.906   416    0   -   933 50      (daemon) 
     fseventsd <a393d343a7533860b5c1eddb922a33f1>  20.088   405    0   -   805 50      (daemon) 
    fairplayd.H1 <c3856f0573fb3f9887721a239507f28b>  30.647   159    0   -   1096 50      (daemon) 
     assertiond <7d4db2b36ddac986060d8c62f73>  26.282   289    0   -   702 50      (daemon) 
    wirelessproxd <ba82fe3b38f63f2b8b8807a2bf97aadd>   1.071   179    0   -   643 50      (daemon) 
     distnoted <e8f9e76e751838a880dad2d4a953f814>   4.457   193    0   -   254 50      (daemon) 
discoveryd_helpe <84abc0c6dd5b37a8b2c8323881e16da7>   0.493   123    0   -   466 50      (daemon) 
      ubd <5f4f0054821e3b41b543a4d9f4176291>   9.040   730    0   -   1540 50      (daemon) 
filecoordination <68a3848887853629adae42f5828a5443>   2.731   251    0   -   649 100      (daemon) 
     aggregated <ab0d307a392f36cc827709d24c4b8696>  1335.558  1081    0   -   1688 50      (daemon) 
     DTMobileIS <086152f142ac30a686a172b148d38fbc>  109.156   474    0   -   1724 50      (daemon) 
    touchsetupd <d8aabe65f2d23f6ab7704bbccc6c2ba1>   0.388   158    0   -   464 50      (daemon) 
     cfprefsd <6e5dcfe209183c719091d07edad590da>   0.150   166    0   -   320 50      (daemon) 
     accountsd <9eb0309b021033c6b24ce65da48fa228>   0.665   595    0   -   1909 50      (daemon) 
     CommCenter <0e1ced0eddce346ba27e9f54886ef025>  669.306  1543    0   -   4623 50      (daemon) 
     notifyd <7beaf472572334d4989a40473776f635>  61.698   272    0   -   309 50      (daemon) 
    ReportCrash <b36d5780860a3dfcbb146b2cc6bca339>   0.062   146    0   -   443 50      (daemon) 

**End**

UPDATE：

它原來是內存問題。該應用程序很快分配了大量內存，操作系統終止了該應用程序。奇怪的是，Xcode沒有記錄內存警告，而在儀表顯示該應用程序收到很多警告。使用相同數量內存的其他應用程序不會出現內存警告。我的猜測是那些人沒有以如此快的速度分配內存。

該應用程序運行在iPhone 4S上，並在大約90MB內存使用率時死亡。

令我困惑的是其他內存不足問題全部都有Purgeable pages: 0。所以我猜這不是完全是內存不足，而是在很短的時間內使用了太多內存。

來源

2014-09-24 SolidSun

+0

看起來像內存不足問題？在儀器中剖析應用程序 – 2014-09-24 15:42:37

+0

我有同樣的問題，並使用儀器進行分析，發現某些代碼導致CPU 100％使用率，重構具體方法，然後問題消失。 – Allen 2015-04-22 16:12:49

+1

你怎麼知道具體的方法？ @Allen – omarojo 2016-02-04 04:13:49

回答

12

是的，這是一個內存問題，或者你打開了太多的線程。我以前遇到過這個問題。我遇到的問題是這樣的：

當我刪除一張可能花費約0.2秒的照片時，我想向用戶顯示一個烤麪包（MBProgressHUD），並且在刪除後隱藏烤麪包。
當我試圖刪除100張照片時，沒關係。但是，當我試圖刪除200張照片時，該應用可能會崩潰。當我試圖刪除300張照片時，iPhone總是自行重啓。

來源

2015-05-05 08:29:20

+0

嗨安迪， 您是否找到解決此問題的任何解決方案？ – Wish 2017-02-03 16:53:38

+0

你必須找出錯誤的邏輯。我的問題是在1秒內顯示MBProgressHUD 200次。你的代碼邏輯肯定有問題。 – 2017-02-07 02:07:51

18

我UIImage■裝載了一堆非常大的圖像（5000px X 5000px）時有同樣的問題。幸運的是，圖像不應該在任何附近，我只需要調整它們。

來源

2015-05-07 23:27:16 respectTheCode

+0

你的意思是上傳圖片時調整它的大小，還是下載時調整大小？ – aircraft 2017-01-05 03:00:45

+0

有沒有辦法來釋放這些'UIImage'？ – 2017-09-25 18:37:39

3

正如安迪達爾文所說，這是一個記憶問題。

我animationImages添加UIImageView時，對舊設備這個問題。

來源

2015-06-18 08:31:11 Jasper

+0

但在那裏有一個很好的解決方案？ – aircraft 2017-01-05 02:59:26

1

在我的情況下，我使用UICollectionView來顯示一堆照片，並且當我想要執行reloadData視圖時，發生崩潰，而內存使用率並不高（小於100M）。除了內存問題，我認爲UICollectionView或UITableView的reloadData也可能導致這種情況。

來源

2015-12-09 13:50:16 FisherMartyn

2

發帖爲後代，我最近經歷了這種「崩潰」和其他人所說是不是因爲內存問題：

在極少數情況下，這可與用於連接電源線的問題iPhone到電腦。我有一個錯誤的閃電電纜，偶爾會失去與我的Mac的連接。解決方案是由一個新的！

來源

2016-11-09 23:50:22 Tim

+0

它可以肯定是電纜！ – Fattie 2017-12-19 15:58:29

0

只是爲了補充一點，我有同樣的問題上都運行我的應用程序和舊的iPad 3和iPhone 6，什麼結束了，問題是我不小心保存的項目的2個圖像爲40MB和20MB的版本。所以這是一個記憶問題。我把它們縮小爲每個1MB，然後解決問題。

來源

2016-11-12 17:10:45 Apneist

21

只是在爲這個人苦苦掙扎的任何其他人。

對我來說，解決方案是重新啓動我的設備。

來源

2017-07-23 10:22:32 Chris

18

自從我打開iOS 11測試版以來，此錯誤頻繁出現。有時重新啓動設備的作品，有時我的電腦...

來源

2017-08-21 16:05:56 Beninho85

+1

我在10/4/2017有官方最新版本的iOS 11，並且我無法每次都從Xcode運行我的應用到我的設備。昨天事情很好。這個人說，解決方案就是重新啓動我的設備。謝謝。 – coolcool1994 2017-10-04 19:07:08

相關問題

 相關問題