dsym file

I get the same issue and i have solved it now. i'd like to share my solution.command line below will result in xcarchive missing BSCymbolMaps and dSYMs${xcodePath}/xcodebuild -workspace ${workspace} -scheme ${scheme} -configuration ${configuration} -sdk ${sdk} -archivePath ${archive_path} archive CONFIGURATION_BUILD_DIR=${build_dir}command line below will solve the problem${xcodePath}/xcodebuild -workspace ${workspace} -scheme ${scheme} -configuration ${configuration} -sdk ${sdk} -archivePath ${archive_path} archiveI find adding a buildingsetting CONFIGURATION_BUILD_DIR=Path will change the others buildSetting variables such as DWARF_DSYM_FOLDER_PATH, i guess it will lead the missing of BCSymbolMaps and empty dSYMs folder in xcarchivecheck DWARF_DSYM_FOLDER_PATH buildsettings value maybe helpyou can see DWARF_DSYM_FOLDER_PATH value by excute command line xcodebuild -workspace APP.xcworkspace -scheme APP -showBuildSettings in your project root path.

but there’s no way to specify file and line number to the log(…) function Right. The system log implementation does not log file and line numbers in the traditional way. Rather, the log ends up including: The Mach-O UUID of the caller — If you look at the C API, you’ll see that under the macros there’s a dso parameter that is effectively a pointer to the mach_header[_64]. The offset into that Mach-O — It finds the caller by walking up the stack, and then calculates the offset from the dso. This allows log clients to recover the file and line info from a .dSYM, in much the same way as symbolication [1]. The primary motivation for this is space saving, in your program, the transient log buffers, and the final on-disk log. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] See Adding Identifiable Symbol Names to a Crash Report.

It's all done via a script, but the basic gist is: xcrun xcodebuild archive -archivePath MyFramework.xcarchive -scheme MyFramework xcrun xcodebuild -create-xcframework -framework MyFramework.xcarchive/Products/@rpath/MyFramework.framework -debug-symbols MyFramework.xcarchive/dSYMs/MyFramework.framework -output MyFramework.xcframework ditto -c -k --rsrc --keepParent MyFramework.xcframework MyFramework.xcframework.zip The zip file is attached to a GitHub release, and I download it in the app project, expand it and link to it as normal. I can see looking at this how the signing might be a bit off by reaching into the xcarchive directly, rather than exporting the framework first. I might try using xcodebuild -exportArchive prior to creating the XCFramework, and see if that helps.

This may be an old question, and there may be recommendations against rolling your own solution, but for those who prefer to write their own solution, I wanted to share mine. To write your own crash reporter you need to capture signals and exceptions. To capture signals, use a handler in this format: signal(SIGINT) { _ in var threadStackTrace = _ = Thread.callStackSymbols.map({ threadStackTrace.append(($0)n) }) } This will build a string representing the lines of a stack trace. SIGINT is just one of the signals that you need to capture. There are 14 other signals that I capture in my crash reporter. You'll need a separate handler for each signal. Here are a few other signals I capture: EXC_BREAKPOINT, EXC_CRASH, EXC_BAD_ACCESS, EXC_BAD_INSTRUCTION, SIGABRT, SIGKILL, SIGTRAP, SIGBUS, SIGSEGV, SIGHUP, SIGTERM, SIGILL, SIGFPE, SIGPIPE. There may be others that should be handled. In Xcode, 'Jump to Definition' to see other signals. You also need to capture uncaught exceptions. You can do that with: NSSetUncaught

Hi,Where exactly do you go to disable CLANG_ENABLE_MODULES and enable dSYM creation in xCode? Any help to point me there will be greatly appreciated it, I have been trying to get rid of these warnings for a long time now.Also, if these warnings don't go away. Will Apple still accept the App for to publish on the App Store?Thanks!

For those who (like me) stumbled upon this thread trying to create an XCFramework with debug symbols & bitcode, I've made a build-phase script that makes it easy to implement. Create a new target for your framework that is just for creating the .xcframework container (this is needed because when running this script on the same target, it gets an infinite loop) Add the script to the target's Build phases --> Add new run script For the rest, see the comments in the script Set the output folder var UNIVERSAL_OUTPUTFOLDER=${BUILD_DIR}/${CONFIGURATION}-universal To make an XCFramework, we first build the framework for every type seperately echo XCFramework: Starting script to build an XCFramework. Output dir: ${UNIVERSAL_OUTPUTFOLDER} Device slice. echo XCFramework: Archiving DEVICE type... xcodebuild archive -scheme ${PROJECT_NAME} -configuration Release -destination 'generic/platform=iOS' -archivePath ${BUILD_DIR}/archives/${PROJECT_NAME}.framework-iphoneos.xcarchive SKIP_INSTALL=NO echo XCFramework: Arch

