The trace is like this
Application received signal SIGSEGV
Stack trace:
#0 CoreFoundation 002BCE149F <redacted>()
#1 libobjc.A.dylib 00394F8C8B objc_exception_throw()
#2 CoreFoundation 002BCE13E5 -[NSException initWithCoder:]
#3 funadhoc 000025B129 UmengSignalHandler()
#4 libsystem_platform.dylib 0039BB8873 _sigtramp()
#5 libobjc.A.dylib 0039505571 objc_setProperty_nonatomic_copy()
#6 Foundation 002C947F59 -[NSObject setValue:forKey:]
#7 Foundation 002C9C58F3 -[NSObject setValuesForKeysWithDictionary:]
..........................
I understand the situation of setValue:forUndefinedKey: or setNilValueForKey: , but what is this?
Besides, some system symbols are <redacted>, how can I get it symbolicated?
In this case, _sigtramp() means that your application received a Unix signal, in this case SIGSEGV. SIGSEGV means that your app was sent this signal because of a memory access violation. In this case, I'm guessing it was caused by your call to setValue: forKey:. Perhaps the object you called setValue:forKey: on (the receiver of that method) has already been deallocated? Or perhaps either the key or the value has been deallocated? That's probably what you should check.
Try turning on NSZombieEnabled (environment variable). It will keep the object around and marked as a "Zombie" and then report to you that you tried to access a Zombie. If you are using ARC, you may have some unsafe-unretained reference to the object. You need to have a strong reference to it. If its non-ARC, then you probably failed to retain it properly.
Related
I am seeing EXC_BAD_ACCESS KERN_INVALID_ADDRESS for class method.
From what I understand, I should not be seeing this for class/static methods.
Am I missing something?
Stack Trace:
Thread : Crashed: com.apple.root.user-initiated-qos
0 libobjc.A.dylib 0x0000000196eac0b4 objc_retain + 20
1 $APP_NAME 0x00000001002611a8 +[$CLASS_NAME $METHOD_NAME:] ($CLASS_NAME.m:590)
2 libdispatch.dylib 0x0000000197511994 _dispatch_call_block_and_release + 24
3 libdispatch.dylib 0x0000000197511954 _dispatch_client_callout + 16
4 libdispatch.dylib 0x000000019751e780 _dispatch_root_queue_drain + 1848
5 libdispatch.dylib 0x000000019751fc4c _dispatch_worker_thread3 + 108
6 libsystem_pthread.dylib 0x00000001976f121c _pthread_wqthread + 816
7 libsystem_pthread.dylib 0x00000001976f0ee0 start_wqthread + 4
I have seen this crash a few times (with very similar, if not identical stack traces), and found that it had to do with a nonatomic property being set with a new object, while simultaneously being read.
That objc_retain +20 instruction turned out to be a call on the isa property of the object being read-- but at that point the object is already released and the isa pointer is changed to a bad address
I was able to debug my issue by following this blog post by Mike Ash:
https://www.mikeash.com/pyblog/tales-from-the-crash-mines-issue-1.html
I would highly recommend reading the entire thing through-- it involves using the disassembler to debug, but it was definitely a lifesaver for us on multiple occasions
EDIT: Note that I am definitely not even 50% sure that this is your issue, but I hope that my anecdotal experience could save you some time. I know that I've spent many work weeks debugging issues that looked like this, but I still was never 100%
This crash happen because of dangling pointer.
For example, when variables or objects is trying to access an object that's already been de-allocated.
P.S: Most people might be confused about "memory leak" and "dangling pointer"
Dangling pointer occurs when a pointer references memory that has been de-allocated.
Memory Leak occurs when memory is still allocated but nothing references it.
EXC_BAD_ACCESS generally means that you are sending a objective C message to an invalid memory address.
It may cause:
1. An object that you want to use which has been deallocated.
2. When any variable or object is trying to access restricted memory. That means such crash occurs due to memory leak.
I'm analyzing a crash report and have come across an exception that may be due to a race-condition (my best guess).
Crash log:
Fatal Exception: NSInvalidArgumentException
*** -[__NSPlaceholderArray initWithObjects:count:]: attempt to insert nil object from objects[9]
0 CoreFoundation
__exceptionPreprocess + 132
2 CoreFoundation
-[__NSPlaceholderArray initWithObjects:count:] + 412
3 CoreFoundation
-[NSArray initWithArray:range:copyItems:] + 464
The most likely culprit is this from my code. Since the array should never contain a nil value, my guess is a possible race condition, since this line runs on a repeating timer, and the batches array is updated with location-based requested also coming in regularly elsewhere.
NSArray *batchesCopy = [self.batches copy];
My question is what is the best way to protect against these race conditions? Is there a thread-safe way to do an array copy or array edit in general? For instance a mutex lock or maybe use the "atomic" option on the property?
There is language level locking :
#synchronized(self){
//array operations
}
One way is the lockless approach, where you have a designated thread that is the only thread that ever reads or changes that object's value. You can either use an existing serial thread (most commonly the main thread as it's already there and there are many easy ways to get code run on it) or keep a custom serial thread just for that object or class of object. The style is that whenever you need to interact with that thing you schedule a block on the designated thread that reads or writes the data and does the resulting work based on the new value. This way avoids deadlocks and spinlocks, and can be faster, but it can be more code.
I am getting a crash in the app with the following stack trace-
Thread : Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x39dfa66a objc_release + 9
1 libobjc.A.dylib 0x39dfb0d7 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 358
2 CoreFoundation 0x2f4a6c69 _CFAutoreleasePoolPop + 16
3 CoreFoundation 0x2f53c1cb __CFRunLoopRun + 1306
4 CoreFoundation 0x2f4a6f0f CFRunLoopRunSpecific + 522
5 CoreFoundation 0x2f4a6cf3 CFRunLoopRunInMode + 106
6 GraphicsServices 0x343ff663 GSEventRunModal + 138
7 UIKit 0x31df216d UIApplicationMain + 1136
8 Batted 0x0009db07 main (main.m:16)
The crash occurs when zombies are not enabled in the Scheme's diagnostics options. However, when I enabled it the crash doesn't occur.
I have read some of the other Q&A regarding this, and all of them seem to advice that once this behavior is seen, enable the zombies and run the Zombie Profile Instruments on the Simulator.
I tried that, but Instruments doesn't seem to indicate anything wrong and the app works.
Any clue to what else can be done here to root-cause this issue?
I am using XCode 5.1 with iOS 7.1 in Simulator.
UPDATE 1
Found the offending code causing the problem but I am still not sure why it is causing the problem.
I am using CoreData, and in subclass of the NSManagedObject, I have -
- (void)willTurnIntoFault;
{
[super willTurnIntoFault];
if ([self observationInfo])
{
BNLogInfo(#"%# has observers:\n%#", [self objectID], [self observationInfo]);
}
}
In the above code, [self observationInfo] is the offending line.
When the app starts up, I loop over some of the NSManagedObjects in an enumeration block and set some property on it, which in turn fires the willTurnIntoFault method. Once the enumeration block completes, the crash happens.
The mystery is that the crash doesn't happen inside this method, but without this method subclassed everything runs fine.
The Q&As say to enable zombies (or run under the Zombies instrument) because a zombie often causes this sort of error.
But it's not the only cause.
Your program is corrupting the heap. Most likely it's overwriting the isa pointer (the class pointer) in some object that's in the autorelease pool, so when the run loop drains the autorelease pool, objc_release tries to dereference the bogus isa pointer and crashes.
Enabling zombies can mask an error like this because, with zombies, the runtime never actually frees objects. This means you end up with lots of parts of the heap that don't get used (unless you try to send a message to a zombie), so they never cause trouble if you corrupt them.
These sorts of crashes can be very difficult to debug, but there's a tool called “guard malloc” that sometimes helps. From the menu bar, choose Product > Scheme > Edit Scheme. Click the Run action in the list on the left. Then click the Diagnostics tab. Turn on the “Enable Guard Malloc” option. Then try to reproduce the crash. Guard malloc will detect certain types of heap corruption immediately and stop the program on the corrupting instruction.
I am stuck with the following crash report:
Date/Time: 2013-09-12 22:39:54 +0000
OS Version: iPhone OS 6.1.3 (10B329)
Report Version: 104
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0xa0000008
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x39a3c564 _cache_getImp + 4
1 libobjc.A.dylib 0x39a3e1d7 class_respondsToSelector + 31
2 CoreFoundation 0x31b96605 objectIsKindOfClass + 37
3 CoreFoundation 0x31b9635d __handleUncaughtException + 69
4 libobjc.A.dylib 0x39a41a65 _objc_terminate() + 129
5 libc++abi.dylib 0x3948e07b safe_handler_caller(void (*)()) + 79
6 libc++abi.dylib 0x3948e114 std::terminate() + 20
7 libc++abi.dylib 0x3948f599 __cxa_current_exception_type + 1
8 libobjc.A.dylib 0x39a419d1 objc_exception_rethrow + 13
9 CoreFoundation 0x31adcf21 CFRunLoopRunSpecific + 457
10 CoreFoundation 0x31adcd49 CFRunLoopRunInMode + 105
11 GraphicsServices 0x356a82eb GSEventRunModal + 75
12 UIKit 0x339f2301 UIApplicationMain + 1121
13 Our App 0x0003bc27 main (main.m:15)
After different attempts to fix the bug causing this error I keep receiving this crashlog again and again from PLCrashReporter (from our adhoc builds from the beta testers). The different exception codes vary from SIGSEGV/SEGV_ACCERR to SIGBUS/BUS_ADRALN to EXC_BAD_ACCESS/KERN_INVALID_ADDRESS
I am using the rapidjson library on iOS (armv7 and armv7s) with the padding fix as described here (#8) and I use the objective-c runtime functions to add method implementation on runtime (using class_addMethod).
Our codebase exists of mostly Objective-C code with some Obj-C++ and some C code. Memory Management is done by ARC except for the Obj-C++ and C parts which is handled manually. I looked into every malloc/free call and I extensively used libgmalloc to determine memory issues but there is nothing which does not seem correct to me.
I cannot reproduce this crashlogs myself, not in debug or release mode, but our beta testers keep sending me this crashlog once in a while (1 in about 50 runs). As our product (hopefully) will run on many iOS devices soon, this is not something we can left broken.
After reading a lot of memory management articles I suspect this issue is caused by bad memory alignment. Therefore I suspect rapidjson to be the cause of this bug. My lack of knowledge about memory alignment on iOS / armv7 does not allow me to fix this crashlog. Can someone explain me more about this subject on iOS? Or am I looking in the wrong place and is this another memory issue?
I hope someone can point me in the right direction.
If more info is needed I am happy to provide it.
Note: I am not looking for answers as using JSONKit or another library to replace rapidjson. Thanks :)
This issue was previously addressed here: https://devforums.apple.com/message/807860
In short, the original Objective-C exception has been released (eg, by an autorelease pool) prior to it being dereferenced in the uncaught exception handler. As such, __handleUncaughtException() dereferences a now-dead pointer, and you see the crash in your exception handler.
First, the address 0xa0000008 does not look misaligned, and SEGV_ACCERR does not mean an alignment problem, but a memory access permission problem (from sys/signal.h):
#define SEGV_ACCERR 2 /* [XSI] invalid permission for mapped object */
Considering you are using class_addMethod() and the crash is in _cache_getImp(), which is part of retrieving a method, my largely unfounded suspicion would be that you passed some invalid pointers to class_addMethod(), or overwrote that information later on.
Something to check would be whether you are using either globals or malloc()ed memory, because the runtime functions do not make copies for you.
Second, the crash you are seeing is secondary, you are crashing while running the top-level exception handler that is already terminating (_objc_terminate()) your program from an earlier exception, but in this case it's not a Unix signal, but an Objective-C exception: objc_exception_rethrow().
So you probably need to figure out that primary error first, for example from logs of the exception (just a backtrace isn't enough in many cases).
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.