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.
Related
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.
I have nib file having lots of UIViews(More than 100), Also I am creating 500+ UIViews using Code.
Just FYI, Application is kind of Game board with Blocks.
Problem, Randomly application get crashed on nib objects while playing game. I am not able to make test case. But I can say that Application crashed on Nib objects(IBOutlet) only.
each time it throughs bad access on nib's IBOutlet only.
I tried by making IBOutlet property with retain. also synthesize properly, but getting the same problem randomly.
Please help me to manage nib objects.
Exact Error Message was : EXC_BAD_ACCESS
Here is Stacktrace
libobjc.A.dylib 0x3995e5aa objc_msgSend + 9
1WWS 0x00064437 0x5a000 + 42039
2WWS 0x00063b5d 0x5a000 + 39773
3Foundation 0x37df7539 + 200
4Foundation 0x37deedb9 + 840
5Foundation 0x37e673db + 102
6libdispatch.dylib 0x370b211f + 10
7libdispatch.dylib 0x370b14b7 + 22
8libdispatch.dylib 0x370b61bd + 224
9CoreFoundation 0x34d57f3b + 1290
10CoreFoundation 0x34ccaebd CFRunLoopRunSpecific + 356
11CoreFoundation 0x34ccad49 CFRunLoopRunInMode + 104
12GraphicsServices 0x3261d2eb GSEventRunModal + 74
13UIKit 0x342a72f9 UIApplicationMain + 1120
14WWS 0x0005b09f 0x5a000 + 4255
One way to test whether IBoutlet causing problem or not is, Disconnect all IBoutlet view. Instantiate them in view didLoad method and try running your app. If app still crashes then consider it is memory issue.
If app is not crashing then it is might be IBoutlet issue only.
Another way is to use Instruments tool.
Use product -> Analyze to check any memory leaks in your code.
Run product -> profile -> Leaks tool check runtime leaks.
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.
I'm seeing the following crash on two different devices (an iphone 3g and an ipod touch) when in adhoc mode, although it seems to be OK when building in debug mode for those devices. It also seems to be OK on iPhone 4's.
Here's the stack trace that I'm getting in ad hoc mode:
https://gist.github.com/af5ea32f2dacc795387e
From what I can tell, this stack trace is producing a recursive call to requestWithURL:delegate: - although it makes no such call in code:
///////////////////////////////////////////////////////////////////////////////////////////////////
+ (TTURLRequest*)requestWithURL:(NSString*)URL delegate:(id /*<TTURLRequestDelegate>*/)delegate {
return [[[TTURLRequest alloc] initWithURL:URL delegate:delegate] autorelease];
}
So what's going on here? How can I debug this further?
From your stack trace (line 8) it looks like something is calling an undefined function
8 CoreFoundation 0x000a5b28 -[NSObject(NSObject) doesNotRecognizeSelector:] + 8
9 CoreFoundation 0x0004ae00 ___forwarding___ + 500
10 CoreFoundation 0x0004abb8 _CF_forwarding_prep_0 + 40
11 App 0x0005684a +[TTURLRequest requestWithURL:delegate:] + 42
12 App 0x00056840 +[TTURLRequest requestWithURL:delegate:] + 32
First add some print statements in to see which function call is the offender, use:
[object doesRespondToSelector:#selector(someFunction:withArg:)]
If it is not your code which is calling an undefined function make sure the arguments you are passing in are valid, print out the value of URL, and delegate to ensure they are are indeed of the expected type and value. Most importantly make sure that delegate does respond to whatever messages TTURLRequest will pass to it.
Also, is TTURLRequest your class, can you give the full definition, does it extend another class, does it define 'initWithURL'? Can we see the source? Those are important questions for anyone trying to debug your code.
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.