On manually integrating the framework and running the command image list MOCore the output is id /Users/rakshitha/Library/Developer/Xcode/DerivedData/swifttesting-cnvmmbfljmnratdcgnfpynlryijy/Build/Products/Debug-iphonesimulator/swifttesting.app/Frameworks/MOCore.framework/MOCore/System/Volumes/Data/Users/rakshitha/Documents/MoEngage-iPhone-SDK/MoEFramework/MoEngage/XCFramework/MOCore.xcframework/ios-arm64_i386_x86_64-simulator/dSYMs/MOCore.framework.dSYM/Contents/Resources/DWARF/MOCore Where the framework resides in the path /Users/rakshitha/Documents/MoEngage-iPhone-SDK/MoEFramework/MoEngage/XCFramework/MOCore.xcframework/ios-arm64_i386_x86_64-simulator/dSYMs/MOCore.framework.dSYM/Contents/Resources/DWARF/MOCore Find the attachment below for the output of the swift-healthcheck command. (The attachment has partial output only due to size restriction) swift-healthcheck Looking forward for your assistance

Similar problem happening here. Symbols and Bitcode uploaded for the latest version of our app, as confirmed by iTunes Connect.Downloading dSYMs works fine, but they are useless, filled with __hidden#xx symbolication descriptions, despite symbols having been included.So, the crash reports symbolicate, but there is nothing to be learned from them.Filed as another radar issue: 26536862

I am having this issue too. When I check the newly generated Archive's folder, I can only see the folders BCSymbolMaps, Products, and dSYMs, whereas previous (and working) archives had those three, as well as the Info.plist and the folders SCMBlueprint and SwiftSupport. This happened to me after updating Xcode. I have tried all previously mentioned solutions (to my knowledge). Any help is welcome.

I get the same annoying warnings since Xcode 16. Currently seeing them under 16.1. Not only do I see it in scripts being executed as an Xcode Archive post action, but also in other scripts on my compputer. Don't know if it is related, but since then DSYM info for Sentry is also broken. Path is: /Applications/Xcode.app/Contents/Developer

It seems that sentry-cli has changed since the previous responses were made. Here's the ci_scripts/ci_post_xcodebuild.sh that worked for me: set -e if [ ! -d $CI_ARCHIVE_PATH ]; then echo Archive does not exist, skipping Sentry upload exit 0 fi # This is necessary in order to have sentry-cli # install locally into the current directory export INSTALL_DIR=$PWD if [[ $(command -v sentry-cli) == ]]; then echo Installing Sentry CLI curl -sL https://sentry.io/get-cli/ | bash fi echo Authenticate to Sentry sentry-cli login --auth-token $SENTRY_AUTH_TOKEN echo Uploading dSYM to Sentry sentry-cli debug-files upload -o -p $CI_ARCHIVE_PATH

@manumayank The best way I have found is to use grep on an archive version. Is that the instructions you got? Open /Applications/Utilities/Terminal Type the following on the command-line to change to the directory where the application binary is: cd ~/Library/Developer/Xcode/Archives// For example, cd ~/Library/Developer/Xcode/Archives/2020-03-09/SampleApp 3-9-20, 11.47 AM.xcarchive To search for open_dprotected_np, type the following on the command-line: grep -R open_dprotected_np * should provide you a result like: Binary file dSYMs/SampleApp.app.dSYM/Contents/Resources/DWARF/SampleApp matches To point you into the right direction. Do you have any result? Albert Pascual
  Worldwide Developer Relations.

Is the .dSYM baggage needed to get to the proper line numbers or something?Yes. Because there are enough other factors involved (compiler versions, optimization settings, etc.) that the translation from addresses inside a method to line numbers wouldn't be deterministic without a symbol map.You can find documentation for dSym and the related stuff on the LLVM pages, but I don't know whether that's We're documenting this after figuring it out or being told what it is, so we know what the heck we're doing in the future, We're making this up, or a combination of the two. As software, it's probably a bit of both. 🙂lldb.llvm.org/symbols.htmlEdit: When dealing with debugging, do also keep in mind that there's an option to strip debugging symbols from executables. So were you running nm on the binary with debugging symbols; or with only the necessary symbols needed to interact with the Objective-C runtime, linker, and loader?

+1. It started happening randomly around February 3 (JST), and since February 8 (JST), none of the builds have generated dSYM!I had to increment a lot of build versions to try this out... I had to reorganize my version control... (I had to patch the marketing version or something, even though it wasn't a patch for the app)