When running instruments or when debug memory in Xcode, I am getting same error as An unknown error occurred launching the helper task Xcode: Xcode16.3 OS: 15.5 Beta (24F5068b) Mac mini: Apple M2 Pro

Context I created a short script to CPU profile a program from the command line. I am able to record via the Instruments app, but when I try from the command line I get the following error shown below. This example is just profiling the grep command. Error: % cpu_profile /usr/bin/grep \ --recursive "Brendan Gregg" \ "$(xcode-select --print-path)/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk" Profiling /usr/bin/grep into /tmp/cpu_profile_grep.trace Starting recording with the CPU Profiler template. Launching process: grep. Ctrl-C to stop the recording Run issues were detected (trace is still ready to be viewed): * [Error] Failed to start the recording: Failed to force all hardware CPU counters: 13. Recording failed with errors. Saving output file... Script: #!/bin/sh set -o errexit set -o nounset if [ "$#" -lt 1 ] then echo "Usage $0 <program> [arguments...]" 1>&2 exit 1 fi PROGRAM="$(realpath "$1")" shift OUTPUT="/tmp/cpu_profile_$(basename "$PROGRAM").trace" echo "Profiling $PROGRAM into $OUTPUT" 1>&2 # Delete potential previous traces rm -rf "$OUTPUT" xcrun xctrace record \ --template 'CPU Profiler' \ --no-prompt \ --output "$OUTPUT" \ --target-stdout - \ --launch -- "$PROGRAM" "$@" open "$OUTPUT" I think the error has to do with xctrace based on this post, but according to this post it should have been resolved in MacOS version 15.4. System Chip: Apple M3 Pro macOS: Sequoia 15.4.1 xctrace version: 16.0 (16E140) xcrun version: 70. Xcode version: 16.3 (16E140) Working Screenshots from Instruments App:

I am currently reviewing the tutorial documentation for the instruments. (Instruments Tutorials: https://developer.apple.com/tutorials/instruments/identifying-a-hang) It seems very useful, so I want to follow the tutorials step by step. However, I am having trouble downloading the sample project files; it appears that the 7z file is broken. (https://developer.apple.com/instruments/tutorials/downloads/InitialVersion.7z) Can anyone help me with how to download the project files properly?

I am using XCode16 and macOS 14.7.2. Previously, using the instruments on an iPhone with iOS 14.3 was normal, but when I upgraded to iOS 18, the instruments often couldn't find the library. I have to restart the instruments to restore normal operation, but the problem will occur again after using it for a period of time

I have an XPC server running on macOS and want to perform comprehensive performance and load testing to evaluate its efficiency, responsiveness, and scalability. Specifically, I need to measure factors such as request latency, throughput, and how well it handles concurrent connections under different load conditions. What are the best tools, frameworks, or methodologies for testing an XPC service? Additionally, are there any best practices for simulating real-world usage scenarios and identifying potential bottlenecks?

I've discovered what appears to be a system-level memory leak when pressing any key in Swift UI projects. This issue occurs even in a completely empty SwiftUI project with no custom code or event handlers. When monitoring with Instruments' Leaks tool, I observe multiple memory leaks each time any key is pressed. These leaks consist primarily of: NSExtraData objects (240 bytes each) NSMenuItem objects (112 bytes each) Other AppKit and Foundation objects Has anyone else encountered this issue? How can I fix this behavior? While the leaks are small (about 5-6KB per keypress), they could potentially accumulate in applications where keyboard input is frequent.

I have a complex CoreImage pipeline which I'm keen to optimise. I'm aware that calling back to the CPU can have a significant impact on the performance - what is the best way to find out where this is happening?

Hi, I’m encountering an issue while using xctrace & instruments to profile an application on macOS. Specifically, when trying to record a trace using the CPU Profiler template, I get the following errors: Failed to start the recording: configureHardwareCounters: Failed set kpc configuration: Operation not permitted. Unexpected failure: Couriers have returned unexpectedly. macOS Version: 15.3.1 Chip: Apple M4 Pro Xcode Version: Xcode 16.2

Hello, We are experiencing slow launch time indicators in our performance monitoring tools(Crashlytics/DataDog/Xcode), and trying to understand what is the best approach to reduce it. Currently, cold launch takes ~900ms on iPhone 16 Pro , but ~2s on iPhone 11. Profiling app launch detected that most of the time is spend on loading the libraries. Our app is massive, we use a total of ~40 3rd parties libraries + 10 internal libraries. We enabled the "mergeable libraries" XCode new feature however the app launch is as written above. We also postponed some of the work in didFinishLaunch, which help a bit... But maybe we are trying to achieve the impossible? Could it be that large apps just can't reach the golden 500ms goal? Currently we are trying to create an "umbrella" library for all the third parties in order to force them to become part of the mergeable libraries. We would like to know if, are we on the right track?

I am a developer creating an app for iOS 16 and my app mysteriously started showing a blank screen during previews and the simulator. I profiled the app launch with Instruments, and the results said that dlopen was running on the main thread for the whole minutes of profiling:

As SwiftUI adoption grows, developers face challenges in effectively measuring and optimizing SwiftUI app performance within automated tests. Currently, the only viable approach to analyzing SwiftUI performance is through Profiling (Instruments), which, while powerful, lacks the ability to be incorporated into automated testing workflows. It would be incredibly valuable if XCTest could introduce new performance metrics specifically tailored for SwiftUI, allowing us to write tests against common performance bottlenecks. Suggested Metrics: View Body Evaluation Count – Tracks how often a SwiftUI body is recomputed to detect unnecessary re-renders. Slow View Bodies – Flags SwiftUI views that take a significant amount of time to compute their body. These metrics would help developers identify inefficiencies early, enforce performance best practices through CI/CD pipelines, and ensure a smooth user experience. I believe adding these performance metrics would be a game-changer for SwiftUI development. Thank you for your time and consideration!

I'm developing a library and using XCTest for unit tests. While trying to profile the test suite, I noticed that Instruments seems to report a leak every single time the async throwing setup function is called, no matter what. For example, This will report a leak: final class LeakTests: XCTestCase { override func setUp() async throws { try await super.setUp() } func testLeak() async throws { try await Task.sleep(nanoseconds: 5_000_000_000) } } This will not report a leak: final class LeakTests: XCTestCase { // override func setUp() async throws { // try await super.setUp() // } func testLeak() async throws { try await Task.sleep(nanoseconds: 5_000_000_000) } } Any ideas on why this might be happening, or should I just file a bug report? It makes it quite difficult to use the leak detection for unit tests, as it shows hundreds of leaks when the whole suite is ran.

Our team is currently handling hang issues and logs received by the Organizer during our project. Regarding the xCode Organizer, we’d like to ask a few questions: The hang rate is presented as a bar chart for each app version. Is there any way to get detailed information for each versions? For example, what percentage of the hang rate is attributed to users on different iOS versions? We've encountered a situation where the hang logs have decreased, but the hang rate has increased. Could you explain why this might occur? I was wondering how the hang rate is sampled. For instance, does it record all users who experience a hang, or only those under specific conditions? The situation is that we can see only a handful of hang logs (around 13), but we have hundreds of thousands of DAUs. This ratio seems quite off. Could you explain what might cause us to receive such a small number of logs for each version?

Hey, In the UI of the Instruments app, I can change the recording mode to immediate. Is that possible when using xctrace? It seems to use deferred as a default. I've tried to create a template, set the recording mode to immediate, and use that template for recording. However, that doesn't seem to work. At least the exported TOC of the .trace will have the following summary: <summary> <start-date>2025-01-11T13:00:11.365+01:00</start-date> <end-date>2025-01-11T13:00:30.525+01:00</end-date> <duration>19.160279</duration> <end-reason>Target app exited</end-reason> <instruments-version>16.0 (16A242d)</instruments-version> <template-name>core_animation_fps</template-name> <recording-mode>Deferred</recording-mode> <time-limit>12 hours</time-limit> </summary> This issue might be related to: https://developer.apple.com/forums/thread/735948 Thanks a lot!

Hello, I would like to obtain the average CPU usage of a trace I ran through instruments by looking at the cpu profiler. Is there any way to do this? Or should I be using another instrument.

I'm having an issue with my swiftui macOS application where it is continually consuming more memory over time and after a couple of hours will grind to a halt. I've watched a few videos now on how to use Xcode Memory Graph and Instruments to identify the source of a leak (I assume it is a leak). These videos all provide very obvious issues as examples but mine seems more elusive and I don't know how to identify which part of my code is the cause of the issue. After running instruments I see the following but the leaked objects are not always consistent: Xcode Memory Graph shows NSSet as the culprit which is shown under CoreFoundation (not my App). I really am a beginner here and because it's not showing me somewhere in my app that I can go and investigate I'm really stuck.

I am experiencing a crash on iOS 18 for some devices when the app becomes active again after being inactive for one or two days, with the following details: Crash Information: Thread: com.apple.main-thread Exception: EXC_BAD_ACCESS KERN_INVALID_ADDRESS The crash occurs intermittently on certain devices, but I haven’t been able to reproduce it consistently. Based on the crash logs, it seems to be related to accessing an invalid or corrupted memory address. But if user try to uninstall the app or restart the device, the issue is gone . Is this a known issue in iOS 18? Are there any official workarounds or fixes? Could this be related to specific device configurations, such as limited memory on older models? Are there any known APIs or frameworks in iOS 18 that could trigger such an issue? What additional debugging steps would you recommend to narrow down the root cause? Have other developers encountered similar crashes in iOS 18? Thank you for your help! I appreciate any insights or suggestions.

While I was recently profiling some code from a Swift library, I noticed that XCTest added in signposts for the measurement tests, which I found really helpful to "home in" on the code I wanted to profile digging around in the stack trace. I tried to add my own signposts to provide just a bit of my own markers in there, but while it compiles and profiles equivalently, the signposts just aren't showing up. This is with Xcode 16.1, macOS Sequoia (15.1) and a swift library, using XCTest and profiling within one of the unit tests. Is there something in this sequence that doesn't allow the library to set up signposts and have instruments collect them? The flow I'm using: import os let subsystem = "MyLibrary" class MyClass { let logger: Logger = .init(subsystem: subsystem, category: "fastloop") let signposter: OSSignposter init() { signposter = OSSignposter(logger: logger) } func goFast() { let signpostId = signposter.makeSignpostID() let state = signposter.beginInterval("tick", id: signpostId) // ... do a bunch of work here - all synchronous signposter.endInterval("tick", state) } } Is there something I'm doing incorrectly in using this API, or not enabling to allow those signposts to be collected by the profiler? I do see the signposts that XCTests injects into the system, just not any of the ones I'm creating.

I've been developing an app for macOS for some time. As I've been approaching the app's final development stages, I decided to try Instruments as I've suspected a memory leak was occurring, since my app's memory usage slowly grows over time. Instruments has found one leak, and I've spent considerable time trying to find the cause. Long story short, I've ended up with just an EmptyView() and Instruments were still showing a leak. I've tried creating a new project with a placeholder "Hello, world!" text, and Instruments were still detecting a leak. Am I doing something wrong here? Maybe I'm not using Instruments correctly? Or is this a bug? My Instruments version is 16.0, macOS Sequoia 15.1.

Hi Apple Engineers, I am encountering an issue where the memory usage reported by the Xcode memory report and the Xcode Instruments memory profiler are not aligned. Specifically: Xcode Memory Report: After implementing autoreleasepool, URLSession reading a zip file, and moving the task inside DispatchQueue.global().async, the memory usage goes down from 900MB to 450MB, indicating a potential memory leak. Xcode Instruments Memory Profiler: The memory usage goes down from 900MB to 100MB, suggesting that the memory has been properly released and there is no significant memory leak. Could you please help me understand the discrepancy between these two tools and provide guidance on the appropriate way to interpret the memory usage in my application? Which result I should rely on it? I would greatly appreciate your insights and expertise on this matter. Thank you in advance for your assistance.