Exactly 60 seconds after launching my app it crashes with an uncaught exception:
libc++abi.dynlib: terminating app due to uncaught exception of type NSException
*** Terminating app due to uncaught exception of type 'NSInvalidArgumentException', reason: '*** -[__NSDictionaryM setObject:forKey:]: object cannot be nil (key: BundleVersion)'
The crashing thread has a random number (it is #7 in the attached screenshot) and it is always created for an unknown to me queue glmtl.telemetry.
The crash occurs only on one device (iPhone 11 Pro Max) and iOS 14.0 (it was then replicated with iOS 14.0.1).
I am not using in the project anywhere a key "BundleVersion". (There is CFBundleVersion in the info.plist, but does not seem to be related).
Can this be caused by the project sources?
This is not an explanation of the issue but the crash stopped appearing after adding a group of missing resource files to a folder (not a group but a folder) in the bundle.
Fix
I am having the same issue. In my case, I needed to add CFBundleVersion to the project's Info.plist since the exception mentions the "BundleVersion" key and because I recalled seeing XCode complain about invalid bundles when that key is missing.
My guess is that those recommended CFBundle* keys should be set for the main project's Info.plist and any embedded framework or projects with their own Info.plist. I'm just surprised XCode 12 doesn't raise that error right now at build time.
Source of the issue (?)
Do you use OpenGL in your app? I could not find what glmtl is, but it seems that the crash occurs exactly 1 minute after I instantiate a new OpenGL context. The crash will still occur after 1 minute if I delete the context before that, but it will be delayed another minute if I create a new instance in between.
I am getting a message in my debugger:
The LLDB RPC server has crashed. The crash log is located in ~/Library/Logs/DiagnosticReports and has a prefix 'lldb-rpc-server'. Please file a bug and attach the most recent crash log.
In my case the LLDB RPC server consistently crashed every time I ran my app, even after cleaning the build folder and removing and reinstalling Xcode (Version 8.3.3 (8E3004b)) completely.
It turned out that apparently LLDB took objection to a breakpoint I had set, just moving this breakpoint by a line resolved the issue.
Make sure you are not running the app in release mode, if it is in release mode then change it to debug.
In my case: I update to Xcode Version 9.3 (9E145) recently and Xcode execute to the line with breakpoint then I type "po XXX" commend it will show the same message.
I try to delete following files
~/Library/Preferences/com.apple.dt.Xcode.plist
~/Library/Caches/com.apple.dt.Xcode
and it solved.
not knowing exactly why but worth to try.
remember to backup those files in order to recovered in case any unexpected situation occur.
I had the same problem and fixed it after I deleted some of the breakpoints. Not sure why this happen at all, but at least you can remove breakpoints and use some NSLog() or print() if you are in Swift and debug with the help of those. Good luck!
Clearly a lot of different causes for this, but for me I was using a DispatchGroup to keep track of multiple async tasks.
I had forgotten to call dispatchGroup.enter() before one of the async tasks (but still calling dispatchGroup.leave() when it finished).
Adding this in fixed the crash for me.
If workspace has lots of breakpoint then it will happen, So try to remove all the break point and see the magic.
For me just restarting the simulator worked.
I found the solution to this issue. I don't know is this correct or not, but this solution is work for me. what I did is Actually I connected two devices to my mac mini, in one device I run the app and get the above error in my console. Then I removed one device and tried, this time I didn't get any error in my console its worked fine. I think you guys won't believe this, I tried Almost 3 time with two devices and one device its only work for one device
This error occurs for different reasons and the main one is when you add a watch app later to your project where Xcode adds an extra build target to scheme. click on scheme section in right side of "run/stop buttons" then hit on edit scheme, hit on Build section which is the first one, There you see 2 targets one has 2 sub targets which includes watch app and watch extension in it and the other one has no sub targets and it is a watch app target.
Solution is simple delete the watch app target which has no sub targets and run the app again.
For me, I had an expression in my watch list that it was barfing on. When looking at the crash logs in Console, there was something like this on the reported crashed thread which gave it away:
lldb_private::EvaluateExpressionOptions const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, lldb_private::ValueObject*) + 619
17 com.apple.LLDB.framework 0x0000000102855f18 lldb::SBFrame::**EvaluateExpression**(char const*, lldb::SBExpressionOptions const&) + 696
18 lldb-rpc-server 0x00000001025e72e9 rpc_server::_ZN4lldb7SBFrame18EvaluateExpressionEPKcRKNS_19SBExpressionOptionsE::HandleRPCCall(rpc_common::Connection&, rpc_common::RPCStream&, rpc_common::RPCStream&) + 169
19 lldb-rpc-server 0x00000001025f8ce1 rpc_common::Connection::PrivateHandleRPCPacket(rpc_common::RPCPacket&, rpc_common::RPCPacket&, bool&) + 1553
20 lldb-rpc-server 0x00000001025fc36d Packets::ProcessPackets() + 1005
21 lldb-rpc-server 0x00000001025fbe96 Packets::ReadThread() + 214
22 lldb-rpc-server 0x00000001025fbdb9 Packets::RunReadThread(void*) + 9
23 libsystem_pthread.dylib 0x00007fff6a586109 _pthread_start + 148
24 libsystem_pthread.dylib 0x00007fff6a581b8b thread_start + 15
I ran across this same error with zero idea of what to do next. I tried the accepted answer and my project didn't have any breakpoints at all.
Turns out I had an observer that I didn't remove and every few times I would push off/on the vc that contained it it would eventually crash with the op's error. I had to enable zombies to figure out which vc was causing the error. I had to manually go through the code line by line to realize I didn't remove the observer. Once I removed it everything worked fine.
// not removing this caused the error
playerItem?.addObserver(self, forKeyPath: #keyPath(AVPlayerItem.status),
options: [.old, .new],
context: &playerItemContext)
I have found a solution for this, this may not be the perfect but kind a fix my problem.
Go to target Build Settings -> Other Swift Flags -> check Debug Values added
Remove everything except $(inherited) and -DDEBUG
Remove Derived Data
Clean and Run
I am having this issue in Xcode 12.1.1 (12A7605b) in January 2021 on macOS Catalina with a Swift project.
I tried Clean, delete Derived data, restarting mac, running on different simulators and real devices - no luck.
Others suggest removing the breakpoint, but for me this breakpoint is needed for debugging (I guess I can figure out how to debug in a different way, with a differently placed breakpoint or with print statements, but that's frustrating).
I filed a bug report with Apple as the error message suggest - I urge others to do the same to increase the chance of a fix by Apple.
In the meanwhile I use this workaround - wrap the code where you want the breakpoint in a DispatchQueue.main.async:
DispatchQueue.main.async { [self] in
print("Put the breakpoint on this line")
}
(Note we use [self] here because it's just debug code, but in most cases these async calls need [weak self] to avoid retain cycles and memory leaks)
The problem I encountered was that the main project was objC, the Swift library introduced by Cococapods, and then crashed during breakpoint debugging of the Swift library
The solution
Add a swift class to the main project, name it at will, and do not need to add the bridge header file
Switch to project Settings, not Target Settings, and find build_setting
SWIFT_ACTIVE_COMPILATION_CONDITIONS adds a DEBUG as follows:
SWIFT_ACTIVE_COMPILATION_CONDITIONS
Debug Debug
Release
In my case. I'm also using SQLite.swift to create database. The crashing happened when I tried to change a column data type of an existing table in code(which was not in the right way to do it), then inserted a tuple with new data type, then tried to print all the tuple out.
Solution: Delete the .sqlite3 database file you have or delete the table with conflict data type and recreate them all.
I believe I'm looking at properly symbolicated logs, but please do tell me if that's not the case. This is an excerpt of a crash log I received from Apple after rejected due to a crash upon launch, which I have been entirely unable to replicate.
I installed a crash reporting system called Crashlytics which received no crash reports during the time the app was In Review, leading me to believe the crash occurs before AppDelegate's didFinishLaunchingWithOptions where Crashlytics is initialized. That said, Crashlytics only sends reports upon re-opening the app after a crash. So the Apple reviewer may have experienced a crash and didn't bother to attempt again, possible the reason I have no Crashlytics report.
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Triggered by Thread: 0
Last Exception Backtrace:
(0x181f9a084 0x1929ec0e4 0x180819674 0x100091318 0x100084fe4 0x100084098 0x18671d158 0x18671ce68 0x1867d0ee8 0x1869d1da8 0x186791938 0x18671e88c 0x1867906f8 0x10006187c 0x18678e5d0 0x1869a4de8 0x1869a7568 0x1869a5c00 0x18a171640 0x181f52360 0x181f51468 0x181f4fa8c 0x181e7d664 0x18678798c 0x186782984 0x100061c28 0x19305aa08)
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x0000000193172964 __kill + 8
1 Luff 0x00000001001330dc 0x10005c000 + 880860
2 libsystem_platform.dylib 0x0000000193208958 _sigtramp + 64
3 libsystem_pthread.dylib 0x0000000193211224 pthread_kill + 108
4 libsystem_c.dylib 0x00000001930eab14 abort + 108
5 libc++abi.dylib 0x00000001921d1414 abort_message + 112
6 libc++abi.dylib 0x00000001921f0b88 default_terminate_handler() + 300
7 libobjc.A.dylib 0x00000001929ec3bc _objc_terminate() + 124
8 libc++abi.dylib 0x00000001921edbb0 std::__terminate(void (*)()) + 12
9 libc++abi.dylib 0x00000001921ed738 __cxa_rethrow + 140
10 libobjc.A.dylib 0x00000001929ec290 objc_exception_rethrow + 40
11 CoreFoundation 0x0000000181e7d710 CFRunLoopRunSpecific + 568
12 UIKit 0x0000000186787988 -[UIApplication _run] + 548
13 UIKit 0x0000000186782980 UIApplicationMain + 1484
14 Luff 0x0000000100061c24 0x10005c000 + 23588
15 libdyld.dylib 0x000000019305aa04 start + 0
What you have is NOT fully symbolicated. In order to get it fully symbolicated, i.e. with the names for your functions on lines 14 and 1, and the last exception backtrace, you need the dSYM file which would have been generated when you built the app for submission and placed in the same folder as your app bundle. If you used Xcode's archive functionality, I believe the dSYM is included in the archive. I say lines 1 and 14 because those are the ones that have your app name on them (Luff).
What you need to do is put the crash report, dSYM file and app file (not the IPA) in the same folder (I'm not sure if the app file is actually necessary for Xcode to symbolicate, therefore make sure it is there if it doesn't work with just the crash report and dSYM). Then, import the crash report into the Xcode organizer and click "Re-symbolicate".
What you have above as it is right now is 100% useless without the dSYM, unless you can somehow map the addresses in the report to symbols (functions, methods).
Also, the stack trace of the crashed thread is not where the relevant info is. From experience, I can tell you a couple of things about that stack trace, though. The symbol on line 14 is most likely your main() function. Nothing special there.
The lines between 1 and 14 show a bunch of exception rethrow and catch, i.e. that is not the stack trace that led to the crash, but the stacktrace of the exception being passed around. Since you mentioned you have Crashlytics, I bet line 14 is just that. It says Luff and not Crashlytics because Crashlytics is a static library embedded into your app. For all intents and purposes, iOS sees it as just another part of your app. The reason I say it is Crashlytics is when you are catching crashes, the thing that caused the crash (exception, signal, etc.) is sometimes rethrown and it eventually reaches your own custom crash-reporting code.
The relevant info is in the Last Exception Backtrace addresses you have above. But to read that, it has to be symbolicated with the dSYM file.
Like you said, Crashlytics is not real-time. The user needs to reopen the app. I know all this because I'm working on my own project called Crashional which is real-time, provided there is an internet connection.
A possible reason that you did not get a report through Crashlytics is that the reviewer may have had internet disabled on the device when she first launched your app. Even if she opened it again, it would not have sent the crash back to Crashlytics.
(Draco has provided an excellent idea in the checked response below.)
This crash occurs in the program when a custom URL is handled by the app delegate, then an operation is started on another thread. Sometimes the operation finishes and I can see the results in the UI. But it is always crashing.
This only happens when running without the debugger. Here is the crash log:
0 libobjc.A.dylib 0x37d9ff7e objc_msgSend + 22
1 CoreData 0x3634bbd2 -[_PFManagedObjectReferenceQueue _processReferenceQueue:] + 934
2 CoreData 0x3634efd0 _performRunLoopAction + 196
3 CoreFoundation 0x359d2b14 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 12
4 CoreFoundation 0x359d0d50 __CFRunLoopDoObservers + 252
5 CoreFoundation 0x359d10aa __CFRunLoopRun + 754
6 CoreFoundation 0x3595449e CFRunLoopRunSpecific + 294
7 CoreFoundation 0x35954366 CFRunLoopRunInMode + 98
8 GraphicsServices 0x375f0432 GSEventRunModal + 130
9 UIKit 0x33460cce UIApplicationMain + 1074
10 myApp 0x000e2770 main (main.m:15)
11 myApp 0x000e2728 start + 32
It looks like its trying to respond to an event or, more specifically, a notification. If that's the case, I'm guessing that the tageted observer has been removed or the object it was added to has been deallocated.
Is there a way I can intercept notifications and have a look at what's in them? If I could, I can probably identify which observer is missing, or at least narrow it down.
Update added to address WrightsCS's point about All Exceptions breakpoint. These are both set to Break On Throw, all exceptions. (Break on catch doesn't work either.)
How does this work when there is no exception, no crash, while running in the debugger?
Update 2
Re-titled to provide a more general scope of searches by other users.
Was: "App crashes without debugger, but not with. What does the crash log tell me?"
This doesn't answer your explicit question, but it does answer the implied question:
"How do I debug a crash when the debugger won't crash and the crash log is lacking details?"
You can look at more than just the crash logs in XCode Organizer. Take a look at the Console output in the Organizer Devices section; look at the device that had the crash and click on Console. You should be able to see the debugging output from the NSLog statements there, even if it's not running with the debugger.
You can look at this in XCode while the application is running, even if the debugger is not running.
The console shows more than your application's output, so you will have to sift through it to see your applications outputs. You will see the application name on the corresponding lines.
You can do this with code compiled for Debug, Ad-Hoc, or Release. Try it with someone else's app. (Try it with Twitter. You will see some debug logging there. Try it with Safari. You might see your other suspended apps being killed by jetsam.)
You may not be able to see the line it crashed on, but you should be able to narrow it down by judiciously inserting some debug code.
Whenever I try to run a specific project / app from Xcode it crashes with the details in the backtrace (please see below).
All sorts of funny stuff is going on running this in Xcode.
First, deleting the app from the iPad simulator and then running it for the first time seems to be working 90% of the time. But then either the second or the third attempt running on the iPad simulator it crashes again.
Trying to run it on a iPad device always crash, not luck at all.
Another funny thing I noticed is that whenever I do manage to get it to run for a second time on the iPad simulator all my appearance code (colors etc.) define in my app delegate is gone...
The only clue I could gather from the backtrace is: target 'MyApp' has been asked for its build context but it does not belong to a project
So, I'm not sure wheter this is Xcode related or perhaps somthing with the workspace / project file since it only crashes on this very specific project. If it is a problem with my workspace or project file, does anybody know how to fix this?
I appreciate your help.
Backtrace details:
Application Specific Information:
ProductBuildVersion: 4E2002
ASSERTION FAILURE in /SourceCache/IDEXcode3ProjectSupport/IDEXcode3ProjectSupport- 1197/Xcode3Sources/XcodeIDE/Frameworks/DevToolsBase/pbxcore/Target.subproj/PBXTarget.m:4006
Details: target 'MyApp' has been asked for its build context but it does not belong to a project
Object: <PBXNativeTarget: 0x409f3d8c0>
Method: -targetBuildContext
Thread: <NSThread: 0x40a7d8a80>{name = (null), num = 51}
Hints: None
Backtrace:
0 0x000000010bbbbb9f -[IDEAssertionHandler handleFailureInMethod:object:fileName:lineNumber:messageFormat:arguments:] (in IDEKit)
1 0x000000010b070635 _DVTAssertionFailureHandler (in DVTFoundation)
2 0x000000010e18c505 -[PBXTarget targetBuildContext] (in DevToolsCore)
3 0x000000010e18fec4 -[PBXTarget(XCBuildables) buildDidFinishWithBuildLogRecorder:] (in DevToolsCore)
4 0x000000010e2fefe2 -[Xcode3TargetBuildableSnapshot buildForBuilderDidFinish:] (in DevToolsCore)
5 0x000000010b6bb668 -[IDEBuildableSnapshot performBuildForBuilder:buildCommand:buildOnlyTheseFiles:] (in IDEFoundation)
6 0x000000010b6bada6 -[IDEBuilder main] (in IDEFoundation)
7 0x00007fff95e8b6b4 -[__NSOperationInternal start] (in Foundation)
8 0x00007fff95e9e912 ____NSOQSchedule_block_invoke_2 (in Foundation)
9 0x00007fff96d6da86 _dispatch_call_block_and_release (in libdispatch.dylib)
10 0x00007fff96d6e965 _dispatch_worker_thread2 (in libdispatch.dylib)
11 0x00007fff8f67c3da _pthread_wqthread (in libsystem_c.dylib)
12 0x00007fff8f67db85 start_wqthread (in libsystem_c.dylib)
objc[31243]: garbage collection is ON
abort() called
So I finally figured out what the problem was.
I was using a build script that bumped my build number (CFBundleShortVersionString) after each build.
It seems Xcode doesn't like the fact that the plist file gets changed underneath it.
The only "workaround" I could come up with was to remove the build step containing my version bump script that changed that plist file on every build.
Have faced with that about hour and I haven't auto-increasing build number script. If you are trying to delete target by right-click make sure that this target is closed, even at tab where you are deleting. Select another one and right-click to delete needed target.
Hope it helps