dsym file

-David, so long as you have the correct .ipa and .dSYM files that match the crash log:drop them all into one folder for simplicity,attach your device to your macbook,remove your app from your device,install the app via the .ipa device directly through itunes (this may take a bit of searching but is fairly easy)once that is done, and you are assured your app matches the one that caused the crash log: in Xcode, fire up the WIndow | Devices viewselect your device,click on View Device Logsdrag your crash log into the log window (left-hand pane, under the headers: Process / Dev / etc..that should be it, Xcode should automatically symbolicate the crash log for you.I hope this helps, as i know just how totally frustrating this experience can be.drew..

We use cmake, so it was a bit more difficult -- and CircleCI, so I had to make sure the dsym files got archived. Did that. Re-confirmed it's this code: guard let flowData = self.flowSets[id] else { os_log(.error, log: Self.log, Could not find flow %{public}@, id.uuidString); completion(RedirectorError.flowNotFound) return } id is a UUID; self.flowSets is private var flowSets : [UUID : FlowData] = [:] (where FlowData is a simple class wrapping some flow-related information). This particular method is invoked via XPC from a daemon, with a signature of func handleTCPData(_ id: UUID, data: Data?, completion: @escaping (_: Error?) -> Void). The daemon code is in ObjC++, and it checks to ensure that the UUID is non-nil. So I have no idea why it is segfaulting!

I'm having this problem as well.I found this post helpful in symbolicating my crash logs manually:http://stackoverflow.com/questions/25855389/how-to-symbolicate-crash-log-xcodein particular the post by 'Sea Coast of Tibet'.In the Xcode Crashes Organizer, cmd-click/right click on the app's name (above # devices) and choose 'Show in Finder' to find the 'xxx.xccrashpoint' bundle containing the raw crash logs. Cmd-click/right-click on this and select 'Show Package Contents' to open the bundle.Copy the raw crash logs to a folder with your app's binary and its dSYM file (you did save these after submitting your app, right?) and follow the directions in Sea Coast of Tibet's post with some/all of the crash logs to see the symbolicated stack trace of each crash.

there is no Download Debug Symbols button You shouldn’t need to download debug symbols. Consider this quote from the Download debug symbols page in Xcode help: If you include bitcode when you upload your app to App Store Connect Downloading debug symbols is only relevant if you use bitcode, and there’s no point using bitcode in a Mac App Store app [1]. So: Make sure you’re not using bitcode. Symbolicate using the .dSYM files created by your local build. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] As of WWWDC this year, bitcode is effectively deprecated for all our platforms, but it’s never been relevant to Mac App Store apps.

I'm having the same problem, the archive contains a dSYMs folder with dSYM packages for the binary and each framework, with the line number information of the files.

I'm not that familiar with Swift, I mostly do Objective-C programming, but my understanding is that Swift apps bundle a Swift runtime to be able to run the specific version of Swift that the app was compiled for.This runtime will obviously increase the size of the app.Looking at the contents of the .app file created by a debug build (using a default project in Xcode 7.1.1) there are the following files of intrest:Objective-CContents/MacOS/<app> 61 KBContents/Resources/Base.lproj/MainMenu.nib 36 KBSwiftContents/MacOS/<app> 37 KBContents/Resources/Base.lproj/MainMenu.nib 36 KBContents/Frameworks/libswift*.dylib 6 MB (the Swift runtime files)So a Swift app appears to get about 6MB of extra Swift related frameworks added to it, which isn't really that much.I'm not sure why the archive builds differ by 99.2MB rather than 6MB - although some of this could be due to dSYM files and other meta data bundled with the app archive. The Swift build may perhaps need to bundle

[quote='809905022, gpg, /thread/766290?answerId=809905022#809905022, /profile/gpg'] I use Xcode Command Line tools (clang 16.1) to compile the source and generate the dSYM files. [/quote] OK. From Xcode’s perspective, that’s still an external build system. [quote='809905022, gpg, /thread/766290?answerId=809905022#809905022, /profile/gpg'] Can a sandboxed process (python exec) access to a URL from another sandboxed process (app)? [/quote] Yes, but I don’t think it needs to in this case. My understanding is that you’re running this Python executable as a child process, using posix_spawn or something layered on top of that (like NSTask or Process). Please confirm. 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?

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

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