I am writing an App using the Appcelerator framework, and I get occasional crashes. I'm trying to track down whats causing the crash, so I decided to take a look at the iOS simulator crash report. Its of course all greek to me, but was hoping for some guidance on what part of this is a clue to the cause of the crash?
I pulled out the thread which is labeled as 'Crashed', but within that thread there are multiple entries (0-9), listed below. Is there any clue to figuring out which of those entries is causing the problem?
Crashed Thread: 2 KrollContext<kroll$1>
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000bbadbeef
Thread 2 Crashed:: KrollContext<kroll$1>
0 com.a 0x000000010082865e Ti_WTFCrash + 62
1 com.a 0x000000010069ffe9 TiObjectGetProperty + 361
2 com.a 0x00000001002c42e5 -[KrollObject objectForTiString:context:] + 101
3 com.a 0x00000001002bf6a5 KrollGetProperty + 165
4 com.a 0x0000000100656ef7 TI::JSCallbackObject<TI::JSDestructibleObject>::getOwnPropertySlot(TI::JSObject*, TI::ExecState*, TI::PropertyName, TI::PropertySlot&) + 487
5 com.a 0x00000001005e32aa TI::TiValue::get(TI::ExecState*, TI::PropertyName, TI::PropertySlot&) const + 362
6 com.a 0x00000001006f6ec0 llint_slow_path_get_by_id + 192
7 com.a 0x0000000100701711 llint_op_get_by_id + 98
8 com.a 0x0000000100703ae2 llint_op_call + 153
9 com.a 0x00000001006ffea5 callToJavaScript + 191
SIGSEGV errors occur when you try to use an object that already has been garbage collected. It's the equivalent of NullPointer errors on Android.
Seeing it has callToJavaScript as well would mean a native event or callback is not finding the JavaScript object anymore.
I'd advise to use the Appcelerator Studio debugger and step through the code to the moment it crashes.
Related
We are seeing a strange crash in our map based iOS app that I cannot figure out. Basically as some point the following lines of code repeat over and over, more than 100 times in crash log:
6 VectorKit 0x000000019050c6f8 __86-[VKMapCameraController _animateToPosition:pitch:yaw:duration:timingCurve:completion:]_block_invoke347 + 40
7 VectorKit 0x0000000190485a30 -[VKAnimation _stopAnimation:] + 140
8 VectorKit 0x0000000190488b20 -[VKMapCameraController setYaw:animated:] + 100
9 MapKit 0x000000018540263c -[MKMapView snapToNorth:] + 148
before finally calling:
0 CoreFoundation 0x0000000183251e38 _CFArrayReplaceValues + 152
1 CoreFoundation 0x000000018332876c __CFRepositionTimerInMode + 108
2 CoreFoundation 0x000000018332876c __CFRepositionTimerInMode + 108
3 CoreFoundation 0x0000000183272630 CFRunLoopTimerSetNextFireDate + 580
4 MapKit 0x00000001853e8588 -[MKMapView _didChangeRegionMidstream:] + 196
5 MapKit 0x0000000185404e90 -[MKMapView mapLayer:didChangeRegionAnimated:] + 60
where _CGArrayReplaceValues crashes with a EXC_BAD_ACCESS KERN_PROTECTION_FAILURE at 0x000000016fccbef0 error.
I'd like to point out we never directly call any of the methods in this crash report, in fact VectorKit is completely private Apple framework. The only thing we ever do in the app remotely related is call basic setRegion:animated: methods, usually after a user taps an annotation to center on said annotation. It is also worth pointing out this only happens on iOS 8. Not a single iOS 7 crash has been reported.
Here is a link for full crash report: http://crashes.to/s/f09eb96c753
Any help is appreciated. Thank you.
Try enabling NSZombieEnabled. Once enabled, when an object reaches a retain count of 0, instead of being deallocated it'll morph itself into an NSZombie instance. When a zombie receives a message it will log a warning rather than crashing or behaving in an unpredictable way.
To be quite honest i'm not really sure why this is only crashing on iOS 8 and not iOS 7 but a EXC_BAD_ACCESS signal is the result of passing an invalid pointer to a system call, so you might be dereferencing a null pointer somewhere.
If the above NSZombieEnabled doesn't uncover the issue then try using the Static Analyzer.
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.
We have crashes in our Unity iOS app.
We cannot reproduce them when debugging, but we regularly catch this crash.
We tried to analyze crash logs. (crash log is in the bottom of the post)
We examine part of code mentioned in crash log (m_Controller... methods), and cant see something that could cause crash.
We tried to imagine situations that can occurs in that part of code, but see nothing that can lead to crash. There are small* array of strings which is loadaed from disk, and modified.
We thinking of rewriting this part of code, but we afraid that otherp part of program can affect and lead to this crash, and that crash will remain after rewriting.
We tried to add try-catch block in this part of code and process situation when exception occurs gracefully (move user to our app's main menu), but we have to remove this block due to requirements
to our app.
Also, I think that crash occurs only (or at least much more frequent) in Ad-hoc build (which uses Release configuration in Xcode).
In parts of crash logs you can see mono_gc_out_of_memory in GC_malloc, which is looking very strange to me (I thought that iOS generates memory warning when memory is low, but possibly mono has its own constraints)
Also, there is another one or two crashes in this part of code with different crash logs (without mono_gc_out_of_memory, but ), but all of them occurs in methods of ArrayList ( ArrayList.Clear() in other situations).
Can you help us with this situation?
Can you give us any advice please on how should we deal with this crashes?
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000000e7ffdefe
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 MyApp 0x00f0e150 CrashedCheckBellowForHintsWhy() (CrashReporter.mm:73)
1 MyApp 0x00dcd888 m_wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 200
2 MyApp 0x01462eec mono_jit_runtime_invoke + 2152
3 MyApp 0x01504f24 mono_runtime_invoke + 132
4 MyApp 0x015050a8 mono_runtime_delegate_invoke + 128
5 MyApp 0x0150931c call_unhandled_exception_delegate + 340
6 MyApp 0x0150b230 mono_unhandled_exception + 328
7 MyApp 0x01473080 mono_handle_exception_internal + 952
8 MyApp 0x01473918 mono_handle_exception + 64
9 MyApp 0x0148f6d8 mono_arm_throw_exception + 184
10 MyApp 0x00e76ecc throw_exception + 44
11 MyApp 0x014b7f44 mono_gc_out_of_memory + 16
12 MyApp 0x0156a62c GC_generic_malloc + 452
13 MyApp 0x0156a6cc GC_malloc + 140
14 MyApp 0x015045fc mono_array_new_specific + 272
15 MyApp 0x00dd27ac m_wrapper_managed_to_native_object___icall_wrapper_mono_array_new_specific_intptr_int + 68
16 MyApp 0x00b7b2b8 m_System_Collections_ArrayList_InsertRange_int_System_Collections_ICollection + 212
17 MyApp 0x00b7b898 m_System_Collections_ArrayList_AddRange_System_Collections_ICollection + 52
18 MyApp 0x001fc3fc m_Controller_PrepareSkins_string_string_string_string_string_string_string__ + 1600
19 MyApp 0x001fda88 m_Controller_Awake + 4972
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).
I've been getting some low level crashes lately, and this one in particular is hard to determine the origin / state of the app. Has anyone seen this or know the problem? Thanks!
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x3dcccccd
Crashed Thread: 0
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x3dcccccd
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x000025fa objc_msgSend + 18
1 UIKit 0x00162d1c -[UIAlertView(Private) _performPopup:] + 12
2 UIKit 0x001628de -[UIAlertView(Private) _repopup] + 10
3 UIKit 0x0016d196 -[UIAlertView(Private) _removeAlertWindowOrShowAnOldAlert] + 70
4 UIKit 0x00162afa -[UIAlertView(Private) _popoutAnimationDidStop:finished:] + 502
5 UIKit 0x00050ae4 -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 184
6 UIKit 0x000509ee -[UIViewAnimationState animationDidStop:finished:] + 34
7 QuartzCore 0x0002ee8c run_animation_callbacks(double, void*) + 284
8 QuartzCore 0x0002ed2c CA::timer_callback(__CFRunLoopTimer*, void*) + 96
9 CoreFoundation 0x00022d1c CFRunLoopRunSpecific + 2092
10 CoreFoundation 0x000224da CFRunLoopRunInMode + 42
11 GraphicsServices 0x000030d4 GSEventRunModal + 108
12 GraphicsServices 0x00003180 GSEventRun + 56
13 UIKit 0x0000342a -[UIApplication _run] + 374
14 UIKit 0x00001954 UIApplicationMain + 636
15 iPadDrinkHub.1.0.7 0x00002f24 0x1000 + 7972
16 iPadDrinkHub.1.0.7 0x00002ed8 0x1000 + 7896
Weird crashes are sometimes a symptom of memory corruption and/or mismanagement. I just found and fixed a difficult-to-find bug in one of my apps a few days ago. The app had been working flawlessly for 6 months on iOS 3.2, but would crash instantly on iOS 4.2. The crash was happening while adding the main view to the window during applicationDidFinishLaunching. The stack trace showed 100% iOS code; there wasn't a single function of mine in there anywhere (except for applicationDidFinishLaunching). It turned out I was over-releasing a UIImage in code that had been called earlier while views were getting loaded. (I was mistakenly calling release on an autoreleased UIImage).
I haven't seen the specific crash that you're seeing, but here are a few things you can try that may shed some light:
(1) Run the app with NSZombieEnabled. This is an environment variable you set via Xcode that will often identify places where you may be referencing objects that have already been freed (e.g., like the over-release example I mentioned earlier). Additional details are here:
http://www.cocoadev.com/index.pl?NSZombieEnabled
(2) You can turn on logging that will log all messages sent to all objects. The log is a written to a text file in the tmp folder. If you inspect the log file leading up to the crash, you may gain some insight into what's happening right before the crash. This is actually the technique I used to solve my bug. You can either modify your code to enable/disable logging:
instrumentObjcMessageSends(YES);
// Do stuff...
instrumentObjcMessageSends(NO);
Or, you can call the function directly from the debugger. For example, set a breakpoint right before the crash, then drop into the debugger console and do this:
(gdb) call (void)instrumentObjcMessageSends(YES)
Additional details are here:
http://www.dribin.org/dave/blog/archives/2006/04/22/tracing_objc/