I received a crash log that I cannot explain. I have searched around and it appears that the SIGSEGV has something to do with memory. But in my case there is nothing of my own code except for the main.m in the stacktrace. Also it doesn't seem to symbolicate any of the system libraries.
The crash so far only happened on one iPhone. On other phones I haven't been able to reproduce it. Right now I'm completely stuck and don't know where to continue so if anyone has seen something like this before it would be good to hear their problem and resolution.
The crash log:
Incident Identifier: TODO
CrashReporter Key: TODO
Hardware Model: iPhone4,1
OS Version: iPhone OS 6.1.3 (10B329)
Report Version: 104
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0x41fd5903
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x3b0b9564 0x3b0b6000 + 13668
1 libobjc.A.dylib 0x3b0bb1d7 0x3b0b6000 + 20951
2 CoreFoundation 0x33396605 0x332d4000 + 796165
3 CoreFoundation 0x3339635d 0x332d4000 + 795485
4 libobjc.A.dylib 0x3b0bea65 0x3b0b6000 + 35429
5 libc++abi.dylib 0x3ab0b07b 0x3ab0a000 + 4219
6 libc++abi.dylib 0x3ab0b114 0x3ab0a000 + 4372
7 libc++abi.dylib 0x3ab0c599 0x3ab0a000 + 9625
8 libobjc.A.dylib 0x3b0be9d1 0x3b0b6000 + 35281
9 CoreFoundation 0x332dcf21 0x332d4000 + 36641
10 CoreFoundation 0x332dcd49 0x332d4000 + 36169
11 GraphicsServices 0x36eb52eb 0x36eb0000 + 21227
12 UIKit 0x351f2301 0x3519b000 + 357121
13 Stylbar 0x0007109f main (main.m:21)
Edit 3th of May:
The crash log is sent by a user. I haven't been able to reproduce the issue myself unfortunately, which is why it's so difficult for me to figure out what went wrong with just this crash log.
It appeared to have happened about 15 times in a row for the same user when opening a certain view controller. The view controller does several calls to a server to load a post, comments and images and profile pictures. All the code that's executed when this view controller is opened is probably over 2000 lines of code (excluding the RestKit and SBWebImage libraries that are used within this code). Posting that code here wouldn't help anyone I'm afraid.
The most simple and useful way to spend your time hunting for the cause of the crash is to look at your code and focus on places where UIKit has a delegate that points back into your code. For example, I found that the most common place this sort of thing would show up was in UITableView. The reason these problems are so hard to track down is that they might only happen in a low memory situation or in some uncommon UI condition that is very hard to reproduce. It is better to just do a code review and make sure that delegate that are set to point to your classes are set back to nil in your own object destructors. If you have many developers, it is often better to work on some higher level abstractions like a generic table and cell class that is used throughout the project than to have every developer coding up a UITableView and making mistakes like forgetting to nil out the delegate that are very difficult to find.
SIGSEGV is a problem the occurs when your application tries to access an address of memory that doesn't exists or some address where is already reserved to another program. I have the same issue with an application right now but I have to review my code to figure it out better. One clue for this kind of problem could be something equivalent to this (found in wikipedia):
#include <stdlib.h>
int main(void)
{
char p = NULL; / p is a pointer to char that initializes poiting to "nowhere"*/
* p = 'x'; /* Tries to save the char 'x' in 'no address'*/
return 0;
}
I hope this can help someone.
Related
This issue is specific to RestKit, but I believe the underlying issue is related to registering to notifications. I could really use some help figuring this one out...I seem to be having the same issue appearing multiple times:
An NSInvalidArguementException coming from
serviceDidBecomeUnavailableNotification within RKClient. The action
is calling from __NSMallocBlock__, __NSCFString, __NSCFArray, NSURL,
and UICFFont... obviously the delegate is not being set correctly.
It is ONLY in my requests using RKObjectMapping to map the response to
my model classes. I've noticed the objectLoader has
isResponseMappable and checks [self.response isServiceUnavailable] -
which then posts a RKServiceDidBecomeUnavailableNotification. This
seems to be where my issue is coming from. The only place I see
isResponseMappable being called is within didFinishLoad:(RKResponse*)response.
Here's an example stack trace, I thought this could be very beneficial:
Error Message:
NSInvalidArgumentException: -[__NSMallocBlock__
serviceDidBecomeUnavailableNotification:]: unrecognized selector sent
to instance 0xee168b0
CoreFoundation:2:in `0x37d4dacb -[NSObject doesNotRecognizeSelector:]
+ 174'
CoreFoundation:3:in `0x37d4c945 ___forwarding___ + 300'
CoreFoundation:4:in `0x37ca7680 _CF_forwarding_prep_0 + 48'
Foundation:5:in `0x31c6f50f __57-[NSNotificationCenter
addObserver:selector:name:object:]_block_invoke_0 + 18'
CoreFoundation:6:in `0x37d16577 ___CFXNotificationPost_block_invoke_0
+ 70'
CoreFoundation:7:in `0x37ca20cf _CFXNotificationPost + 1406'
Foundation:8:in `0x31be33fb -[NSNotificationCenter
postNotificationName:object:userInfo:] + 66'
Foundation:9:in `0x31be4c2b -[NSNotificationCenter
postNotificationName:object:] + 30'
MyApp:10:in `0x000d2157 -[RKObjectLoader isResponseMappable] + 114'
MyApp:11:in `0x000d2b83 -[RKObjectLoader didFinishLoad:] + 418'
MyApp:12:in `0x000cb151 -[RKResponse connectionDidFinishLoading:] +
36'
Foundation:13:in `0x31ca6c39 __65-[NSURLConnectionInternal
_withConnectionAndDelegate:onlyActive:]_block_invoke_0 + 16'
Foundation:14:in `0x31bfe6e9 -[NSURLConnectionInternalConnection
invokeForDelegate:] + 28'
If anyone has any helpful tips, ideas, or suggestions on how to debug this, it would be greatly appreciated! I've been dealing with this for two weeks and am only seeing it in deployed apps (cannot replicate the issue) so any insight is better than none! Cheers!
Check whether you have add all the frame works recommended for RestKit, in your project
1. **CFNetwork.framework**
1. **CoreData.framework**
1. **MobileCoreServices.framework**
1. **SystemConfiguration.framework**
1. **libxml2.dylib**
Just incase any others fall onto this solution, the approach I took was:
Completely remove RestKit from my existing project. I then downloaded the master branch of RestKit, reintegrated into my project (there were some deprecated methods, less necessary frameworks, and refactored classes, but all in all pretty simple). I will be releasing this version with the new RestKit within the next week or so, and HOPE to not see this issue arising again.:)
If I do have this issue, I will come back and modify my answer with a reason for why it's still happening.
i have the following stack trace:
0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26
1 MyApp 0x000836bd TFSignalHandler + 28
2 libsystem_c.dylib 0x33eac727 _sigtramp + 34
3 ??? 0x00000002 0x0 + 2
4 MyApp 0x000803f1 msgpack_unpack_next + 112
5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74
6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26
7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146
...
And i'm wondering how to read it:
I assume i go from the bottom up, eg line 7 called line 6 called line 5, etc.
What does the '+ 112' on line 4 mean? Is that a line number in the code file where it crashed?
What does the '???' on line 3 mean?
Thanks a lot
0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26
Crash was generated from +[TFCrashHandler backtrace] + 26; from whatever instruction fell at that symbol location + 26 bytes.
If that is really the bottom of your stack trace and it crashed there, then the TCrashHandler is obscuring the real crash. The real crash looks to be a couple of frames above.
1 MyApp 0x000836bd TFSignalHandler + 28
TFSignalHandler was what called +backtrace.
2 libsystem_c.dylib 0x33eac727 _sigtramp + 34
Ewww... a signal trampoline. The app received a signal and the a trampoline was set to call TFSignalHandler().
There are situations where a signal handler might be called on a random thread. I.e. there is a minuscule chance that this particular crash had nothing to do with the parser and everything to do with a crash somewhere else. However, without knowing more about the parser, I'd question whether it is hardened against malicious input (which could certainly cause a crash like this).
3 ??? 0x00000002 0x0 + 2
Stack was undecodable. Ignore. Meaningless. Best case; fallout from compiler optimization. Worst case; somebody pooped on the stack and the backtrace mechanism can't figure out what is going on (highly unlikely -- usually, stack poop splatters to the point of preventing a full backtrace).
4 MyApp 0x000803f1 msgpack_unpack_next + 112
Ooooh... trickzy. Someone is using C to parse stuff. And it crashed. Whatever instruction was 112 bytes from the entry point to the function went boom. But, not really, because it called the signal handler and was handled by that; which is still a boom but the signal handler has effectively destroyed additional forensic evidence.
The "trickzy" comment references that an optimizing compiler against a big pile o' C can end up collapsing frames to the point that the crash could have happened in a function well below this one.
5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74
MessagePackParser was parsing when things went horribly wrong.
6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26
7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146
Ahh... yes.... somebody done grabbed some data from HTTP and it was malformed, causing the crash.
Bottom line; the parser got bogus input and crashed. There was a signal handler in place that tried to help by creating a backtrace, but -- apparently -- didn't really reveal any more info. A long shot alternative is that the signal was generated somewhere else and this thread was randomly selected to handle it -- if you can consistently recreate this crash, the random-thread-signal case is unlikely.
Unless you have a capture of the input data or can somehow guess how msgpack_unpack_next() might crash, you are out of luck without providing more info.
The '???' is something that can't be identified, probably code that was compiled without symbols, but could also be something else.
Those are the line numbers in the implementation file. And the hex is the pointer in memory to the line call.
I am getting a strange crash from some of my beta testers that I am having trouble with. The symbolicated crash reports indicate that the crash is occurring in the simple allocation of a controller as a singleton, at the init call, but according to the stack trace, it appears that the code I have in init is not actually where the crash is. Here is the relevant code:
1534| + (UA[REDACTED]PlayerController*)sharedInstance
1535| {
1536| #synchronized(self)
1537| {
1538| if (sharedInstance == nil)
1539| sharedInstance = [[UA[REDACTED]PlayerController alloc] init];
1540| }
1541| return sharedInstance;
1542| }
This has never crashed before, and the code has not changed anytime recently. Here is the raised stack trace:
Thread 5:
0 libSystem.B.dylib 0x33bd52d4 __kill + 8
1 libSystem.B.dylib 0x33bd52c4 kill + 4
2 libSystem.B.dylib 0x33bd52b6 raise + 10
3 libSystem.B.dylib 0x33be9d26 __abort + 62
4 libSystem.B.dylib 0x33be9d7e abort + 62
5 libSystem.B.dylib 0x33bd7980 __assert_rtn + 152
6 libgcc_s.1.dylib 0x32acab4e _Unwind_SjLj_Resume + 26
7 [REDACTED] 0x00060b64 +[UA[REDACTED]PlayerController sharedInstance] (UA[REDACTED]PlayerController.m:1540)
8 [REDACTED] 0x00063e6c -[UA[REDACTED]PlayerViewController setupControlViews] (UA[REDACTED]PlayerViewController.m:224)
9 [REDACTED] 0x00062ce0 -[UA[REDACTED]PlayerViewController viewDidLoad] (UA[REDACTED]PlayerViewController.m:268)
10 UIKit 0x320a0270 -[UIViewController view] + 104
…
Any ideas as to what this cryptic crash is and where it might be coming from?
UPDATE 1
It appears it has to do with core data and migrations. I was able to duplicate it, but the root cause is still unknown. I have some automatic migrations that are in this version, and it appears that while some of the NSManagedObjects can be read, others are throwing this exception, particularly on a NSManagedObjects relationship. It might not be related to the PlayerController at all. Any Core-Data experts have some insight?
UPDATE 2
Here is the call stack of the crash after I have found a way to reproduce it
and the relevant code:
if (resultArray && [resultArray count]) {
for (MixAudio *ma in resultArray) {
Audio *audio = [ma valueForKey:LOCAL_MIX_AUDIO_AUDIO_KEY];
if (audio) {
[returnArray addObject:audio];
}
}
To help explain what I did to reproduce it, I have to explain the data structure a little. I have Mix and Audio items. Mixes have many Audio, Audio belongs to many Mixes. This is a simple relationship call on the MixAudio objects to get the Audio. Now, this has only been crashing here after I do a database restore to the new version.
Database backups in my setup means zipping up the database to save the data, then unzipping on restore. This crash only happens after the restore process. To make things more complicated, there are 3 database versions with mapping models. Because this process worked for me before the versioning, I feel that something in my versions is causing this crash.
All other data is fine and can be accessed, even saved. Somehow, this single fetch is causing issues. There are no errors or warnings when setting up the persistent store or managed object model. Furthermore, new Mix objects can be created and accessed fine, only older fetches (that were in the DB before the restore) are failing.
If I don't catch the error, the console prints:
Assertion failed: (_Unwind_SjLj_Resume() can't return), function _Unwind_SjLj_Resume, file /SourceCache/libunwind/libunwind-24.1/src/Unwind-sjlj.c, line 326.
Putting a try/catch around the crashing line allows me to inspect the root crash cause:
Error: NSRangeException: *** -[NSMutableArray objectAtIndex:]: index 4294967295 beyond bounds [0 .. 16]
but this makes no sense (to me at least) for a simple valueForKey call. 4294967295 = 2^32-1 which means the index var was probably set to −1 if that helps. I am lost here.
[SOLVED] UPDATE 3
I was right about it being in the versioning :) I reread the section on versioning in Zarra's book and had a major DOH moment. This is the first time I have ever had an app with 3 database versions. I am using Mapping Models in my app and I naively assumed that core data would be able to map from 1-2 using one model, then 2-3 using the next. I literally hit my head when I realized I did not have a 1-3 mapping model. to test it out, I added one quickly and everything is as smooth as butter. Now I just have to go back and use his Progressive Data Migration samples to make my life easier as I go on with more version of this DB.
I am hoping Zarra drives by here and answers something… anything… so I can give him the points for this :)
While the OP was able to solve his own question, it is helpful to have a clear understanding of migrations.
When you create a second version of your data model, you need a mapping model from version one to version two.
When you create a third model you need a mapping model from one to two AND a map from one to three.
When you add a fourth model you need the following models:
1-2
1-3
1-4
2-3
2-4
And it gets more progress from there.
The crashlog on iTunesConnect for my XCode 3.2.5-built application shows method names, but not line numbers. For example, in the abridged crash report I've pasted in below, it shows this:
0x000f5ef8 -[MyTableViewController dealloc] + 120
There are two things here that are puzzling me, upon which I'd appreciate some insight. The first is why the raw .crash file coming from iTunesConnect is already partially symbolized: it shows the class and method name, but not the source code file and line number. I would expect the raw iTunesConnect crashlog to show just the hexidecimal addresses. As I understand it, only once I download the crash log onto my local system and explicitly bind it using the appropriate tool (XCode Organizer, symbolicatecrash, atos, gdb x/i command, etc) and to the exact application binary and dSYM files (those having the matching UUID), will I see the full symbols of class, method, source code file, and line number. Even when I download and view the crashlog on a Windows box, it appears partially symbolized. I am concerned that my distribution binary must be including some debug symbols in order for this information to show up in the raw crashlog, despite having "Strip Linked Project" set in its Distribution target settings. Any insight here would be great.
The second thing that is perplexing me, and is of more immediate concern to me in fixing this high-profile crash, is this business of the offset. I've very carefully located the dSYM and application binary with the matching UUID, put them in my home directory so they can be found by Spotlight et al, and no matter what I do, I am unable to convert that offset [MyTableViewController dealloc] + 120 to a source code file (which is known to me to be MyTableViewController.m) and a line number. I have tried the following tricks with the raw iTunesConnect .crash file:
XCode Organizer: its "symbolication" affects no changes to the crashlog -- it's the same.
symbolicatecrash: It doesn't really complain about anything in verbose mode, and the output crashlog is the same
gdb: Using the same gdb and -arch setting that XCode 3.2.5 uses for producing the distribution build, and loading in the matching application binary and dSYM symbols per this post, gdb 'x/i' and 'info line *' commands tells me that [MyTableViewController dealloc] + 120 corresponds to a totally unrelated piece of our codebase in a completely different file -- a .h file, even! Wild goose chase.
Something is not right here. Even despite ensuring the exact same UUID across the crash report, the application binary, and the dSYM file ... none of these tools can yield an actual line number, and doing it the low-level way sends me on a wild goose chase. Knowing the exact line number is critical to fixing this, because we are unable to reproduce this crash in-house so we're flying blind here. This looks to be a simple over-released object, but it's not clear which exact object it is, and we're unable to tell from context. I'm wondering if there is some misappropriated XCode build setting that is somehow breaking the symbolication process.
Thanks for your time!
What follows is the abridged raw .crash log from iTunesConnect.
Incident Identifier: 09EAE058-7D55-4AE5-947A-17280FB0211A
Hardware Model: iPhone3,1
Process: MyApp [1895]
Path: /var/mobile/Applications/B4B872EF-CB0D-41D7-A7B5-435ADE479D0A/MyApp.app/MyApp
Identifier: MyApp
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2011-01-24 14:06:32.941 -0500
OS Version: iPhone OS 4.2.1 (8C148)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xd0000000
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x33479466 objc_msgSend + 18
1 MyApp 0x000f5ef8 -[MyTableViewController dealloc] + 120
2 CoreFoundation 0x33a26f74 -[NSObject(NSObject) release]
3 libobjc.A.dylib 0x3347a812 objc_setProperty
4 UIKit 0x320bb4a0 -[UINavigationController setDisappearingViewController:]
5 UIKit 0x320bb478 -[UINavigationController _clearLastOperation]
xx SNIP xx
23 MyApp 0x00014eac main + 36
24 MyApp 0x0000b324 start + 44
XX SNIP xx
Binary Images:
0x1000 - 0x1e3fff +MyApp armv7 <5570f8eee3bc11647732c12f96fe9553> /var/mobile/Applications/B4B872EF-CB0D-41D7-A7B5-435ADE479D0A/MyApp.app/MyApp
I've experienced similar issues with releasing object that weren't retained or that were in an autorelease pool thereby getting released twice. More often than not I'll get a crash for a location that is inside the framework/iOS but was caused from my lack of proper memory management. I'm not saying this IS happening here, but just is something I've experienced when a similar error has presented itself.
I've been looking at crash logs generated by an iphone app today:
Thread 0 Crashed:
0 libobjc.A.dylib 0x3002d7da 0x3002b000 + 10202
1 UIKit 0x31ec4abc 0x31e4d000 + 490172
2 UIKit 0x31ebd214 0x31e4d000 + 459284
3 UIKit 0x31ebcfac 0x31e4d000 + 458668
Can anyone tell me what the hex addresses mean? (memory addresses, sure..)
I know how to symbolicate to produce:
0 libobjc.A.dylib 0x000027da objc_msgSend + 18
1 UIKit 0x00077abc -[UINavigationController _startDeferredTransitionIfNeeded] + 176
2 UIKit 0x00070214 -[UINavigationController pushViewController:transition:forceImmediate:] + 600
3 UIKit 0x0006ffac -[UINavigationController pushViewController:animated:] + 28
and debug the crash from there, but I'm curious; if you take
0x3002d7da 0x3002b000 + 10202
then: 0x3002d7da = 0x3002b000 + (decimal) 10202
What does this signify exactly?
I should add I'm not looking for info on how to symbolicate, thx!
EDIT: what is also strange to me is that if you compare pre and post symbolicated versions, then for code I wrote:
9 memleaktest 0x00002ffe 0x1000 + 8190
becomes
9 memleaktest 0x00002ffe -[memleaktestViewController buttonOne] (memleaktestViewController.m:24)
makes sense, but for framework code:
8 CoreFoundation 0x307fe52c 0x307f8000 + 25900
becomes
8 CoreFoundation 0x0000652c -[NSObject(NSObject) release] + 24
the address and offset has changed? Why would this be?
if you take
0x3002d7da 0x3002b000 + 10202
What does this signify exactly?
In this case, the "+" doesn't signify addition so much. What this line is telling you is:
The routine/library in question starts at address 0x3002b000
Your line-of-code in the stack trace happened 10202 bytes into it.
The sum of those two numbers = 0x3002d7da
(Put another way, as you did, 0x3002d7da = 0x3002b000 + 10202.)
The important thing about which you might care is the start address of the method being called.
But, really, you can ignore all of that, since it's not nearly as useful as the symbolicated version, which gives you source-file name & line-number.
Extending Olie's response on the "symbolicated version" of the app: The debugging information is stripped from the distribution version of the app to make it smaller and also to protect the developer's intellectual property (so you can't see class and method names).
In order to decrypt the log, you need to have the debugging symbols file associated with the specific build that created the crash log.
This file (.dSYM extension) will be present in the build folder where the binary of the iPhone app is also located. Please note that you need the .dSYM file for the specific compilation that was used to compile the app on the phone - the dSYM file is timestamped, so if you recompile the app, the dSYM file will change even if you don't change a line of code.
Once you have this file on your computer, drag the crash file into xcode (or view logs from attached devices in the Organiser), which will give you a stack trace of the methods called and the specific lines of code called which led to the crash.