Databases
StackOverflow2013
Postsdbo
POiOS app crashes on resuming
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POiOS app crashes on resuming
    primarykey
    data
    text
    <p><strong>(SEE UPDATE AT THE BOTTOM)</strong></p> <p>Recently I've started getting a weird and rare crash of my iPhone app when it returns from background. The crash log consists of system calls only:</p> <pre><code>Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00000138 Crashed Thread: 0 Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libobjc.A.dylib 0x34c715b0 objc_msgSend + 16 1 CoreFoundation 0x368b7034 _CFXNotificationPost + 1424 2 Foundation 0x34379d8c -[NSNotificationCenter postNotificationName:object:userInfo:] + 68 3 UIKit 0x37ddfec2 -[UIApplication _handleApplicationResumeEvent:] + 1290 4 UIKit 0x37c37d5c -[UIApplication handleEvent:withNewEvent:] + 1288 5 UIKit 0x37c376d0 -[UIApplication sendEvent:] + 68 6 UIKit 0x37c3711e _UIApplicationHandleEvent + 6150 7 GraphicsServices 0x36dea5a0 _PurpleEventCallback + 588 8 CoreFoundation 0x3693b680 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 12 9 CoreFoundation 0x3693aee4 __CFRunLoopDoSources0 + 208 10 CoreFoundation 0x36939cb2 __CFRunLoopRun + 642 11 CoreFoundation 0x368aceb8 CFRunLoopRunSpecific + 352 12 CoreFoundation 0x368acd44 CFRunLoopRunInMode + 100 13 GraphicsServices 0x36de92e6 GSEventRunModal + 70 14 UIKit 0x37c8b2fc UIApplicationMain + 1116 15 [MyAppName] 0x00083d60 main (main.m:20) 16 [MyAppName] 0x00080304 start + 36 </code></pre> <p>This might look like a zombie object being called on <code>UIApplicationWillEnterForegroundNotification</code> or <code>UIApplicationDidBecomeActiveNotification</code> (guessing by <code>_handleApplicationResumeEvent</code> in stack trace and the time when it crashes), but:</p> <ol> <li>None of my classes register for <code>UIApplicationDidBecomeActiveNotification</code>, and only a couple of singletons (that stay alive forever) register for <code>UIApplicationWillEnterForegroundNotification</code>;</li> <li>I've done some experimenting, and it turns out that posting <code>UIApplicationWillEnterForegroundNotification</code> goes from <code>[UIApplication _sendWillEnterForegroundCallbacks:]</code>, and it isn't in the crash log.</li> </ol> <p>For me, all this implies a bug in some library I'm using, or a system bug, and the crash occurred once on iOS 5.1.1 (release build), once on iOS 6.0 (release build) and once on iOS 6.0 (debug build). I scanned every library I'm using and have access to the source code for, and they aren't registering for neither <code>UIApplicationWillEnterForegroundNotification</code> nor <code>UIApplicationDidBecomeActiveNotification</code>. The only library I don't have access to is TestFlight, but the crash occurred on both 1.0 and 1.1 versions of TestFlight, and I've been using the former for quite a while now, without such problems. So, summing up, I have no idea why has this crash come up and what's it coming from. Any ideas?</p> <p><strong>UPDATE 1</strong></p> <p>I've investigated the issue a bit deeper, thanks to DarthMike and matt for their help. By using notification center callback and logging stack trace, I've discovered that this exact stack comes up when and only when <code>UIApplicationResumedNotification</code> notification is fired as a part of returning from background. And guess what - it's some "private" notification and it doesn't have a public identifier counterpart. It doesn't have <code>userInfo</code> and its object is <code>UIApplication</code> (as many other notifications that are posted before this). Obviously I don't use it, neither does any library I have source code for. I can't even find any reasonable mentioning of it in the Internet! I also highly doubt that TestFlight is the culprit, because crash happened during debug too, and I don't "take off" TestFlight in debug mode.</p> <p>Here's the stack trace for receiving <code>UIApplicationResumedNotification</code>. The offsets are all the same but with a constant byte offset (2 or 4, depending on the library - probably because it's a debug stack tracing, not release):</p> <pre><code>0 [MyAppName] 0x0016f509 NotificationsCallback + 72 1 CoreFoundation 0x3598ce25 __CFNotificationCenterAddObserver_block_invoke_0 + 124 2 CoreFoundation 0x35911037 _CFXNotificationPost + 1426 3 Foundation 0x333d3d91 -[NSNotificationCenter postNotificationName:object:userInfo:] + 72 4 UIKit 0x36e39ec7 -[UIApplication _handleApplicationResumeEvent:] + 1294 5 UIKit 0x36c91d61 -[UIApplication handleEvent:withNewEvent:] + 1292 6 UIKit 0x36c916d5 -[UIApplication sendEvent:] + 72 7 UIKit 0x36c91123 _UIApplicationHandleEvent + 6154 8 GraphicsServices 0x35e445a3 _PurpleEventCallback + 590 9 CoreFoundation 0x35995683 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 14 10 CoreFoundation 0x35994ee9 __CFRunLoopDoSources0 + 212 11 CoreFoundation 0x35993cb7 __CFRunLoopRun + 646 12 CoreFoundation 0x35906ebd CFRunLoopRunSpecific + 356 13 CoreFoundation 0x35906d49 CFRunLoopRunInMode + 104 14 GraphicsServices 0x35e432eb GSEventRunModal + 74 15 UIKit 0x36ce5301 UIApplicationMain + 1120 16 [MyAppName] 0x000aa603 main + 390 17 [MyAppName] 0x000a41b0 start + 40 </code></pre> <p>NotificationsCallback is an "observer" callback I've added for debug just for now.</p> <p>Just to prove a point, I've deliberately omitted a <code>removeObserver:</code> call from one of my objects to generate a zombie/exception, and stack trace still included <code>_CFXNotificationPost + 1426</code> followed by a crash with <code>EXC_BAD_ACCESS</code> in <code>objc_msgSend + 16</code>, just as in my original crash. So this just means that someone has registered an observer for <code>UIApplicationResumedNotification</code> and haven't removed it before the observer was deallocated. Based on the fact that I never registered for such a notification, I can assume that this crash is not my fault. Still the question remains - whose it is then? I wonder who actually registers for this notification anyway...</p> <p><strong>UPDATE 2</strong></p> <p>While I'm still waiting to see if there are any changes with this bug on the new version of my app, I've got another crash on the previous version caused by this. Turns out that whatever registers for <code>UIApplicationResumedNotification</code>, specifies selector <code>_applicationResuming:</code> for it. I doubt that's of any use though.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USArgentumko
    1. USArgentumko
    plurals
    1. This table or related slice is empty.
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POiOS app crashes on resuming
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POiOS app crashes on resuming
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POiOS app crashes on resuming
      1. USYang Meyer
      1. VTFavorite
    1. CO"For me, all this implies a bug in some library I'm using, or a system bug." I'm going to give you the best Cocoa touch programming advice you will ever get. Assume it's *you*.
      singulars
      1. POiOS app crashes on resuming
      1. USmatt
    2. COIf you are using Localytics, then this is a known issue for their library and they have dispatched an emergency update for their library
      singulars
      1. POiOS app crashes on resuming
      1. USLefteris
    3. COThanks, Leftertis, but I don't use Localytics, I use TestFlight.
      singulars
      1. POiOS app crashes on resuming
      1. USArgentumko
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload