Normally the crash log indicates where this might be happening, but in this case, this is all I am getting. Lets say my main view is A and I have A,B, and C views.
This only happens if I do the following:
Go from A to B to C, go out of app and load up a few other apps. Then return to my app, go back to B, then go back to A (THIS IS WHERE IT CRASHES).
EDIT - I had posted the wrong thread before...here is the correct thread
CRASH LOG:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x4daf03bd
Crashed Thread: 7
Thread 7 name: Dispatch queue: com.apple.root.default-priority
Thread 7 Crashed:
0 libobjc.A.dylib 0x36f22f78 objc_msgSend + 16
1 Foundation 0x33707d04 _NSDescriptionWithLocaleFunc + 44
2 CoreFoundation 0x34f3a96e __CFStringAppendFormatCore + 7998
3 CoreFoundation 0x34eb51d8 _CFStringCreateWithFormatAndArgumentsAux + 68
4 Foundation 0x33707c2e +[NSString stringWithFormat:] + 54
5 MyGreatApp 0x00061028 -[DataAccessor getProducts:div:productType:cat:searchsilver:completion:] (DataAccessor.m:301)
6 MyGreatApp 0x00017196 __36-[products showNationalCategories]_block_invoke_0 (products.m:1688)
7 libdispatch.dylib 0x37886c52 _dispatch_call_block_and_release + 6
8 libdispatch.dylib 0x378927b4 _dispatch_worker_thread2 + 256
9 libsystem_c.dylib 0x35b45df4 _pthread_wqthread + 288
10 libsystem_c.dylib 0x35b45cc8 start_wqthread + 0
Here is line 301 (Note, all the objects going into the string are NSStrings):
NSString *urlStr = [NSString stringWithFormat:#"%#?api_key=%#&device[duid]=%#&division=%#",apiUrl,apiKey, duid, division];
My wild guess is that something is being deallocated in viewDidUnload which is relied upon and not being re-initialized properly. In most cases, viewDidUnload does not get called while testing; and it's the one thing I can think might be happening while you are off in those other apps. Do some double-checking on all of A's properties which get used when the view comes on screen, and double-check that they are non-nil.
I think your callback is being run when a different view controller from the one you were expecting is being presented. I think its first best to work out the faulty string pointer by NSLogging them on separate code lines. Also have you used any _block decorations for those string parameters (or used them twice: both inside and outside the block) -- that would break the retain on them.
Related
I am experiencing an incredibly strange crash inside my override of the encodeWithCoder: method. You can see my implementation at https://github.com/reidmain/FDModel/blob/193b0661f7ab1ce62f80de02bcbfa10a38c58ce9/FDModel/FDModel.m#L340-358
I have received tens of thousands of crash logs similar to the following:
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0x5000000c
Crashed Thread: 0
Application Specific Information:
objc_msgSend() selector name: replacementObjectForKeyedArchiver:
Thread 0 Crashed:
0 libobjc.A.dylib 0x38acb626 objc_msgSend + 6
1 Foundation 0x2eca70d7 _encodeObject + 128
2 MyApp 0x00411d8b -[FDModel encodeWithCoder:] + 268
3 Foundation 0x2eca7479 _encodeObject + 1058
4 Foundation 0x2eca8657 -[NSKeyedArchiver _encodeArrayOfObjects:forKey:] + 396
5 Foundation 0x2eca8329 -[NSDictionary(NSDictionary) encodeWithCoder:] + 918
6 Foundation 0x2eca7479 _encodeObject + 1058
7 Foundation 0x2ecf432d +[NSKeyedArchiver archiveRootObject:toFile:] + 202
8 MyApp 0x003dd561 -[MyAppsDataClient _saveObjectsToDisk] + 74
The problem is that inside the company no one has experienced these crashes personally. Even after writing a stress test which calls the method which triggers the encoding every couple seconds and letting it run for an hour nothing happens.
It looks like either FDModel or the object that it is trying to encode is somehow released from memory but how this happens remains a mystery to me. If FDModel was released from memory how would _encodeObject succeed being called? If it was FDModel being released from memory I would expect to see a wide range of crash logs on all sorts of methods being called on FDModel but it not existing in memory. All of the crashes are complaining about replacementObjectForKeyedArchiver:
After talking with an Apple employee on the dev forums it looks like the issue was due to the model being encoded at the same time as it was being modified.
I updated FDModel to use a NSRecursiveLock whenever changes were being made the model or whenever the model was being encoded.
I'm getting crash reports of AFNetworking throwing an EXC_BAD_ACCESS KERN_INVALID_ADDRESS:
Thread : Crashed: com.apple.root.default-priority
0 libobjc.A.dylib 0x39e237fa objc_release + 9
1 MY_APP 0x0015ba63 __64-[AFHTTPRequestOperation setCompletionBlockWithSuccess:failure:]_block_invoke (AFHTTPRequestOperation.m:266)
2 MY_APP 0x00163bf7 __47-[AFURLConnectionOperation setCompletionBlock:]_block_invoke (AFURLConnectionOperation.m:301)
3 Foundation 0x3049a2a9 __103+[__NSOperationInternal _observeValueForKeyPath:ofObject:changeKind:oldValue:newValue:indexes:context:]_block_invoke96 + 12
4 libdispatch.dylib 0x3a30b0c3 _dispatch_call_block_and_release + 10
5 libdispatch.dylib 0x3a3107d9 _dispatch_root_queue_drain + 224
6 libdispatch.dylib 0x3a3109c5 _dispatch_worker_thread2 + 56
7 libsystem_pthread.dylib 0x3a43adff _pthread_wqthread + 298
I need help to understand the possible bug. This is something that happens sometimes, actually is very rare and it could be related to a timeout issue when user is using 3G (network can be disconnected while loading data).
I don't post my code because I can't find on the crash log in which file or class this crash happened and I use AFNetworking in a lot of files.
Without any code this is all conjecture but:
Something in the completion block is being accessed after it is deallocated. Commonly, this happens when a network operation isn't cancelled after a view controller is dismissed.
I have an iOS app, and I am getting quite amount of this crash.
And it seems that it is not related to my code. Do you have any idea why the app can crash because of this. Is there something that I can do to prevent these crashes.
Thread 9 Crashed:
1 libobjc.A.dylib _objc_msgSend + 16
2 libdispatch.dylib __dispatch_call_block_and_release + 13
3 libdispatch.dylib __dispatch_queue_drain + 239
4 libdispatch.dylib __dispatch_queue_invoke$VARIANT$mp + 41
5 libdispatch.dylib __dispatch_worker_thread2 + 211
6 libsystem_c.dylib __pthread_wqthread + 295
GCD is used in your app. So..
Bring more detail-info please? code where it's occurred?
May be you need copy block vs retain, may be you need use __block vars correctly. May be something else. Obviously, your object had been captured by block is released and deallocated when happens queue_drain, and after that you call method of the object in other scope, or in the block scope.
My iOS app keeps crashing. I found the way I could make it crash consistently. I repeated the operation multiple times and I get the same crash log every single time.
The crash happens if I do the following: launch the app, use it a bit (optional), go to the main screen, open a modal ViewController, dismiss it, keep using the app (optional), close the app (press home button, not kill the app), wait a bit (optional), re-open the app. When the app is re-opened, it crashes after 1 second. Note that where you are in the app when you leave it does not cause/prevent the crash. No matter where you are on the app, it crashes the same way. If I use the app and don't open the modal VC, I can send it in background and re-open it with no problem.
Here is some of the crash log I get every time (I took out what I thought was not related, I can provide the full log):
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x317d332c __pthread_kill + 8
1 libsystem_c.dylib 0x33ed0208 pthread_kill + 48
2 libsystem_c.dylib 0x33ec9298 abort + 88
3 libc++abi.dylib 0x36d56f64 abort_message + 40
4 libc++abi.dylib 0x36d54346 _ZL17default_terminatev + 18
5 libobjc.A.dylib 0x35321350 _objc_terminate + 140
6 libc++abi.dylib 0x36d543be _ZL19safe_handler_callerPFvvE + 70
7 libc++abi.dylib 0x36d5444a std::terminate() + 14
8 libc++abi.dylib 0x36d5581e __cxa_rethrow + 82
9 libobjc.A.dylib 0x353212a2 objc_exception_rethrow + 6
10 CoreFoundation 0x37572506 CFRunLoopRunSpecific + 398
11 CoreFoundation 0x37572366 CFRunLoopRunInMode + 98
12 GraphicsServices 0x33d31432 GSEventRunModal + 130
13 UIKit 0x3131ecce UIApplicationMain + 1074
14 ***my app name** 0x0006f140 0x6b000 + 16704
15 ***my app name** 0x0006d5f0 0x6b000 + 9712
It's hard to provide some code, and I don't even know what I could possibly give..
I'd love some help, I have no idea why this is happening..
Feels to me like some cleanup is happening whilst you're in the background. If it's not iOS 6 then check what you;re doing to handle viewDidUnload and in any version, check what you're doing in viewWillDisappear/viewDidDisappear and viewWillAppear/viewDidAppear.
One of our testers is reporting the following crash:
0 APP_NAME_WAS_HERE 0x00074892 testflight_backtrace + 158
1 APP_NAME_WAS_HERE 0x000754bc TFSignalHandler + 244
2 libsystem_c.dylib 0x378ea7ec _sigtramp + 48
3 CoreFoundation 0x30ef42e6 CFRelease + 94
4 CoreFoundation 0x30f09a36 -[__NSArrayM removeObjectAtIndex:] + 294
5 CoreFoundation 0x30f4a65e -[NSMutableArray removeObjectsInRange:] + 90
6 APP_NAME_WAS_HERE 0x000570ca -[StoryViewController rewindToChunkIndex:] + 558
7 APP_NAME_WAS_HERE 0x00057396 -[StoryViewController restartChapter] + 22
Unfortunately, we can't reproduce the crash - we're only getting crash log sent through via TestFlight.
We did receive debug logs to confirm that the removeObjectsInRange is definitely receiving a valid range for the NSMutableArray that is being acted upon. (besides, that would kick up an exception rather than raising a signal, right?)
My only thought is that the object is getting a double release, but I'm not sure how this is possible with ARC switched on?
Note that the objects being removed are UIView subclasses, and before-hand, some or all of them may have been removed from their superviews. So I wouldn't be surprised if they were released at this stage, I just don't understand why that's causing it to crash!
EDIT: In an attempt to verify that it's an over-released object, I artificially tried over-releasing an object (using CFRelease(__bridge (CFTypeRef) obj) to force release in ARC environment) to see the type of crash log that it would produce. Unfortunately, it's a bit different, so perhaps it's not an over-release after all? Is it perhaps a scribble of some kind?
Here's what a definite over-release looks like:
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x369c732c __pthread_kill + 8
1 libsystem_c.dylib 0x36c20208 pthread_kill + 48
2 libsystem_c.dylib 0x36c19298 abort + 88
3 libsystem_c.dylib 0x36bd437a free + 374
4 libobjc.A.dylib 0x375e4d72 object_dispose + 14
5 CoreFoundation 0x362e9618 -[NSObject dealloc] + 76
6 UIKit 0x310323a8 -[UIView dealloc] + 620
7 libobjc.A.dylib 0x375e416e _objc_rootRelease + 30
8 CoreFoundation 0x362dc2e0 CFRelease + 88
9 APP_NAME_WAS_HERE 0x000cea98 -[StoryViewController rewindToChunkIndex:] (StoryViewController.m:584)
Here's what an over-release crash log looks like:
If you look at the stack trace, the crash occurs not because of wrong index, but because of a over-release of the objects.
NSArray sends a retain message when you add an object and a release message when you remove an object. Apparently, that release is crashing.
This means, you are over-releasing the object you added to your array.
Update
Are your sub-views strongly owned? Is your ownership modifier "strong" or "weak" or unsafe_unretained? Even in ARC, there can be unbalanced calls to retain if you don't "own" your variables properly. For example, since you are manually adding and removing views into another array, you should "own" it. Remove from superview will send a release to the view and addSubview will send a retain. When you build your views using XIB, the XIB loading mechanism uses the property'w ownership modifier and bump up the retain count accordingly when it adds it to the view (StoryViewController.view). Since XIB loading mechanism added it to subviews, you shouldn't unload it. If you want to unload it, you should "own" it by changing the property type of your subviews (outlets) to "strong", otherwise, you will end up messing the ownership.
Start thinking in terms of Object graphs and who owns what, when you write your ARC ownership modifiers. ARC is not like Garbage collection. Things like this will still happen :)
My fix for the problem was to turn the compiler's optimization level down to None [-O0] from the default setting of Fastest, Smallest [-Os] in the target's build setting (set in release only).
I'm not sure whether it's simply sidestepping the problem or whether there's actually a bug in the compiler, but there you go. And it explains why only testers were getting it.
Without seeing code, it's tough to say what the real problem is. I'd bet its a case of something being over-released. Remember, ARC does not apply to Core Foundation objects.
It's possible that you've assigned a property with an convenience constructor instead of with alloc and init. Such objects are autoreleased and must be explicitly retained or they will be immediately deallocated in the following cycle.