I got a high amount of crash reports for an app via XCode Organizer / Crashes tab
However the stack trace does not show any exception type, just point to a recursive method run in a background thread (via dispatch_async) (and no it's not infinite recursion, it's a search method with limited depth). I have no clue to figure out why this crash occurs. I try to reproduce the crash in real devices but cannot. Could this be an intensive cpu task and gets killed by the OS? How do I verify if that is the case? Any help would be appreciate!
#0 (null) in _TFC11MyAppFree17SearcherP33_D7BE9E167FAD2091BF2475359F0659466searchfS0_FTSi5aSi4bSi_Si ()
#1 (null) in _TFC11MyAppFree17SearcherP33_D7BE9E167FAD2091BF2475359F0659466searchfS0_FTSi5aSi4bSi_Si at Searcher.swift:115
#2 (null) in _TFC11MyAppFree17SearcherP33_D7BE9E167FAD2091BF2475359F0659466searchfS0_FTSi5aSi4bSi_Si at Searcher.swift:115
#3 (null) in _TFC11MyAppFree17SearcherP33_D7BE9E167FAD2091BF2475359F0659466searchfS0_FTSi5aSi4bSi_Si at Searcher.swift:115
#4 (null) in _TFC11MyAppFree17SearcherP33_D7BE9E167FAD2091BF2475359F0659466searchfS0_FTSi5aSi4bSi_Si at Searcher.swift:115
#5 (null) in _TFC11MyAppFree17SearcherP33_D7BE9E167FAD2091BF2475359F0659466searchfS0_FTSi5aSi4bSi_Si at Searcher.swift:115
#6 (null) in _TFC11MyAppFree17SearcherP33_D7BE9E167FAD2091BF2475359F0659466searchfS0_FTSi5aSi4bSi_Si at Searcher.swift:115
#7 (null) in _TFC11MyAppFree17SearcherP33_D7BE9E167FAD2091BF2475359F0659466searchfS0_FTSi5aSi4bSi_Si at Searcher.swift:115
#8 (null) in _TFC11MyAppFree17SearcherP33_D7BE9E167FAD2091BF2475359F0659466searchfS0_FTSi5aSi4bSi_Si at Searcher.swift:115
Related
I have developed a iOS keyboard and i am getting some wired error in my crash logs i have search in every where but i didn't find any solution. This is the error i am getting in my error console.
PlugInKit: -[PKService run] + 752
Here is screenshot of the error. can anyone tell me how can i solved this error. error log
#0 (null) in mach_msg_trap ()
#1 (null) in mach_msg ()
#2 (null) in __CFRunLoopServiceMachPort ()
#3 (null) in __CFRunLoopRun ()
#4 (null) in CFRunLoopRunSpecific ()
#5 (null) in GSEventRunModal ()
#6 (null) in UIApplicationMain ()
#7 (null) in _xpc_objc_main ()
#8 (null) in xpc_main ()
#9 (null) in -[NSXPCListener resume] ()
#10 (null) in -[PKService run] ()
#11 (null) in +[PKService main] ()
#12 (null) in +[PKService _defaultRun:arguments:] ()
#13 (null) in NSExtensionMain ()
#14 (null) in start ()
Looks like a problem with the memory.
From the documentation
Memory limits for running app extensions are significantly lower than
the memory limits imposed on a foreground app. On both platforms, the
system may aggressively terminate extensions because users want to
return to their main goal in the host app. Some extensions may have
lower memory limits than others: For example, widgets must be
especially efficient because users are likely to have several widgets
open at the same time.
Are you building an extension keyboard? Are you loading images there?
If you are loading images make sure to use lower resolution and check the color bitmap for each image (sometimes png uses 24bit). Try with jpeg images (you are gonna lose transparency but at least will work) so when you load them it won't take too much memory. For more info about PNG vs JPEG and memory concerns take a look at https://www.cocoanetics.com/2011/10/avoiding-image-decompression-sickness/
Open up the actual crash log file (right click / show in finder from Xcode) and post it here. It contains a lot more info such as exception type, notes and so on that will help you diagnose.
Read up a bit here to give you an idea of what you’ll find in the crash log and how to use it.
https://developer.apple.com/library/archive/technotes/tn2151/_index.html
(Just realized how old this post is, oh well :))
I am experiencing a problem with CoreData when an NSOperation that download stuff in the background is beeing deallocated.
I am using the nested managed object contexts and the context the operation uses has everything guarded in -[NSManagedObjectContext performBlock:]
However, around the time the operation is beeing deallocated, I get a crash with the following stack:
#0 0x022d9098 in objc_msgSend ()
#1 0x00bfb903 in _PFObjectIDFastHash64 ()
#2 0x029fbdb0 in __CFDictionaryHashKey ()
#3 0x029e13e2 in CFBasicHashFindBucket ()
#4 0x029e0e2d in CFDictionaryGetValue ()
#5 0x00c0a408 in -[NSPersistentStoreCache incrementRefCountForObjectID:] ()
#6 0x00c0a37e in -[NSSQLCore managedObjectContextDidRegisterObjectsWithIDs:] ()
#7 0x00cd378c in -[NSPersistentStoreCoordinator(_NSInternalMethods) _informAffectedStoresOfInterestByChildContextInObjectsWithObjectIDs:withSelector:] ()
#8 0x00c0a29f in -[NSPersistentStoreCoordinator(_NSInternalMethods) managedObjectContextDidRegisterObjectsWithIDs:] ()
#9 0x00cb41db in __95-[NSManagedObjectContext(_NestedContextSupport) managedObjectContextDidRegisterObjectsWithIDs:]_block_invoke_0 ()
#10 0x00c39cc1 in internalBlockToNSManagedObjectContextPerform ()
#11 0x025af014 in _dispatch_client_callout ()
#12 0x0259ed5f in _dispatch_barrier_sync_f_invoke ()
#13 0x0259eaa3 in dispatch_barrier_sync_f ()
#14 0x00c39c8b in _perform ()
#15 0x00c3a6e9 in -[NSManagedObjectContext(_NestedContextSupport) managedObjectContextDidRegisterObjectsWithIDs:] ()
#16 0x00cb41db in __95-[NSManagedObjectContext(_NestedContextSupport) managedObjectContextDidRegisterObjectsWithIDs:]_block_invoke_0 ()
#17 0x00c39cc1 in internalBlockToNSManagedObjectContextPerform ()
#18 0x025a0731 in _dispatch_barrier_sync_f_slow_invoke ()
#19 0x025af014 in _dispatch_client_callout ()
#20 0x0259f7d5 in _dispatch_main_queue_callback_4CF ()
#21 0x02a12af5 in __CFRunLoopRun ()
#22 0x02a11f44 in CFRunLoopRunSpecific ()
#23 0x02a11e1b in CFRunLoopRunInMode ()
#24 0x02dff7e3 in GSEventRunModal ()
#25 0x02dff668 in GSEventRun ()
#26 0x0120bffc in UIApplicationMain ()
#27 0x0000285d in main at /Users/mochs/Projects/12_IP_Lufthansa_Next/Lufthansa/Supporting Files/main.m:16
#28 0x00002785 in start ()
I really have no clue what's going on. What I know is:
I am using ARC
I am using nested managed object contexts
The operation schedules and executes stuff in a shared NSThread with its own runloop
The thread is shared and is not released when the operation is being deallocated
Shortly after -[NSOperation dealloc] the app crashes in the main thread
I fixed the same issue a couple of ours before with a [context reset] in the NSOperation's dealloc method. At this time the concurrency type was NSConfinementConcurrencyType and I didn't use performBlock:
Because of some changes I needed to change the concurrency type of the context to NSPrivateQueueConcurrencyType and make it use performBlock:, now the error is back.
I am pretty sure that the call to reset wasn't really solving the problem but instead just fixing the crash. I have no clue what really leads to such a crash.
Does anybody know what this error is about?
Best regards,
Michael
As far as I know Core Data isn't thread safe. On github you can find these extension that would make Core Data thread safe Adam Roth
Finally I found the issue. When saving all contexts up to the persistent store, is used a method saveToPersistentStore: that I used from RestKit, with some minor changes to match our requirements.
The following line, that should work as a fix on iOS5, caused the issue, at least on iOS6:
[contextToSave obtainPermanentIDsForObjects:[[contextToSave insertedObjects] allObjects] error:&localError];
I have to further investigate wether the issue only occurs on iOS6 (right know, we are not targeting something else) before I send them an issue request, but simply removing this line fixed the issue.
I have a crash that happens at least once a day that I really can't seem to put a finger on. It seems to happen to me at random moments and I can't trace the stack to understand why it happens. If anyone can point me in the proper direction or even show me some online documentation and tutorials on how I can properly trace values that would be perfect. The most that I understand is that something is trying to access an index in an array, but I can't figure out for the life of me what that array can be. I've included the information from the output window below:
2012-09-28 12:45:26.884 TestApp[1683:c07] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArrayM objectAtIndex:]: index 0 beyond bounds for empty array'
*** First throw call stack:
(0x1bdd052 0x19ccd0a 0x1bc9db8 0x29522 0x23e76 0x22bed 0x21e36 0xdfee 0xdba8 0xd3cc 0x1bdee72 0x13339ef 0x1bb197f 0x1b14b73 0x1b14454 0x1b13db4 0x1b13ccb 0x2692879 0x269293e 0xa1ba9b 0x2ded 0x2d25)
terminate called throwing an exceptionCurrent language: auto; currently objective-c
(gdb) bt
#0 0x98468a6a in __pthread_kill ()
#1 0x98554acf in pthread_kill ()
#2 0x9858b4f8 in abort ()
#3 0x021cbe78 in abort_message ()
#4 0x021c989e in default_terminate ()
#5 0x019ccf4b in _objc_terminate ()
#6 0x021c98de in safe_handler_caller ()
#7 0x021c9946 in std::terminate ()
#8 0x021cab3e in __cxa_rethrow ()
#9 0x019cce49 in objc_exception_rethrow ()
#10 0x01b13e10 in CFRunLoopRunSpecific ()
#11 0x01b13ccb in CFRunLoopRunInMode ()
#12 0x02692879 in GSEventRunModal ()
#13 0x0269293e in GSEventRun ()
#14 0x00a1ba9b in UIApplicationMain ()
#15 0x00002ded in main (argc=1, argv=0xbffff39c) at /Users/seb/Desktop/Development/main.m:14
You need to use the Xcode debugger:
Tap the Breakpoints button in the toolbar:
Tap the Breakpoints option in the left pane:
Tap the '+' button bottom left, and select 'Add Exception Breakpoint':
Tap done in the presented view, and you will see something like this (the top one is disabled):
insure your app scheme has lldb enabled:
I am getting the following index out of bounds error:
*** Terminating app due to uncaught exception 'NSRangeException', reason:
'*** -[__NSArrayM objectAtIndex:]: index 0 beyond bounds for empty array'
*** First throw call stack:
(0x2263052 0x24c7d0a 0x224fdb8 0x2f4a7 0x2264ec9 0x81e299 0x81e306 0x75aa30
0x75ac56 0x741384 0x734aa9 0x39a9fa9 0x22371c5 0x219c022 0x219a90a 0x2199db4
0x2199ccb 0x39a8879 0x39a893e 0x732a9b 0x1e5b 0x1dc5 0x1)
I know exactly what the error means, but I find these errors very difficult to fix because for some reason the call stack isn't telling me the line of code where the array was being called. Here is the call stack from thread 1:
#0 0x9706d9c6 in __pthread_kill ()
#1 0x93e2cf78 in pthread_kill ()
#2 0x93e1dbdd in abort ()
#3 0x02859e78 in dyld_stub__Unwind_DeleteException ()
#4 0x0285789e in default_terminate() ()
#5 0x024c7f4b in _objc_terminate ()
#6 0x028578de in safe_handler_caller(void (*)()) ()
#7 0x02857946 in __cxa_bad_typeid ()
#8 0x02858b3e in __cxa_current_exception_type ()
#9 0x024c7e49 in objc_exception_rethrow ()
#10 0x02199e10 in CFRunLoopRunSpecific ()
#11 0x02199ccb in CFRunLoopRunInMode ()
#12 0x039a8879 in GSEventRunModal ()
#13 0x039a893e in GSEventRun ()
#14 0x00732a9b in UIApplicationMain ()
#15 0x00001e5b in main
As you can see this call stack is not very helpful because it doesn't show any methods from my code. Also, the call stack shown in the error has 22 memory addresses, while the stack from thread 1 only has 15, and the addresses don't match at all. No other threads seem to contain any useful information.
How is it possible to see the thread of the "First throw call stack" from the error (the one with 22 addresses), so I can find the line causing this error? Perhaps I have something set incorrectly in my Build Settings that is causing the relevant stack to not be retrievable?
If someone could point me in the right direction on this I'd be very grateful. Trying to locate the offending line manually is quite tedious.
Thanks!
turn on the debugger and set a breakpoint on whenever an exception is thrown, this way you exactly know which line of code is being a jerk.
objc_exception_throw
Alternatively, [NSException raise];
Have a look at the following question: Add breakpoint to objc-exception-throw
Did you enable global breakpoints in your project?
if not add objc_exception_throw to the breakpoints section in the project navigator then re-run the app, you should get the stack. In adition, when you crash happends, watch and expand any additional threads to see their stacks as well. It happened to me several times that the stack i was searching was in a background thread, though the crash was being reported by the main thread. HTH.
Assuming this happened while in the XCode debugger, you can determine
the line of code referenced in the traceback addresses.
In the debug window, enter the following:
list *address from traceback
For example, for your first entry, you would enter the following:
list *0x2263052
Do this for each address. One of them should point to your programs code
and list the failing line number and code above and below the failing line.
-Steve
I am getting EXC_BAD_ACCESS error at the line
GADRequest *request = [[GADRequest alloc] init];
I don't have source code of GADRequest as its from Google AdMob SDK.
The stack trace is below.
Its happening only on device and not on simulator.
#0 0x34a80462 in objc_msgSend ()
#1 0x0017d9dc in +[GADRequest alloc] (self=<value temporarily unavailable, due to optimizations>, _cmd=<value temporarily unavailable, due to optimizations>) at /Users/mikeying/work/ios_sdk_git/googlemac/iPhone/GoogleAds/NextGen/Request/GADRequest.m:48
#2 0x0006e728 in -[AdWhirlAdapterGoogleAdMobAds getAd] (self=0x5511c0, _cmd=0x225209) at /Users/xxx/yyy/libs/AdWhirl/adapters/AdWhirlAdapterGoogleAdMobAds.m:68
#3 0x0007b4f6 in -[AdWhirlView makeAdRequest:] (self=0x5538f0, _cmd=0x22691c, isFirstRequest=1 '\001') at /Users/xxx/yyy/libs/AdWhirl/internal/AdWhirlView.m:370
#4 0x0007ac5c in -[AdWhirlView buildPrioritizedAdNetCfgsAndMakeRequest] (self=0x5538f0, _cmd=0x226965) at /Users/xxx/yyy/libs/AdWhirl/internal/AdWhirlView.m:235
#5 0x35818bbe in -[NSObject(NSObject) performSelector:withObject:] ()
The program receives the EXC_BAD_ACCESS signal when a message is sent to an object that has been deallocated. With the environment variable NSZombieEnabled set to YES, objects are never deallocated, but instead kept in memory as zombie objects. When a message is sent to a zombie object, execution stops at the line that would normally cause the EXC_BAD_ACCESS signal.
In Xcode 4.2, you could set environment variables by editing scheme, select the “Run XYZ.app” stage in the left panel, then select the “Arguments” tab on the right.
It’s important that you disable NSZombieEnabled once you’re done, or your application would use a tremendous amount of memory and eventually would crash.