I get this crash in my live app for my IAP. I'm stressed out by it since it's a missed revenue opportunity. Can anyone help me understand this crash report?
Crashed: com.apple.main-thread
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000010
raw
0
libobjc.A.dylib
objc_msgSend + 16
1
StoreKit
__34-[SKProductsRequest _handleReply:]_block_invoke + 52
2 libdispatch.dylib
_dispatch_call_block_and_release + 24
9 UIKit
UIApplicationMain + 204
10
MyApp
main.m line 14
main
11
libdispatch.dylib
(Missing)
Not much to go on there.
0 libobjc.A.dylib objc_msgSend + 16
1 StoreKit __34-[SKProductsRequest _handleReply:]_block_invoke + 52
If I were you I'd look carefully at your SKProductRequestDelegate's -productRequestDidReceiveResponse: method. Although it doesn't show up in the backtrace, sometimes they aren't 100% reliable.
The other thing to look for is to see if that delegate has somehow been released. Crashing in objc_msgSend is frequently due to that. Are you using ARC?
Here's an article that should be on every ObjC coder's reading list:
http://sealiesoftware.com/blog/archive/2008/09/22/objc_explain_So_you_crashed_in_objc_msgSend.html
Related
I have several production iOS apps that all use the Fabric framework for Crashlytics and Twitter integration. For the past few months I've been seeing a low-level crash show up in Crashlytics, but I have been unable to duplicate it.
Here is the stack trace and about all I have to go on:
Thread : Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x0000000194eec174 objc_release + 20
1 libobjc.A.dylib 0x0000000194eed724 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 564
2 CoreFoundation 0x0000000183141074 _CFAutoreleasePoolPop + 28
3 Foundation 0x0000000184072588 -[NSAutoreleasePool release] + 148
4 UIKit 0x0000000187d443f4 -[UIApplication _run] + 588
5 UIKit 0x0000000187d3ef40 UIApplicationMain + 1488
6 GT CFPlus 0x000000010000e7ec main (main.m:16)
7 libdyld.dylib 0x000000019557ea08 start + 4
At that point I get an EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x00000000e005bec8 message.
I've done the standard Googling of the problem and based on posts like this it seems obvious that I'm doing something that ARC doesn't like. I just can't figure out what that might be. I have tried turning on NSZombies and have also run my code against an Objective-C static analysis tool with no luck on either.
My question is: has anyone run into anything similar, especially when using the Fabric framework? If so, is this something that could be buried in the framework, or is it my own doing?
I'm posting here in hope for advice from more experienced programmers (in general & with Cocos2D specifically).
I have an old-ish project that is using Cocos2D v2.1 in a couple of places, otherwise it's standard UIKit. I updated it to be compliant with arm64, or so I thought, and managed to remove any compiler warnings, and run the app successfully on the simulator. However, I just got a bug report form an iPad Air user that the Cocos2d portion of the app is crashing.
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000010
Triggered by Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x00000001995101d0 0x1994f8000 + 98768
1 0x000000010014e820 -[CCTimer update:] + 152
2 0x0000000100152140 -[CCScheduler update:] + 420
3 0x000000010016ab30 -[CCDirectorIOS drawScene] + 172
Like I say, there are no compiler warnings and it all works on the simulator, so I'm kinda stuck as to how to fix it. I know that the usual two options would be to
1. remove arm64
2. upgrade to Cocos2D v3.0
However, I use Cocos2D only for a tiny portion of the app, so I was hoping that perhaps I am missing a simple fix. I'm pretty inexperienced with Cocos2D and debugging in general, so I'm hoping for some advice if this is a lost cause and I should better spend my time on one of the other 2 options, or perhaps there is something simple that I can tweak that I am missing right now. I did browse through the CCTimer update: methods, and the only thing that stood out were a few floats in the code, that I know can be problematic between 32/64 bit, but without a compiler warning I am at a loss.
UPDATE
So it gets mysteriouser and mysteriouser. I bought a brand new iPad Air to test this locally instead of on the simulator, and... it works. No crashes. Does the user perhaps simply have a defective device? I noticed that the Exception is thrown at KERN_INVALID_ADDRESS at 0x0000000000000010 which looks somewhat odd. Most of similar crash reports I've seen online have entirely different addresses that look much more random.
UPDATE 2
More mysteries. While the local version works on the device (run via XCode), the actually downloaded app from the AppStore does crash! I was able to capture some more info about it from the Device Logs:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000010
Triggered by Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x0000000196c041d0 objc_msgSend + 16
1 0x00000001001da820 -[CCTimer update:] + 152
2 0x00000001001de140 -[CCScheduler update:] + 420
3 0x00000001001f6b30 -[CCDirectorIOS drawScene] + 172
4 QuartzCore 0x000000018cf40cb8 CA::Display::DisplayLinkItem::dispatch() + 32
5 QuartzCore 0x000000018cf40ac4 CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 296
6 IOKit 0x000000018b23be70 IODispatchCalloutFromCFMessage + 360
7 CoreFoundation 0x000000018a2ec8dc __CFMachPortPerform + 188
8 CoreFoundation 0x000000018a2fae8c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 52
9 CoreFoundation 0x000000018a2fadec __CFRunLoopDoSource1 + 440
10 CoreFoundation 0x000000018a2f9010 __CFRunLoopRun + 1616
11 CoreFoundation 0x000000018a239c1c CFRunLoopRunSpecific + 448
12 GraphicsServices 0x000000018fec9c08 GSEventRunModal + 164
13 UIKit 0x000000018d36afd8 UIApplicationMain + 1152
14 0x00000001000f4994 main (main.m:16)
15 libdyld.dylib 0x00000001971e7a9c start + 0
Thread 1:
0 libsystem_kernel.dylib 0x00000001972c9aa8 kevent64 + 8
1 libdispatch.dylib 0x00000001971cd998 _dispatch_mgr_thread + 48
Thread 2:
0 libsystem_kernel.dylib 0x00000001972c9ca0 mach_msg_trap + 8
1 CoreFoundation 0x000000018a2fab70 __CFRunLoopServiceMachPort + 180
2 CoreFoundation 0x000000018a2f8d00 __CFRunLoopRun + 832
3 CoreFoundation 0x000000018a239c1c CFRunLoopRunSpecific + 448
4 AudioToolbox 0x0000000189aedabc GenericRunLoopThread::Entry(void*) + 156
5 AudioToolbox 0x0000000189ade278 CAPThread::Entry(CAPThread*) + 136
6 libsystem_pthread.dylib 0x0000000197363e18 _pthread_body + 164
7 libsystem_pthread.dylib 0x0000000197363d70 _pthread_start + 136
8 libsystem_pthread.dylib 0x0000000197361550 thread_start + 0
Thread 3:
0 libsystem_kernel.dylib 0x00000001972e2e74 __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x0000000197361548 start_wqthread + 0
Thread 4:
0 libsystem_kernel.dylib 0x00000001972e2e74 __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x0000000197361548 start_wqthread + 0
Baffled.
Definitely remove arm64 from your project build settings (architecture, valid architectures) because cocos2d-iphone prior to v3 is not compatible with 64-bit builds even if you do not get compiler warnings/errors. There are some nasty potential issues hidden away.
If you do not receive compiler warnings I think it's likely that the 32/64 bit compatibility issues warnings are simply not enabled in your project/target (specifically the cocos2d-iphone target if it's in a separate target). In stock v2.1 of cocos2d there should actually be plenty of such warnings, though it may depend on your iOS Deployment target (for a test try setting it to iOS 7.1 which will give you the most warnings, including many "deprecation" warnings).
You can also perform an Analyze build to point out potential issues (and some false alerts, too).
I'm running my ios app in ipad 1, the following crash happen sometime while app is running, i don't know where the crash happen. This mostly happen in ios 5.1.1 . Here the crash log,
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xf0000008
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x3387ef78 objc_msgSend + 16
1 UIKit 0x333ffa3a -[UIViewController unloadViewForced:] + 254
2 UIKit 0x335473a6 -[UIViewController purgeMemoryForReason:] + 58
3 Foundation 0x3507a4f8 __57-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke_0 + 12
4 CoreFoundation 0x35c2c540 ___CFXNotificationPost_block_invoke_0 + 64
5 CoreFoundation 0x35bb8090 _CFXNotificationPost + 1400
6 Foundation 0x34fee3e4 -[NSNotificationCenter postNotificationName:object:userInfo:] + 60
7 Foundation 0x34fefc14 -[NSNotificationCenter postNotificationName:object:] + 24
8 UIKit 0x335120e6 -[UIApplication _performMemoryWarning] + 74
9 UIKit 0x335121e0 -[UIApplication _receivedMemoryNotification] + 168
10 libdispatch.dylib 0x33ffb252 _dispatch_source_invoke + 510
11 libdispatch.dylib 0x33ff8b1e _dispatch_queue_invoke$VARIANT$up + 42
12 libdispatch.dylib 0x33ff8e64 _dispatch_main_queue_callback_4CF$VARIANT$up + 152
13 CoreFoundation 0x35c332a6 __CFRunLoopRun + 1262
14 CoreFoundation 0x35bb649e CFRunLoopRunSpecific + 294
15 CoreFoundation 0x35bb6366 CFRunLoopRunInMode + 98
16 GraphicsServices 0x33951432 GSEventRunModal + 130
17 UIKit 0x3338ecce UIApplicationMain + 1074
18 MY Game 0x00079a90 0x75000 + 19088
19 MY Game 0x00079a50 0x75000 + 19024
As i understand from crash log, crash not happen due to my code. It's due low memory. Is that correct? How to find where the crash happen? Any suggestions.
As i understand from crash log, crash not happen due to my code. It's due low memory. Is that correct?
No, that's not correct.
Low memory is being reported, but your view controller is not responding properly. The most common cause of this is a retain cycle - see UIViewController purgeMemoryForReason: Crashing on iOS 5. In that answer, the retain cycle is in SVPullToRefresh , but yours could be elsewhere. The most common cause of retain cycles is not setting a delegate property to weak.
Once you figure out where the issue is, you can set breakpoints in viewDidUnload and ``didReceiveMemoryWarning`, simulate a memory warning, and step through your code to find the error.
Symbolication
Additionally, this crash report isn't symbolicated. Typically you'll want to symbolicate your crash report first. For example, see these lines:
18 MY Game 0x00079a90 0x75000 + 19088
19 MY Game 0x00079a50 0x75000 + 19024
In this case, as pointed out by Kerni, those two will just show start and main, so they won't help you in this instance. But generally, you should symbolicate your crash reports. (Search for "Xccode symbolicate crash logs" if you don't know how to do this.)
My application is crashing when one of the views is purged from memory because of low-memory condition. At least this is what I understand from the crashlog. It happens on numerous screens but only when opening a Facebook dialog (using the Facebook SDK). Basically, looks like the system sometimes runs out of memory when we need to present a Facebook dialog (e.g. to let user post something on the Facebook timeline).
Date/Time: 2012-03-14 19:47:33.819 +0000
OS Version: iPhone OS 5.1 (9B176)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x30000008
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x30f2bf78 objc_msgSend + 16
1 MyApp 0x00003c0e -LTBaseViewController viewDidUnload (LTBaseViewController.m:145)
2 MyApp 0x00004ea2 -LTBaseTableViewController viewDidUnload (LTBaseTableViewController.m:90)
3 UIKit 0x33766bd8 -[UIViewController unloadViewForced:] + 244
4 UIKit 0x338ae492 -[UIViewController purgeMemoryForReason:] + 58
5 Foundation 0x3071a4f8 __57-NSNotificationCenter addObserver:selector:name:object:_block_invoke_0 + 12
6 CoreFoundation 0x30e95540 ___CFXNotificationPost_block_invoke_0 + 64
7 CoreFoundation 0x30e21090 _CFXNotificationPost + 1400
8 Foundation 0x3068e3e4 -NSNotificationCenter postNotificationName:object:userInfo: + 60
9 Foundation 0x3068fc14 -NSNotificationCenter postNotificationName:object: + 24
10 UIKit 0x3387926a -UIApplication _performMemoryWarning + 74
11 UIKit 0x33879364 -UIApplication _receivedMemoryNotification + 168
12 libdispatch.dylib 0x36a12252 _dispatch_source_invoke + 510
13 libdispatch.dylib 0x36a0fb1e _dispatch_queue_invoke$VARIANT$up + 42
14 libdispatch.dylib 0x36a0fe64 _dispatch_main_queue_callback_4CF$VARIANT$up + 152
15 CoreFoundation 0x30e9c2a6 __CFRunLoopRun + 1262
16 CoreFoundation 0x30e1f49e CFRunLoopRunSpecific + 294
17 CoreFoundation 0x30e1f366 CFRunLoopRunInMode + 98
18 GraphicsServices 0x33fb6432 GSEventRunModal + 130
19 UIKit 0x336f5e76 UIApplicationMain + 1074
20 MyApp 0x00004818 main (main.m:16)
21 MyApp 0x000023b4 0x1000 + 5044
I checked and there are almost no memory leaks, e.g. when testing the app for an hour the total memory leaked was around 2-3Kb caused by some string-copying libraries. So I don't believe this is caused by the application. I guess that when the phone is not restarted for some time there are applications running in the background and when using Facebook SDK the memory becomes a problem and the system tries to recover the memory from random applications, including my application.
My question is, how can I prevent this crash from happening? How should I handle unloadViewForced on a view controller to make the app more robust in low-memory conditions? And lastly, am I right that this crashlog suggests the crash occurred because the system tried to free memory and my application didn't handle it properly?
Any help greatly appreciated.
What is most likely happening is that one of the objects being referred to and probably being released by LTBaseViewController viewDidUnload method is being doubly released. In fact, since the backtrace indicates that the crash is happing on line 145 of LTBaseViewController.m you should be able to quickly see which object is the culprit.
An iPhone app is crashing on the device but not on the simulator. So I'm trying to learn how to interpret the crash log. I read lots of forum posts saying that the symbolicated crash log shows a back trace that gives the method and line number of the calls leading to the crash but I don't see anything useful. Maybe I'm not looking at the symbolicated crash log. Here is the beginning of what I see:
Incident Identifier: 432A8974-1661-409F-B5A6-970148550A46
CrashReporter Key: db93147c0a70a5f4c60dc92f826e72d5a74477c8
Hardware Model: iPhone3,3
Process: Darken [57959]
Path: /var/mobile/Applications/CB27C10F-CD3B-4148-8321-2C251888B27B/Darken.app/Darken
Identifier: Darken
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2012-02-25 10:43:47.753 -0500
OS Version: iPhone OS 4.2.10 (8E600)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000008
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x32716464 objc_msgSend + 16
1 UIKit 0x3245e6fe -[UIScrollView(UIScrollViewInternal) _scrollViewAnimationEnded] + 90
2 CoreFoundation 0x32071bb8 -[NSObject(NSObject) performSelector:withObject:] + 16
3 UIKit 0x3245e5b8 -[UIAnimator stopAnimation:] + 276
4 UIKit 0x323efbf2 -[UIAnimator(Static) _advance:] + 214
5 UIKit 0x323efb0e LCDHeartbeatCallback + 10
6 GraphicsServices 0x35474362 HeartbeatVBLCallback + 86
7 IOMobileFramebuffer 0x34739bf4 IOMobileFramebufferVsyncNotifyFunc + 68
8 IOKit 0x348e5e64 IODispatchCalloutFromCFMessage + 192
9 CoreFoundation 0x32070be0 __CFMachPortPerform + 204
10 CoreFoundation 0x320686f8 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 20
11 CoreFoundation 0x320686bc __CFRunLoopDoSource1 + 160
12 CoreFoundation 0x3205af76 __CFRunLoopRun + 514
13 CoreFoundation 0x3205ac80 CFRunLoopRunSpecific + 224
14 CoreFoundation 0x3205ab88 CFRunLoopRunInMode + 52
15 GraphicsServices 0x354724a4 GSEventRunModal + 108
16 GraphicsServices 0x35472550 GSEventRun + 56
17 UIKit 0x323c7d1a -[UIApplication _run] + 406
18 UIKit 0x323c5884 UIApplicationMain + 664
19 Darken 0x000029d6 0x1000 + 6614
20 Darken 0x00002998 0x1000 + 6552
... Threads other than 0 listed here
Is anything here useful for finding out which line of my code led to the crash? Darken is the name of the application -- I already knew that. The only method name I recognize is UIApplicationMain but the crash didn't happen when the app was first launched -- I was running it about a minute and doing dozens of functions before the crash.
You may want to try and set NSZombieEnabled to YES in your project and let it crash with your device running in debug. It should stop at the line of code causing your crash. Your error looks like it is an EXC_BAD_ACCESS which usually means you were trying to access some deallocated memory.
You won't get a line number from a crash dump (unless you compiled your app with -g and run in GDB, but I doubt it since you don't seem to know what these are at all).
You ARE looking at the symbolicated crash dump: you DO have the names of the functions in the call stack. The crash occurs in the last called (topmost) function, which is objc_msgSend. That means you're not properly balancing your alloc/retain/copy methods with autorelease/release, and the messenger function tries to access already freed/corrupted/nonexistent memory, hence the crash (EXC_BAD_ACCESS is similar to a segfault, in fact you'll get one of these when you make such a mistake).
So my advice is, triple check your code for method calls modifying the reference count.