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
Related
Our iOS app, which was working normally under earlier iOS versions, now has an exception at startup in iOS 16.
Thread 1: EXC_BAD_ACCESS (code=1, address=0x1176aca60)
But this is only visible when debugging; if I run it directly on device, it appears to run fine. Still a problem because we cannot debug our app.
There is very little information available, but this is the call stack, none of which is our code. I stepped through a lot of our startup code without noticing any problems.
Thread 1 Queue : com.apple.main-thread (serial)
#0 0x0000000183aa3518 in objc_release ()
#1 0x0000000183aa15d8 in AutoreleasePoolPage::releaseUntil(objc_object**) ()
#2 0x0000000183aa4f40 in objc_autoreleasePoolPop ()
#3 0x00000001a0061aec in -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] ()
#4 0x00000001a009cd3c in __92-[FBSWorkspaceScenesClient createSceneWithIdentity:parameters:transitionContext:completion:]_block_invoke ()
#5 0x000000010900e04c in _dispatch_client_callout ()
#6 0x0000000109011ac8 in _dispatch_block_invoke_direct ()
#7 0x00000001a006bf2c in FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK ()
#8 0x00000001a006bac8 in -[FBSSerialQueue _targetQueue_performNextIfPossible] ()
#9 0x00000001a006e2a8 in -[FBSSerialQueue _performNextFromRunLoopSource] ()
#10 0x000000018a7be22c in CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION ()
#11 0x000000018a7ca614 in __CFRunLoopDoSource0 ()
#12 0x000000018a74e57c in __CFRunLoopDoSources0 ()
#13 0x000000018a763eb8 in __CFRunLoopRun ()
#14 0x000000018a7691e4 in CFRunLoopRunSpecific ()
#15 0x00000001c3589368 in GSEventRunModal ()
#16 0x000000018cc18d88 in -[UIApplication _run] ()
#17 0x000000018cc189ec in UIApplicationMain ()
#18 0x0000000101d76580 in main at /Users/aaronl/engine-johnsonville/src/platform/ios/main.mm:8
#19 0x00000001a8a8d948 in start ()
Turning on some Xcode debug flags showed the following message:
2022-10-13 16:33:49.020927+1300 umajin_viewer[1297:357539] *** -[CaptureMTLCaptureScope release]: message sent to deallocated instance 0x280aafb40
The app is a combination of Objective-C and C++, and has Vulkan graphics rendering on top of Metal. All this was working well up till now.
I'm looking for any clues on how to find out what is going wrong!
Eventually we were able to confirm that this was a problem in MoltenVK, the implementation of Vulkan on top of Metal for iOS and Mac. It was releasing something that Apple expects to be autoreleased (MTLCaptureScope)? Because it wasn't our code we couldn't see into it. Upgrading to the latest solved this.
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 :))
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.
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: