dsym file

Documentation bug reported, as FB14929037. Yes - the offset from the string is quite large, but I just want useful output such as ThisFunctionWasInvolved from ThisFunctionCausedAPanic.cpp, line 455. Symbolicate the other frames you've got. This is a quick way to differentiate between something is wrong with THIS symbol vs something systemic is wrong. Yes, this is a “something systemic is wrong” situation. I was trying to reduce the amount of information for readers to wade through, but I am not getting useful results for any efforts at symbolicating the addresses on the back trace or the PC (program counter). ” dwarfdump will print the contents of a dsym file, which will either show that the symbols dwarfdump works on dSYM files, but apparently not on debug-builds-with-symbols-in-the-binary. As such, I rebuilt with separating the symbols into a dSYM file. dwarfdump provides what appears to be correct information for the symbols, but for a sanity check here is a blurb from the start

The first thing I tried was using the built-in Xcode crash reports in the Organizer. I assumed that since Xcode has access to the archives and is fetching the crash reports itself, it would be able to locate and use the appropriate dSYMs, but I see unsymbolicated entries for the parts of the stack trace that are in my app. So that led me to trying to symbolicate manually. I looked up the UUID and then used this, which produced no output: mdfind com_apple_xcode_dsyms_uuids == E49A5EB3-C560-3895-B2AE-4CEE263E45CA Next I tried looking in the archive for the dSYM itself. I right-clicked on the archive in the Xcode organizer and chose Show in Finder, then used Show Package Contents on the xcarchive. In the dSYMs folder, I see dSYM files for some frameworks the app uses, as well as some of its extensions (intents, widgets) but there isn't a dSYM for the app itself.

FWIW, in another thread on the same issue, a user suggested going to Build Settings -> Build Options -> Debug Information Format, and changing the selection to DWARF only for both the debug and release build, and then change it back to DWARF with dSYM File. I haven't uploaded a new archive yet to test, but after making that change, the following lines are added to project.pbxproj. Given that DWARF with dSYM was originally selected and these lines were added only after changing to DWARF and back, it seems that XCODE 16+ fails to add those options to the project file

Thanks for your reply. If you are experiencing persistent issues, please consider submitting a bug report. To facilitate our investigation, would you be able to share a project demonstrating the problem? Additionally, please provide both dSYM files for comparison. We are eager to resolve this matter with your assistance. Please remember the software is still on beta. Albert Pascual
  Worldwide Developer Relations.

Hi all, I came across the same issue when adding -debug-symbols to xcframework, which resulted with following error: error: the path does not point to a valid debug symbols I resolved it by using the absolute path when referencing the dSYM/BCSymbolmap files So instead of using the relative path when referencing eg dSYM file xcodebuild -create-xcframework ttttt -framework myFramework-iOS.xcarchive/Products/Library/Frameworks/myFramework.framework ttttt -debug-symbols myFramework-iOS.xcarchive/dSYMs/myFramework.framework.dSYM ttttt ... I would use the absolute path xcodebuild -create-xcframework ttttt -framework myFramework-iOS.xcarchive/Products/Library/Frameworks/myFramework.framework ttttt -debug-symbols ~/myFolder/myFramework-iOS.xcarchive/dSYMs/myFramework.framework.dSYM ttttt ... This way, the dSYM was properly integrated into final xcframework. Hope this helps somebody.

Sorry, this Xcode16 just sucks. I've lost another half a days fiddling around with no luck, I just don't know what to do, and where. The project is big and in order to recreate the functionality, and the lldb bug, I have to build a whole new project, which will end up resembling the original one, minus some functionalities, so I dropped this route. The issue appears in one of the projects's internal static library. Now, I pause the execution at some breakpoint, run the po command and promptly get the Couldn't realize Swift AST type of self. Then I run swift-healthcheck, check the health log file, find the error below and conclude that the issue is in the static lib XXX. SwiftASTContextForExpressions(module: XXX, cu: AllParts.swift)::LoadOneModule() -- Missing Swift module or Clang module found for XXX, imported via SwiftDWARFImporterDelegate. Hint: Register Swift modules with the linker using -add_ast_path. Then I added -add_ast_path on the Other Linker Flags of the final executable, and now I get an

You should stick to Xcode's default build settings here: GCC_GENERATE_DEBUGGING_SYMBOLS: Yes DEBUG_INFORMATION_FORMAT: DWARF for Debug builds, and DWARF with dSYM for Release builds For a release build, this combination means that you'll still have symbols, but they are extracted to a separate bundle called a dSYM file. This way, your app is not consuming more space than it requires when released to your customers. The benefit to you for keeping symbols enabled is that you'll be able to debug the app — without this, you'll have less information in the debugger when working with your Debug build, and you'll be unable to symbolicate any crash reports coming in from your customers.

I just created a small test project with a standard framework (from the Framework template), with no other changes to the default template. From there, I configured the project to build as an XCFramework. As part of the -create-xcframework command, I added the -debug-symbols option so that the original dSYM from the framework archive gets copied in. When I then throw this XCFramework into a new test app that imports my framework, and archive that, the app's archive automatically contains the dSYM file. If you run the same test, what happens? — Ed Ford,  DTS Engineer

[quote='821969022, Fat_Panda, /thread/772077?answerId=821969022#821969022, /profile/Fat_Panda'] How can I find the UUID in my dSYM file? [/quote] Using dwarfdump. Adding identifiable symbol names to a crash report explains the exact syntax. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I'm also getting the same problem. The dSym files seems to be there as well, but navigating to it doesn't do anything. Also Instruments is showing a lot of leaks, but when you run the same app on a physical device, there's no leaks shown. So right now it looks like Xcode 12 Instruments doesn't play nicely with the Simulator, which obviously is a massive problem!

The key thing to do is make sure to download the archive builds for any version that you distribute, either through the App Store, or if you distribute through other means for testing or enterprise workflows. That way, you have the dSYM files locally — Xcode Cloud stores your archives for 30 days. Download and archive build artifacts covers these details. — Ed Ford,  DTS Engineer

And what is interesting, the dSYM file itself is corrupted. It contains all of those extra characters.What extra characters are you talking about? I looked at your screen shot and I don’t see anything anomalous. Are you referring to the _$S13 stuff? Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Anyone found a fix for this? We also experience this problem. I just cannot build and run on either a simulator or device using Xcode 16. The app crashes on launch with the following stacktrace: #0 0x000000010595cf30 in __pthread_kill () #1 0x0000000104d9b124 in pthread_kill () #2 0x000000018016c4ec in abort () #3 0x0000000104b82f18 in abort_could_not_find_entry_point___debug_dylib () #4 0x0000000104b82744 in getDebugDylibEntryPoint () #5 0x0000000104b81f98 in __debug_blank_executor_main () #6 0x0000000104dd5410 in start_sim () #7 0x0000000104eda154 in start () And the following warning: warning: (arm64) /path/to/executable empty dSYM file detected, dSYM was created with an executable with no debug info.