If you need help investigating a crash, please include a crash report in your post. To smooth things along, follow these guidelines:
For information on how to get a crash report, see Acquiring crash reports and diagnostic logs.
Include the whole crash report as a text attachment (click the paperclip icon and then choose Add File). This avoids clogging up the timeline while also preserving the wealth of information in the crash report.
If you’re not able to post your crash report as an attachment, see Can’t Post Crash Report as Attachment below.
If you want to highlight a section of the report, include it in the main body of your post. Put the snippet in a code block so that it renders nicely. To create a code block, add a delimiter line containing triple backquotes before and after the block, or just click the Code Block button.
If possible, post an Apple crash report. Third-party crash reporters are often missing critical information and have general reliability problems (for an explanation as to why, see Implementing Your Own Crash Reporter).
Symbolicate your crash report before posting it. For information on how to do this, see Adding identifiable symbol names to a crash report.
If you need to redact the crash report, do so consistently. Imagine you’re building the WaffleVarnish app whose bundle ID is com.example.wafflevarnish but you want to keep your new waffle varnishing technology secret. Replace WaffleVarnish with WwwwwwVvvvvvv and com.example.wafflevarnish with com.eeeeeee.wwwwwwvvvvvvv. This keeps the text in the crash report aligned while making it possible to distinguish the human-readible name of the app (WaffleVarnish) from the bundle ID (com.example.wafflevarnish).
Finally, for information on how to use a crash report to debug your own problems, see Diagnosing issues using crash reports and device logs.
Can’t Post Crash Report as Attachment
Crash reports have two common extensions: .crash and .ips. DevForums lets you attach the first but not the second (r. 117468172). To work around this, change the extension to .txt.
If DevForums complains that your crash report “contains sensitive language”, leave it out of your initial post and attach it to a reply. That often avoids this roadblock.
If you still can’t post your crash report, upload it to a file sharing service and include the URL in your post. Post the URL in the clear, per tip 14 in Quinn’s Top Ten DevForums Tips.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Revision History:
2024-05-21 Added some advice regarding the “contains sensitive language” message.
2023-10-25 Added the Can’t Post Crash Report as Attachment section. Made other minor editorial changes.
2021-08-26 First posted.
Debugging
RSS for tagDiscover and resolve issues with your app.
Posts under Debugging tag
200 Posts
Sort by:
Post
Replies
Boosts
Views
Activity
General:
DevForums tags: Debugging, LLDB, Graphical Debugger
Xcode > Debugging documentation
Diagnosing memory, thread, and crash issues early documentation
Diagnosing issues using crash reports and device logs documentation
Choosing a Network Debugging Tool documentation
Testing a release build documentation
Isolating Code Signing Problems from Build Problems DevForums post
What is an exception? DevForums post
Language Exception from RCTFatal DevForums post
Standard Memory Debugging Tools DevForums post
Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem DevForums post
Posting a Crash Report DevForums post
Creating a test project DevForums post
Implementing Your Own Crash Reporter DevForums post
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
I have to guess which command queue is the one I want to debug in Xcode here:
I have label set, but it doesn't seem to affect this part of Xcode.
Could someone help me with a good direction on where or how could I fix for this crash from console log:
Not able to open storyboard or XIB.
Once opening them, Xcode is crashing.
tried uninstalling the Xcode, couldn't fix even after deleting derived data and caches.
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------
Incident Identifier: 7E6D64FF-D4E9-4E3A-A37A-BC5016316DCD
CrashReporter Key: 4776E37C-4D3D-F705-40D5-8A96EE95C89A
Hardware Model: Mac15,6
Process: IBAgent-iOS [31688]
Path: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Library/Xcode/Overlays/IBAgent-iOS
Identifier: IBAgent-iOS
Version: 16.0 (23506)
Code Type: ARM-64 (Native)
Role: Unspecified
Parent Process: launchd_sim [31680]
Coalition: com.apple.CoreSimulator.SimDevice.178E8D7E-176F-4B7F-8956-D26C5EF7323A [5165]
Responsible Process: SimulatorTrampoline [1185]
Date/Time: 2024-11-06 14:59:29.3079 +0530
Launch Time: 2024-11-06 14:59:28.9368 +0530
OS Version: macOS 15.1 (24B83)
Release Type: User
Report Version: 104
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x0000000102e1e19c
Termination Reason: SIGNAL 5 Trace/BPT trap: 5
Terminating Process: exc handler [31688]
Triggered by Thread: 0
Application Specific Information:
Abort Cause 259
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_platform.dylib 0x102e1e19c _os_unfair_lock_recursive_abort + 36
1 libsystem_platform.dylib 0x102e19504 _os_unfair_lock_lock_slow + 304
2 libGSFont.dylib 0x19045ebb4 GSFontFileDescriptorForPath + 28
3 libFontParser.dylib 0x19047d714 TFileDescriptorContext::TFileDescriptorContext(char const*) + 216
4 libFontParser.dylib 0x19057c7e4 TFileDataReference::Map(char const*) + 36
5 libFontParser.dylib 0x19047d514 TFileDataReference::TFileDataReference(char const*) + 88
6 libFontParser.dylib 0x19057c934 TFileDataSurrogate::TFileDataSurrogate(char const*, timespec) + 152
7 libFontParser.dylib 0x1905cbaac TFont::CreateFontEntitiesForFile(char const*, timespec, bool, short, char const*) + 580
8 libFontParser.dylib 0x19047d1e0 FPFontCreateFontsWithPath + 200
9 CoreGraphics 0x18b612c54 create_private_data_array_with_path + 16
10 CoreGraphics 0x18b2cddd4 CGFontCreateFontsWithPath + 36
11 CoreGraphics 0x18b3389b0 CGFontCreateFontsWithURL + 680
12 libGSFont.dylib 0x190465518 AddFontsFromURLOrPath + 288
13 libGSFont.dylib 0x19045ffb4 RegisterURLAndCopyFaces + 168
14 libGSFont.dylib 0x19045fefc GSFontRegisterURL + 76
15 CoreText 0x181c5e0b8 _CTFontManagerRegisterActionFontsForURLs(__CFArray const*, CTFontManagerScope, bool, Action, __CFArray const**) + 396
16 IBCocoaTouchToolFoundation 0x10307e748 +[UIFont(IBCocoaTouchToolIntegration) ib_registerFontsAtURLs:] + 336
17 AssetCatalogFoundation 0x1033e1a88 __80-[IBMessageReceiveChannel deliverMessage:toTarget:withArguments:context:result:]_block_invoke + 196
18 AssetCatalogFoundation 0x1033e191c -[IBMessageReceiveChannel deliverMessage:toTarget:withArguments:context:result:] + 328
19 AssetCatalogFoundation 0x1033e14bc __88-[IBMessageReceiveChannel runBlockingReceiveLoopNotifyingQueue:notifyingTarget:context:]_block_invoke + 100
20 libdispatch.dylib 0x180178de0 _dispatch_client_callout + 16
21 libdispatch.dylib 0x180188bc8 _dispatch_async_and_wait_invoke + 112
22 libdispatch.dylib 0x180178de0 _dispatch_client_callout + 16
23 libdispatch.dylib 0x180187c60 _dispatch_main_queue_drain + 1272
24 libdispatch.dylib 0x180187758 _dispatch_main_queue_callback_4CF + 40
25 CoreFoundation 0x18041b2dc __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
26 CoreFoundation 0x180415838 __CFRunLoopRun + 1944
27 CoreFoundation 0x180414c24 CFRunLoopRunSpecific + 552
28 Foundation 0x180f319c8 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 208
29 AssetCatalogFoundation 0x1033bdc00 -[IBAbstractPlatformTool startServingReceiveChannel:] + 292
30 AssetCatalogFoundation 0x1033bddf4 -[IBAbstractPlatformTool startServingWriteDescriptor:readDescriptor:] + 96
31 AssetCatalogFoundation 0x1033be718 +[IBAbstractPlatformTool main] + 800
32 IBAgent-iOS 0x102b77930 main + 32
33 dyld_sim 0x102b89410 start_sim + 20
34 dyld 0x102c96274 start + 2840
Our app experience the strange crash,causing the app to not launch.This crash suddenly began to happen on October 25. At present, all the Hardware Model of mobile phones that occurred were on iPhone17,1 and the iOS system version was iOS18.0.1. This crash was all from users on the appstore, and was collected via Xcode - Organizer - > Crashes. I've attached the crash report.Thanks
Distributor ID: com.apple.AppStore
Hardware Model: iPhone17,1
Process: XxxxxxXXX [31230]
Path: /private/var/containers/Bundle/Application/6E9E07EA-B7A4-4D57-B419-743DDCF7C3A6/XxxxxxXXX.app/XxxxxxXXX
Identifier: com.XxxxxxXXX.XxxxxxXXX
Version: 8.1.10 (811001)
AppStoreTools: 16A242d
AppVariant: 1:iPhone17,1:18
Code Type: ARM-64 (Native)
Role: unknown
Parent Process: launchd [1]
Coalition: com.XxxxxxXXX.XxxxxxXXX [8069]
Date/Time: 2024-10-31 03:30:38.7437 +0800
Launch Time: 2024-10-31 03:30:38.7415 +0800
OS Version: iPhone OS 18.0.1 (22A3370)
Release Type: User
Baseband Version: 1.00.00
Report Version: 104
Exception Type: EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: GUARD 5
Triggered by Thread: 0
Thread 0 Crashed:
0 dyld 0x00000001b2da32b0 lsl::PreallocatedAllocatorLayout<278528ull>::init(char const**, char const**, void*) + 436 (Allocator.h:537)
1 dyld 0x00000001b2d9ca38 start + 1960 (dyldMain.cpp:1289)
Thread 0 crashed with ARM Thread State (64-bit):
x0: 0x2010003030100000 x1: 0x0000000fffffc0d0 x2: 0x0000000000000002 x3: 0x00000001b2d717ab
x4: 0x0000000000000000 x5: 0x0000000000000000 x6: 0x0000000000000000 x7: 0x0000000000000000
x8: 0x2010003030100000 x9: 0x2010003030100000 x10: 0x000000016d1dbdfb x11: 0x00000001b2dddf30
x12: 0x0000000000000050 x13: 0x0000000000000044 x14: 0x0000000000052010 x15: 0x0000000000000000
x16: 0x0000000000000000 x17: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x000000018a7e0000
x20: 0x000000016d1dbb30 x21: 0x000000016d1dbad0 x22: 0x00000001f0794050 x23: 0x000000016d1db7b8
x24: 0x0000000fffffc10c x25: 0x0000000000000000 x26: 0x0000000000000000 x27: 0x0000000000000000
x28: 0x0000000000000000 fp: 0x000000016d1db850 lr: 0x00380001b2da3130
sp: 0x000000016d1db7b0 pc: 0x00000001b2da32b0 cpsr: 0x60000000
esr: 0x92000047 (Data Abort) byte write Translation fault
Binary Images:
0x102c24000 - 0x1056d3fff main_executable_path_missing arm64 <086a82c13b863f4485895baddc3144ba> /main_executable_path_missing
0x1b2d69000 - 0x1b2dec693 dyld arm64e <5db839882ee63756bd07b8d67b1133a5> /usr/lib/dyld
EOF
2024-10-26_17-41-58.4222_+0800-841f6bdf4b2d436606ce55595ffc94d64e9af744.crash
2024-10-26_19-44-40.1115_+0800-7d4d654c76a10108b431acc612d6063b1edb1c3e.crash
2024-10-27_17-12-02.4926_+0800-6a4b6ec4cff928cf746162b9371a3176c3667c21.crash
2024-10-28_21-42-02.6780_+0800-c66c71c13414e7ff14ba783c883730c1361523b5.crash
2024-10-29_05-47-00.3943_+0800-ac7c1f5b6caf9aa97d71744a8f980c32d47eab80.crash
2024-10-31_03-30-38.7437_+0800-e1c54dc8879f97932cbb1520a04210bea6d7aaf4.crash
2024-11-03_07-57-18.8892_+0800-c7704569afc79ce50ac10b66e185de87425b1969.crash
2024-11-03_08-27-19.0514_+0800-c069e2f8dfa6767b8e301513aff3c3a7ea331e2c.crash
I encountered a crash in iOS 17 related to CLBackgroundActivitySession, which appears to be due to misleading guidance in an Apple’s WWDC video.
Crash sample code: https://github.com/steve-ham/AppleLocationCrash
Simplified Reproduction Steps:
1. Open the GitHub sample app.
2. Archive and export (Distribute App -> Custom -> (Release Testing, Enterprise, or Debugging) -> Export).
3. Open the app.
4. Tap enableBackgroundLocation -> select Allow While Using App on the system popup.
5. Tap disableBackgroundLocation.
6. Go to the iOS home screen.
7. Wait for 10 seconds.
8. Reopen the app -> crash occurs.
The crash happens because setting CLBackgroundActivitySession to nil does not end the session, despite Apple’s guidance suggesting it should. Below is the exact quote from WWDC 2023, which explicitly states that both calling invalidate() or letting the object get destroyed (i.e., setting to nil) would end the session:
WWDC 2023 Discover Streamlined Location Updates (https://developer.apple.com/videos/play/wwdc2023/10180/)
“Before starting the updates, you should instantiate a CLBackgroundActivitySession object to start a new session. Note, we are assigning the session to self.backgroundActivity, which is a property and not to a local variable. And this is important because if we used a local variable, then when it goes out of scope, the object it holds would be deallocated, invalidating the session and potentially ending your app’s access to location. Then when we want to end our session, we can do that by sending the invalidate message or by letting the object be destroyed.”
I’ve submitted this to Apple for resolution but wanted to share this with the community. This misguidance has caused issues in my app’s release. If Apple could reply to confirm or provide clarification, it would be greatly appreciated.
P.S. Even a minimal implementation in viewDidLoad triggers the crash:
let session = CLBackgroundActivitySession()
print("session (session)")
The app exits immediately on startup, there is no crash message, and I can't get any valuable diagnostic information. It doesn't even get to the main function. It feels like exit is being called somewhere, and then I used atexit to register the relevant handler. Finally, I found the following stack printout
It looks like it's a dynamic linking issue, so what's the best way to troubleshoot it. This problem only occurs in release versions.
I'm trying to add an iMessage extension to my app, and upon adding the iMessage App Icon set, I ran into an issue with one specific icon size: 1024x768px, aka 1x 1024x768pt.
When I remove this one icon from the icon set, it compiles and runs fine, however I can't push it to the App Store as I get the error: "Asset validation failed. Missing Image Asset. Your app is missing the Large App Icon asset 'AppIcon' in 'Payload/Runner.app/PlugIns/MessagesExtension.appex'." I'm assuming this refers to 1024x768px, as this size placeholder appears upon adding a New Messages Extension Icon to my assets folder, and 1024x1024 is already included and compiles fine with it.
However, when I add the 1024x768 icon, and try to run the app, I get the error: "Command CompileAssetCatalog failed with a nonzero exit code"
The app icon's filename is correct, it is exactly 1024x768 px, and my contents.json correctly includes :
{
"filename" : "AppIcon_1024x768.png",
"idiom" : "ios-marketing",
"platform" : "ios",
"scale" : "1x",
"size" : "1024x768"
}
as is the same format for all of my other icons that work.
Why am I running into this issue upon inclusion of this one required size? How do I fix it?
I have a macOS application built via command line (xcodebuild) using Xcode 16.1. Developed on ARM but end user is on Intel (same macOS 15.1).
App crashed and they sent me a .IPS dump.
From what MacGPT tells me:
Reading an IPS (Incident Processing System) file from a macOS crash report in Xcode isn’t as straightforward as with iOS device logs.
I can open the dump using Console. I see the IPS dump is partially symbolicated.
Line in the dump says: Meteorologist 0x103e0348f 0x103d88000 + 504975
Referencing this article: Adding identifiable symbol names to a crash report | Apple Developer Documentation
I run this command and see the same UUID for x86_64 as in the dump.
dwarfdump --uuid /Users/ed/meteorologist/trunk/Build/Meteorologist.xcarchive/dSYMs/Meteorologist.app.dSYM/Contents/Resources/DWARF/Meteorologist
I run this command:
atos -arch x86_64 -o /Users/ed/meteorologist/trunk/Build/Meteorologist.xcarchive/dSYMs/Meteorologist.app.dSYM/Contents/Resources/DWARF/Meteorologist -l 0x103d88000 0x103e0348f
And it says: fg: no current job
Suggestions for what I’m missing?
I have facing an above crash for many users device running on iOS 17.6.1 mostly on iPad devices. I'm not sure why this happening only in 17.X. In Xcode Organizer unable to see this crash in any devices running on OS 18.x. Our app crashes got spiked due to this. I am unable to fix or reproduce the same. The crash log is not pointing to our app code to find the root cause and fix this issue. Have attached the crash log in this post also the crash log roles have mixed values Background &amp; Foreground. But most of the crash is in background.
Is this any crash related to system and that only solved by OS update? I have updated the app using Xcode 16 and 16.1 still facing this crash unable to symbolicate the crash report as well.
Any ideas/solution how to solve this or how to proceed further. Have attached the entire crash log below.
RoleBackgroundCrash.crash
RoleForeGroundCrash.crash
I've an app running for some time in the Appstore now. Recently I had to renew my singing certficicates to be able to publish my app again.
I renewed the certificates, updated my provisioning profile and signed a new app version to publish only to find out that the app crashes during the splash screen.
I added new features to the app so my first thought was that there would be an issue there. To test that, I built the latest stable version of the app and signed it with the new profivisioning profile. The result was exactly the same crash as the new build.
My assumption is that the crash is caused by bad signing (?) but I am not sure because I'm lacking experience on that front.
I do have a crash report from testflight and logs from the device where the app crashed.
Testflight crash:
TestFlight crashlog
Device error logs:
Device error logs
Hope someone can help my out because I'm at a dead end :(
When running a simple C++ OpenGL project in Xcode, multiple instances of the program are created and launched by Xcode when I build and run...I am not sure why it happens, does anyone know how can I stop this?
Good afternoon
The essence of the question: our product is written in .net maui (a framework for cross-platform development from microsoft), when we use the profile for development in the build and directly install the application on the iPhone, everything works fine. But if you take the same build with the same settings, replace the development profile with the distribution profile, assemble and send it to TestFlight, install it on the same iPhone - when the application is launched, a crash occurs.
Yes, we studied the logs, and at the moment we have come to the theory that maybe the main problem lies inside the maui framework, but still - why will the behavior of the application change so much when using different profiles? From full functionality when using the development profile, to crash at the start when using the distribution profile. What exactly changes when you change your profile? Is there any documentation on this topic? Or advice from those who are more knowledgeable about this topic?
Thanks in advance for any reply
I recently published a new version of my app (I'm fairly new to this) once it was marked ready for distribution I can see it updated in App Store and it allowed me to update. but when I open the app my previous launch screen is present then the screen gos white and stalls.
what did I do wrong
After upgrading to iOS 18, my Core Data stack using NSPersistentCloudKitContainer in a shared App Group container stopped syncing correctly. The persistent store configuration, which previously worked in iOS 17, now experiences delayed or missing sync updates between devices. Then the app freezes and writes terminal the same error detail (which I provided) too many times.
The debug logs from the CloudKit mirroring delegate (NSCloudKitMirroringDelegate) show repetitive notifications but no updates in persistent history. Additionally, the persistent history tracking key appears unresponsive to local changes, causing transactions to fail in updating or syncing as expected.
Key setup details:
Core Data is set up within an App Group container using NSPersistentCloudKitContainer.
NSPersistentHistoryTrackingKey and NSPersistentStoreRemoteChangeNotificationPostOptionKey options are set to true.
Any insights into changes in iOS 18 Core Data or CloudKit handling with NSPersistentCloudKitContainer, especially around history tracking and sync delays, would be greatly appreciated. Thank you.
Error Detail
file:///private/var/mobile/Containers/Shared/AppGroup/BF95D309-EBE9-485E-B5CE-AA17097F7B60/[AppName]Database.sqlite
CoreData: debug: CoreData+CloudKit: -[NSCloudKitMirroringDelegate managedObjectContextSaved:](3123): <NSCloudKitMirroringDelegate: 0x3032b4870>: Observed context save: <NSPersistentStoreCoordinator: 0x302694bd0> - <NSManagedObjectContext: 0x3036b1a00>
CoreData: debug: CoreData+CloudKit: -[NSCloudKitMirroringDelegate remoteStoreDidChange:](3166): <NSCloudKitMirroringDelegate: 0x3032b4870>: Observed remote store notification: <NSPersistentStoreCoordinator: 0x302694bd0> - 090C4244-0101-4DEF-90D6-1260570F47A5 - <NSPersistentHistoryToken - {
"090C4244-0101-4DEF-90D6-1260570F47A5" = 9;
}> -
Persistence.swift
struct PersistenceController {
let container: NSPersistentCloudKitContainer
static let shared = PersistenceController()
static var preview: PersistenceController = {PersistenceController()}()
init() {
container = NSPersistentCloudKitContainer(name: "[AppName]")
// Configure CloudKit for the default container
if let url = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.[CompanyName].[AppName]") {
let storeURL = url.appendingPathComponent("[AppName]Database.sqlite")
let description = container.persistentStoreDescriptions.first
description?.url = storeURL
description?.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey)
description?.setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey)
container.persistentStoreDescriptions = [description].compactMap { $0 }
}
container.loadPersistentStores { (storeDescription, error) in
if let error = error as NSError? {
fatalError("Unresolved error \(error), \(error.userInfo)")
}
}
container.viewContext.automaticallyMergesChangesFromParent = true
container.viewContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy
}
}
There are significant crash reports coming from iOS 18 users regarding AVKit framework that starts from this line [AVPlayerController _observeValueForKeyPath:oldValue:newValue:] which seems to be coming from iOS internal SDK. There are 2 kinds of crash we found:
UI modification on background thread
From the stack trace it seems like when AVPictureInPictureController is being deallocated and its view is being removed from superview somehow the code is being executed in background thread because there is this line there _AssertAutoLayoutOnAllowedThreadsOnly highlighted before the crash.
But I’ve checked our code that plays around AVPictureInPictureController, in the locations where we would deallocate the object it will always be called on main thread which are insideviewDidLoad and deinit inside UIViewController class. From the log, it seems like the crash happened when user try to open another content when PIP player is active resulting in the current PIP instance will be replaced with a new one. My suspect is the observation logic inside AVPlayerController could be the hint to this issue, probably something broken over there since this issue happened across our app versions on iOS 18 users only.
Unfortunately, I was unable to reproduce this issue yet but one of my colleagues reproduced it once but haven’t been able to do it again since. The reports keep raising each day up to 1.3k events in the last 30 days now.
Over release object
This one has lower reports than the first one but I decided to include it since it might have relevant information regarding the first crash since the starting stack trace is similar. The crash timing seems to be similar to the first one, where we deallocate existing AVPictureInPictureController and later replace it with a new one and also found only in iOS 18 users which also refers to [AVPlayerController _observeValueForKeyPath:oldValue:newValue:]. I also was unable to reproduce this issue so far.
Oh, and both of the issues happened on both iPhone and iPad.
We’d appreciate any advice on what we can do to avoid this in the future and probably any hint on why it could happened.
I have reported this issue with bug number: FB15620734
I also attached one sample crash report for each of the crashes here.
non ui thread access.crash
over release.crash
I got sent a crash log from a user of my app. I followed the procedure that Apple specifies to symbolicate the crashlog, but that does not succeed (see https://developer.apple.com/documentation/xcode/adding-identifiable-symbol-names-to-a-crash-report#Symbolicate-the-crash-report-in-Xcode)
XCode complains that
"error: unable to locate main executable (arm64)"
The location of the main executable is given in the crashlog at a path that starts with /private/var/containers/Bundle/Application/ But the /private/var/containers directory on my system is empty.
I have tried to search my filesystem for the specific image that is mentioned in the crashlog, but it is nowhere to be found.
Because the image is not available, I cannot symbolicate the crashlog from the commandline using atos either.
The crashlog is from an iPhone running iOS 18.0.1, if that makes a difference.
Anybody knows how to resolve this?
Hello!
My app is crashing on iOS 12. On other versions (i.e. 15, 17), we could not reproduce it. The problem occurs every once in a while. It simply crashes after a few seconds using the App.
I got a crash report and will include in the post.
Looks like Language exception crash , but i could not narrow it down to the cause of the problem.
The crash happens under the "suggestd" name. Appreciate if someone can help.
suggestd-2024-10-24-134830.txt
Hello!
We're working on a large app with over 400 modules in both Swift and Objective-C, totaling more than 3 million lines of code. Since the release of Xcode 15 and 16 this summer, we’ve been experiencing issues with LLDB that have made debugging practically impossible.
Here are some of the problems we’re facing:
The first breakpoint takes a very long time to hit.
When using 'po self', we encounter the following error:
error: type for self cannot be reconstructed: type for typename "$s5MyModule10PlayerViewCD" was not found (cached)
error: Couldn't realize Swift AST type of self. Hint: using `v` to directly inspect variables and fields may still work.
We get numerous log messages like this:
Debugging will be degraded due to missing types. Rebuilding the project will regenerate the needed module files.warning: (arm64) /Users/egormerkushev/Library/Developer/Xcode/DerivedData/App-enhtbwiyebmjsffoqkqhhpshsfia/Build/Products/Debug-iphoneos/MyModule.framework/MyModule(UploadConfiguration.o) 0x000000000000079d: unable to locate module needed for external types: /Users/builder/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/169D1N0MIKBUI/Security-3BRN4UPIIGHME.pcm
error: '/Users/builder/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/169D1N0MIKBUI/Security-3BRN4UPIIGHME.pcm' does not exist
In the Derived Data folder, we find files with hash-like names, such as:
Security-3JM2E93YFDLZNYHWPPIMWNENB.d
Security-3JM2E93YFDLZNYHWPPIMWNENB.dia
Security-3JM2E93YFDLZNYHWPPIMWNENB.pcm
Security-3JM2E93YFDLZNYHWPPIMWNENB.scan
Security-3NAAT3MGN7XY96KVJW529HR41.d
Security-3NAAT3MGN7XY96KVJW529HR41.dia
Security-3NAAT3MGN7XY96KVJW529HR41.pcm
Security-3NAAT3MGN7XY96KVJW529HR41.scan
Security-3RJH8STJC01N1KKN7JCY1WK7F.d
Security-3RJH8STJC01N1KKN7JCY1WK7F.dia
Security-3RJH8STJC01N1KKN7JCY1WK7F.pcm
Security-3RJH8STJC01N1KKN7JCY1WK7F.scan
Security-3TILE9XTY0B8UV9VYL7Y0MJN.d
Security-3TILE9XTY0B8UV9VYL7Y0MJN.dia
Security-3TILE9XTY0B8UV9VYL7Y0MJN.pcm
Security-3TILE9XTY0B8UV9VYL7Y0MJN.scan
Security-3ZE8O6ZPHE4L52UZGL0PCBA59.d
Security-3ZE8O6ZPHE4L52UZGL0PCBA59.dia
...
When enabling LLDB logs with:
log enable -f /tmp/lldb.log lldb all
we end up with a 1.5GB log file containing hundreds of thousands of error messages.
Finally, the LLDB console output in Xcode ends with errors like:
error: Assertion failed: (byte_size > 0 && byte_size <= 8 && "GetMaxU64 invalid byte_size!"), function GetMaxU64, file DataExtractor.cpp, line 527
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0 LLDB 0x0000000116ccfe1c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56
1 LLDB 0x000000011682fdcc lldb_private::lldb_assert(bool, char const*, char const*, char const*, unsigned int) + 148
2 LLDB 0x000000011682944c lldb_private::DataExtractor::GetMaxU64(unsigned long long*, unsigned long) const + 72
3 LLDB 0x00000001167335a8 lldb_private::CompilerType::GetValueAsScalar(lldb_private::DataExtractor const&, unsigned long long, unsigned long, lldb_private::Scalar&, lldb_private::ExecutionContextScope*) const + 304
4 LLDB 0x000000011666f0f4 lldb_private::Value::ResolveValue(lldb_private::ExecutionContext*, lldb_private::Module*) + 388
5 LLDB 0x0000000116671e94 lldb_private::ValueObject::ResolveValue(lldb_private::Scalar&) + 104
6 LLDB 0x0000000116674d6c lldb_private::ValueObject::GetValueAsSigned(long long, bool*) + 140
7 LLDB 0x000000011650510c lldb::SBValue::GetValueAsSigned(long long) + 160
8 lldb-rpc-server 0x00000001025ebe70 rpc_server::_ZN4lldb7SBValue16GetValueAsSignedEx::HandleRPCCall(rpc_common::Connection&, rpc_common::RPCStream&, rpc_common::RPCStream&) + 92
...
13 libsystem_pthread.dylib 0x00000001917fb2e4 _pthread_start + 136
14 libsystem_pthread.dylib 0x00000001917f60fc thread_start + 8
Please file a bug report against lldb reporting this failure log, and as many details as possibleerror: Assertion failed: (byte_size > 0 && byte_size <= 8 && "GetMaxU64 invalid byte_size!"), function GetMaxU64, file DataExtractor.cpp, line 527
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0 LLDB 0x0000000116ccfe1c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56
1 LLDB 0x000000011682fdcc lldb_private::lldb_assert(bool, char const*, char const*, char const*, unsigned int) + 148
2 LLDB 0x000000011682944c lldb_private::DataExtractor::GetMaxU64(unsigned long long*, unsigned long) const + 72
3 LLDB 0x00000001167335a8 lldb_private::CompilerType::GetValueAsScalar(lldb_private::DataExtractor const&, unsigned long long, unsigned long, lldb_private::Scalar&, lldb_private::ExecutionContextScope*) const + 304
4 LLDB 0x000000011666f0f4 lldb_private::Value::ResolveValue(lldb_private::ExecutionContext*, lldb_private::Module*) + 388
5 LLDB 0x0000000116671e94 lldb_private::ValueObject::ResolveValue(lldb_private::Scalar&) + 104
6 LLDB 0x0000000116674c44 lldb_private::ValueObject::GetValueAsUnsigned(unsigned long long, bool*) + 140
7 LLDB 0x0000000116505224 lldb::SBValue::GetValueAsUnsigned(unsigned long long) + 160
8 lldb-rpc-server 0x00000001025ebf18 rpc_server::_ZN4lldb7SBValue18GetValueAsUnsignedEy::HandleRPCCall(rpc_common::Connection&, rpc_common::RPCStream&, rpc_common::RPCStream&) + 92
9 lldb-rpc-server 0x00000001025f62b8 rpc_common::Connection::PrivateHandleRPCPacket(rpc_common::RPCPacket&, rpc_common::RPCPacket&, bool&) + 628
10 lldb-rpc-server 0x00000001025f9e8c Packets::ProcessPackets() + 564
11 lldb-rpc-server 0x00000001025f9bf4 Packets::ReadThread() + 276
12 lldb-rpc-server 0x00000001025f9ad4 Packets::RunReadThread(void*) + 12
13 libsystem_pthread.dylib 0x00000001917fb2e4 _pthread_start + 136
14 libsystem_pthread.dylib 0x00000001917f60fc thread_start + 8
Please file a bug report against lldb reporting this failure log, and as many details as possiblePrinting description of self:
error: type for self cannot be reconstructed: type for typename "$s5MyModule10PlayerViewCD" was not found (cached)
error: Couldn't realize Swift AST type of self. Hint: using `v` to directly inspect variables and fields may still work.
In short, our debugger is completely unusable at this point, which is severely impacting our team's ability to develop effectively.
Do you have any suggestions on how we can resolve these issues? We would really appreciate your help. Thank you!
I develop React Native app with dynamically linked pods, and app runs on simulator well, while running it on connected device returns this error:
dyld[53510]: Symbol not found: __ZN5swift39swift51override_conformsToSwiftProtocolEPKNS_14TargetMetadataINS_9InProcessEEEPKNS_24TargetProtocolDescriptorIS1_EEN7__swift9__runtime4llvm9StringRefEPFPKNS_35TargetProtocolConformanceDescriptorIS1_EES4_S8_SC_E
Referenced from: <4A3492BF-0479-3124-BE58-05BAED71BB20> /private/var/containers/Bundle/Application/0D9FDF5C-BBC9-4060-972B-B2D6FD91E321/BFF.app/Frameworks/Framework1 Expected in: <0549B906-CB15-3735-AA15-FAEB5F687C8B> /private/var/containers/Bundle/Application/0D9FDF5C-BBC9-4060-972B-B2D6FD91E321/BFF.app/Frameworks/Framework2
I already tried different things:
Different versions of IPHONEOS_DEPLOYMENT_TARGET
Ensured that all dependencies using same Swift version
Different linking
Tested on different devices and iOS versions
Standard cleaning of derived data and reinstalling podfiles also included
BUILD_LIBRARY_FOR_DISTRIBUTION="YES"
ENABLE_BITCODE="NO"
I am using LAContext(), canEvaluatePolicy, and evaluatePolicy in my project, and I've encountered a crash under a specific scenario. When the permission prompt appears asking, "Do you want to allow [App Name] to use biometrics in your app?" and the user locks the device without selecting "Allow" or "Don't Allow," the app crashes at that point.
Has anyone else experienced this issue or tested this scenario?
Any insights would be appreciated!
Hi there, I'm having an app developed in the last weeks, and recently I'm testing it on iOS 18. This following piece of UI code has diff between iOS 18 and iOS version lower than 18.
I have a NavigationStack in my homeView, and the display difference is for its toolbar in one destination. I've tried both approaches in code, with header variable or ToolbarItemGroup used directly in the toolbar modifier, both would result in there being a spacer between the body VStack and toolbar, which is unexpected. Here's the code and a demo screenshot.
var body: some View {
// header
VStack(alignment: .leading) {
notificationView(
iconKey: "ErrorCircle",
contentKey: "receivedFile.notification.noNetwork.content"
)
fileListView
}
.toolbar {
// header
ToolbarItemGroup(placement: .principal) {
Button {
dismiss()
} label: {
Image(systemName: "chevron.backward")
}
.background(Color.yellow)
Spacer()
Text(LocalizedStringKey("title"))
.font(
.system(size: 17)
.weight(.semibold)
)
.background(Color.yellow)
Spacer()
Button {
print("click")
} label: {
Text("Click")
}
.background(Color.yellow)
}
}
.navigationBarBackButtonHidden()
.onAppear {
refreshAllFiles()
}
}
@ToolbarContentBuilder private var header: some ToolbarContent {
ToolbarItem(placement: .topBarLeading) {
Button {
dismiss()
} label: {
Image(systemName: "chevron.backward")
}
.background(Color.yellow)
}
ToolbarItem(placement: .principal) {
Text(LocalizedStringKey("receivedFileList.title"))
.font(
.system(size: 17)
.weight(.semibold)
)
.background(Color.yellow)
}
ToolbarItem(placement: .topBarTrailing) {
Button {
print("click for jumping")
} label: {
Text("Click for jumping")
}
.background(Color.yellow)
}
}
Hope I can get some help from the forum on the usage. If not fixable, may I know if this is a known issue that would be fixed in the next upgrades.