dsym file

I tried thread sanitizer, unfortunately it fails too much on the 3rd party C++ code the project uses. Hmmm, that’s not a good sign. If you temporarily stub out that library, do you still see these crashes? there a better way of getting the line number from the address Most of the time that happens automatically, presuming you have your .dSYM files set up correctly. For all the gory details, see Adding Identifiable Symbol Names to a Crash Report. Oh, one other hint: For testing purposes you can implement a loopback XPC listener, allowing you to stress test your XPC subsystem in a sensible environment, like an XCTest. For info on how to do that, see TN3113 Testing and debugging XPC code with an anonymous listener. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I am using TXLiteAVSDK_Player package dependencies and now when I want to archive and distribute an app I get this two warnings : Upload Symbols Failed The archive did not include a dSYM for the TXFFmpeg.framework with the UUIDs [1xxxxxx]. Ensure that the archive's dSYM folder includes a DWARF file for TXFFmpeg.framework with the expected UUIDs. Upload Symbols Failed The archive did not include a dSYM for the TXSoundTouch.framework with the UUIDs [Axxxx]. Ensure that the archive's dSYM folder includes a DWARF file for TXSoundTouch.framework with the expected UUIDs. My system is macOS sonoma 14.5 and Xcode is 16.0. How can I eliminate this warning?

OK. And python3.11 executable is built by an external build system, right? That is, you are not using Xcode to build it from source. I use Xcode Command Line tools (clang 16.1) to compile the source and generate the dSYM files. Let me bring to the conversation this document I've been going through, although maybe is not related: Accessing files from the macOS App Sandbox Python executable needs a folder to save cache files, at the moment the folder is created by the app and set as environment variable to the executable. The executable also needs access to the folder where the libraries are, etc. We already know that this setup works fine in a non sanboxed app. But now the executable is sandboxed, and the app with its libraries is sandboxed too. Can a sandboxed process (python exec) access to a URL from another sandboxed process (app)? The document mentioned earlier talks about bookmarks to share file access between processes, is that the way to go with all the urls the exec

[quote='767800021, EdwardD20, /thread/767800, /profile/EdwardD20'] And it says: fg: no current job [/quote] You're on the right path, and the commands you provided above look correct to my eye, short of verifying the actual addresses you're passing in from your crash report. I've never seen that specific error text before. It sounds like that could be a shell-level error, such as if you've customized Terminal beyond the basics. Is there anything like that in play for you? One other way to symbolicate the crash report that is helpful is this command: xcrun crashlog /path/to/crash.ips This runs LLDB to locate the matching dSYM file automatically on macOS and then output the symbolicated crash report, including breaking apart any inlined code in a way that atos won't do without using an -i argument in the command. — Ed Ford,  DTS Engineer

I've noticed previously generated dSYM files contains t __T013 instead of t _$S13 and reports for that dSYM file were just Ok.These weird format strings look like Swift mangled names (see this and this for more background). I believe that the Swift name mangling format is undergoing change as part of the ABI compatibility effort, and thus you may see symbolication problems until all the various tools catch up.You can demangle names using the swift-demangle tool. For example, I created an app with code like this: class SearchViewController : UITableViewController { override func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) { fatalError() } }Xcode 10.1 mangles this to the following strings:$ nm My_App.app/My_App | grep SearchViewController.*didSelect 0000000100001610 T _$S6My_App20SearchViewControllerC05tableD0_14didSelectRowAtySo07UITableD0C_10Foundation9IndexPathVtF 00000001000016a0 t _$S6My_App20SearchViewControllerC05tableD0_14didSelectRowAtySo07UITableD0C_10Fou

I have the same issue here regarding the path of dSYMs and BCSymbolMaps. Even when I specify the path to the dSYM for my framework, I get this error: error: the path does not point to a valid debug symbols file:

The archive did not include a dSYM for the hermes.framework with the UUIDs [A56CDAAF-2027-33D2-A806-BA11E8C1B3EF]. Ensure that the archive's dSYM folder includes a DWARF file for hermes.framework with the expected UUIDs.