I have a problem with my iOS app crashing. It uses core data (one managed object context) and ARC but also has a separate SQLite database, which can be fairly large. I am getting crash reports for it with the error: EXC_BAD_ACCESS and usually with the code: KERN_INVALID_ADDRESS
The problem is that every single crash happens in a different place (there are over 30) and that usually those places don't usually include any of my code in the call stack. I think, therefore that I am doing something fundamentally wrong which is causing these errors to occur.
I have tried turning on NSZombiesEnabled, but then I find that the errors don't occur. Also, I have tried turning on core data debugging (level 1), but I find the same there too. The errors occur across a range of devices and operating systems. The crash reports show between 3.0 to 148.0 mb or ram remaining. All of the crashes are on the main thread.
So my question comes in two parts:
1) I can't find any reference to there being a problem using a separate SQLLite database in a core data project. Is there any potential pitfalls to doing this and docs on how to avoid those pitfalls?
2) Does this patten of errors suggest anything in particular which I may be doing incorrectly?
I have added a single crash report on the off chance it reveals something which my question does not:
0
com.apple.main-thread Crashed
0 CoreFoundation CFRetain + 19
1 CoreFoundation __CFRunLoopDoTimer + 690
2 CoreFoundation __CFRunLoopDoTimer + 690
3 CoreFoundation __CFRunLoopRun + 1232
4 CoreFoundation CFRunLoopRunSpecific + 356
5 CoreFoundation CFRunLoopRunInMode + 104
6 GraphicsServices GSEventRunModal + 74
7 UIKit UIApplicationMain + 1120
8 cleverme
main.m line 14
main
Related
I experiencing a crash in my app:
Thread 0 name:
Thread 0 Crashed:
0 LogoQuizAC 0x0000000104705218 __hidden#563_ + 0 (__hidden#957_:0)
1 LogoQuizAC 0x0000000104705218 _hidden#18_ + 592 (__hidden#957_:135)
2 LogoQuizAC 0x000000010470503c __hidden#564_ + 48 (__hidden#456_:0)
3 LogoQuizAC 0x000000010470503c _hidden#18_ + 116 (__hidden#957_:135)
4 LogoQuizAC 0x00000001046fcd6c _hidden#17_ + 504 (__hidden#454_:96)
5 LogoQuizAC 0x00000001046fcea0 _hidden#20_ + 36 (__hidden#456_:0)
6 Foundation 0x0000000182770b20 __NSFireTimer + 68 (NSTimer.m:270)
7 CoreFoundation 0x0000000181355fa0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 32 (CFRunLoop.c:1807)
8 CoreFoundation 0x0000000181355ba0 __CFRunLoopDoTimer + 1064 (CFRunLoop.c:2415)
9 CoreFoundation 0x0000000181354ffc __CFRunLoopDoTimers + 328 (CFRunLoop.c:2575)
10 CoreFoundation 0x000000018134eee4 __CFRunLoopRun + 1936 (CFRunLoop.c:3090)
11 CoreFoundation 0x000000018134e21c CFRunLoopRunSpecific + 600 (CFRunLoop.c:3242)
12 GraphicsServices 0x0000000198f18784 GSEventRunModal + 164 (GSEvent.c:2259)
13 UIKitCore 0x0000000183d8eee8 -[UIApplication _run] + 1072 (UIApplication.m:3253)
14 UIKitCore 0x0000000183d9475c UIApplicationMain + 168 (UIApplication.m:4707)
15 LogoQuizAC 0x000000010453a404 main + 68 (RLockedCell.swift:21)
16 libdyld.dylib 0x000000018100e6b0 start + 4
I tried almost everything but can symbolicate the crash.
I tried using symbolicatecrash followed by these posts:
(_hidden#919_:0) inside crash symbolication file
Why aren't the crashlogs from Testflight symbolicating in Xcode?
Xcode Crash Organizer does Not Symbolicate .xccrashpoint Files
How to symbolicate crash log with Xcode 8?
how Symbolicate a crash file using xcarchive
How to symbolicate crash log Xcode?
But without any success.
What am I doing wrong? How can I figure out what causing the crash?
The good news that it is crashing in your code, not in Operating Systems or Library code, so you have a good chance to debug it. Your code that is crashing is running off a timer. Sometimes these bugs are seen because in testing, you are just testing the app. But in the real world, those timers fire when you are not expecting them.
For example, someone ran your app, then put it into the background when using another app, or for example they received a phone call whilst using the app. If you attach the full contents of the .crash file, it will give more information on the cause of the crash.
Another thing you can do is place asserts into your code, such as in your timer callback functions for each object you are relying on being non-null.
You may find that your app is trying to draw onto the screen but is in the background. This is a common reason for a crash seen in the field for games that use timers. That may sound like a generalisation but it is a suggestion to try and make you think differently about the real world environment your customers face which can the reason for the failure.
I'm using the TestFlight SDK and have received several crash reports identical to this one. However, I'm having trouble understanding it, and what the underlying cause of the crash is from the reports?
Exception
SIGSEGV
2 libsystem_c.dylib 0x32862e92 _sigtramp + 42
3 Foundation 0x33750d1c -[NSError dealloc] + 60...
Exception reason
SIGSEGV
Stacktrace
0 MyAppName 0x0013faba testflight_backtrace + 382
1 MyAppName 0x00140708 TFSignalHandler + 264
2 libsystem_c.dylib 0x32862e92 _sigtramp + 42
3 Foundation 0x33750d1c -[NSError dealloc] + 60
4 libobjc.A.dylib 0x39230488 _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 168
5 CoreFoundation 0x31de9440 _CFAutoreleasePoolPop + 16
6 Foundation 0x33751f7a -[NSAutoreleasePool drain] + 122
7 CoreData 0x35e0a4b2 -[NSManagedObjectContext save:] + 1210
8 MyAppName 0x000b7168 MR_swapMethodsFromClass + 18076
9 CoreData 0x35e0dbc0 developerSubmittedBlockToNSManagedObjectContextPerform + 88
10 libdispatch.dylib 0x335974b6 _dispatch_client_callout + 22
11 libdispatch.dylib 0x33598dca _dispatch_main_queue_callback_4CF$VARIANT$up + 226
12 CoreFoundation 0x31e79f3a __CFRunLoopRun + 1290
13 CoreFoundation 0x31decebc CFRunLoopRunSpecific + 356
14 CoreFoundation 0x31decd48 CFRunLoopRunInMode + 104
15 GraphicsServices 0x36e092ea GSEventRunModal + 74
16 UIKit 0x320db2f8 UIApplicationMain + 1120
17 MyAppName 0x00099122 main (main.m:17)
18 MyAppName 0x000990d7 start + 39
Additional details:
Users report this crash happens 1-2 seconds after the app starts
The app uses Core Data and MagicalRecord (which is where the MR_swapMethodsFromClass method comes from)
I can't reproduce this issue on any test devices when running from Xcode (iPhone 3GS, iPhone 4, or iPhone 5) running various iOS versions (iOS 5.1, 6.0, 6.1)
EDIT
Still working on solving this issue... I've been able to recreate it (but not with a debugger attached).
Here's the strangest part-- if a user has an older version of the app and installs an update (distributed via Test Flight), they get this error.
However, if they first delete the old app and install the update, the error doesn't occur.
Let's walk through it:
0 MyAppName 0x0013faba testflight_backtrace + 382
1 MyAppName 0x00140708 TFSignalHandler + 264
That's TestFlight. This is after the crash has happened, so it's certainly not the cause.
2 libsystem_c.dylib 0x32862e92 _sigtramp + 42
This is the point at which we caught the crash. "sigtramp" is the signal "trampoline." That's a fancy way of saying "I caught a signal (crash) and now I'm going to bounce to somewhere else in the code."
3 Foundation 0x33750d1c -[NSError dealloc] + 60
Ah. This is important. We crashed while deallocating an NSError. That means the NSError was over-released or under-retained.
4 libobjc.A.dylib 0x39230488 _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 168
5 CoreFoundation 0x31de9440 _CFAutoreleasePoolPop + 16
6 Foundation 0x33751f7a -[NSAutoreleasePool drain] + 122
Sad… it manifested while draining the autorelease pool. That means the actual bug could be a long way from here. But at least we know the type of the object. NSZombies could be of use to try to find the specific object.
7 CoreData 0x35e0a4b2 -[NSManagedObjectContext save:] + 1210
And the autorelease pool was draining during a MOC save. That suggests it's probably related to your Core Data code. It's at least where you'd look first.
The things to remember are:
The bug is almost certainly in your code.
If it's not in your code, it's probably in Magical Record
Do not assume it is in Core Data. That is the least likely place for the bug given this stack.
Here's the strangest part-- if a user has an older version of the app and installs an update (distributed via Test Flight), they get this error.
However, if they first delete the old app and install the update, the error doesn't occur.
Probably in your upgrade code then. Most likely in the Core Data migration stuff. Audit every use of NSError in that area of code. Eliminate all compiler and analyzer warnings. And try NSZombies if its reproducible.
You should try to add a model version to your data model. It worked for me, i had a similar Magical-Record-related issue.
I'm using BugSense to track crashes from an iOS App. Recently I noticed problems symbolicating stack traces from live usage.
The problem is that Apple introduced address space randomization with iOS 4.3 so that the stack address of interest cannot solely be used to retrieve the correct methods that caused the crash.
Currently I'm trying to get the correct address by calculating
symbol address = slide + stack address - load address
I already have slide and stack address but from my understanding the load address can only be found in the crash report which I cannot get via BugSense.
The stack trace looks like
0 CoreFoundation 0x342723e7 + 162
1 libobjc.A.dylib 0x3bf63963 objc_exception_throw + 30
2 CoreFoundation 0x3427229d + 0
3 Foundation 0x34b48fa3 + 90
4 UIKit 0x360b5bd9 + 7640
5 MyApp 0x000c6e99 0xb3000 + 81561
6 UIKit 0x3623c2ff 0x3607e000 + 1827583
7 UIKit 0x361b8737 0x3607e000 + 1287991
8 UIKit 0x361a9869 0x3607e000 + 1226857
9 UIKit 0x361a97ad 0x3607e000 + 1226669
10 CoreFoundation 0x34247941 0x341b0000 + 620865
11 CoreFoundation 0x34245c39 0x341b0000 + 613433
12 CoreFoundation 0x34245f1d 0x341b0000 + 614173
13 CoreFoundation 0x341b923d CFRunLoopRunSpecific + 356
14 CoreFoundation 0x341b90c9 CFRunLoopRunInMode + 104
15 GraphicsServices 0x37d9733b GSEventRunModal + 74
16 UIKit 0x360d52b9 UIApplicationMain + 1120
17 MyApp 0x000b61bf 0xb3000 + 12735
18 MyApp 0x000b4a08 0xb3000 + 6664
Is there another way to symbolicate this address or to get the respective load address?
The load address is 0xb3000.
Luckily you have the symbols stripped from your app binary, otherwise this wouldn't be visible.
Also this crash happened because of an exception being thrown, so the crash report should give you a Last Exception Backtrace showing where the actual exception happened and the actual exception reason. It is likely that the call in line 5 of the posted stack trace doesn't give you a lot of information on that. The crash information you are getting looks pretty limited :(
I am using Bugsense in my app to get crash reports.
I have a repeating bug with SIGSEGV and no other details about it.
I tried to symbolicate the report but I get this:
0 libobjc.A.dylib 0x33417f78 0x33414000 + 16248
1 CoreFoundation 0x36f651fb 0x36f4d000 + 98811
2 Foundation 0x32c42747 0x32b9e000 + 673607
3 CoreFoundation 0x36fdaad3 0x36f4d000 + 580307
4 CoreFoundation 0x36fda29f 0x36f4d000 + 578207
5 CoreFoundation 0x36fd9045 0x36f4d000 + 573509
6 CoreFoundation 0x36f5c4a5 CFRunLoopRunSpecific + 300
7 CoreFoundation 0x36f5c36d CFRunLoopRunInMode + 104
8 GraphicsServices 0x35123439 GSEventRunModal + 136
9 UIKit 0x35205cd5 UIApplicationMain + 1080
10 English Club 0x00036a2b 0x34000 + 10795
It does not point to any of my classes (In the last line 'English Club' is the name of my app).
Does that mean that this is a bug in apple classes? how can I parse this report to get somthing helpful (like what are the +1234334 numbers in this case etc.
Thank you all
Shani
Does that mean that this is a bug in apple classes?
No.
how can I parse this report to get somthing helpful
Recompile with debug symbols enabled, and run the app in the debugger. Then, if everything was done right, you'll get a symbolicated stack trace.
what are the +1234334 numbers in this case
They're offsets from the beginning of the particular function address - and you're most likely not interested in them.
Your best bet here is to enable zombies and rerun in the debugger and try to reproduce the crash manually. The bug is likely somwhere in your code where you set a delegate that points to one of your objective C objects. For example, see this question which is much like yours: SIGSEGV SEGV_ACCERR Crash Reports - What to do?
Is this definitely a memory crash, or should I be looking for something else?
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x81093cd0
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x33563f78 objc_msgSend + 16
1 Foundation 0x34d6b92c __NSFireDelayedPerform + 408
2 CoreFoundation 0x35919a2c __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 8
3 CoreFoundation 0x35919692 __CFRunLoopDoTimer + 358
4 CoreFoundation 0x35918268 __CFRunLoopRun + 1200
5 CoreFoundation 0x3589b49e CFRunLoopRunSpecific + 294
6 CoreFoundation 0x3589b366 CFRunLoopRunInMode + 98
7 GraphicsServices 0x33636432 GSEventRunModal + 130
8 UIKit 0x33073cce UIApplicationMain + 1074
Using the profiler, live bytes are well under 10MB at all times, and when memory warns happen I'm back to 3MB or below.
This statement returns YES, so I assume I have zombies enabled:
getenv("NSZombieEnabled") || getenv("NSAutoreleaseFreedObjectCheckEnabled")
When I'm running from Xcode, the app crashes without Xcode even being aware (after some arbitrary number of memory warns).
Any suggestions besides "run with NSZombies enabled?" And, is this definitely a memory crash?
SIGSEGV happens when the code tries to access memory that "doesn't exist" (that is, the address you are trying to use doesn't have a mapping in your virtual address space).
The exact cause of this can be a large number of things - the most common ones are:
Using pointers that are not (properly) initialized.
Walking off the end of an array.
Using memory that has been freed.
Note that all of the above are examples of "undefined behaviour", so you may well have situations where your code doesn't crash although it's doing something wrong, but the same code, under other circumstances, DOES go wrong.
Yes, this is a memory-related error (segmentation fault). Keep in mind that NSZombies can't catch every memory error.