Xcode Version 15.2 (15C500b) After upgrading Xcode from 14 to 15.2 I am not able to attach system extension (packettunnel) process to Instruments tools for memory debugging. Same is working fine with Xcode 14. Error displayed: "Process No Longer Exists". But the service is running and is listed in process list. % ps -ax | grep -i pkttunnel | grep -v grep 61910 ?? 0:01.04 /Library/SystemExtensions/5F4AF6EF-****-****-****-F11****9CE78/com.******.client.*****-Client.***ui.***pkttunnel.systemextension/Contents/MacOS/com.******.client.*****-Client.***ui.***pkttunnel.systemextension Note: I am able to attach a normal program to Instruments tool for memory debugging, I have noticed this issue with system extension processes only.

If I try to run Instrument's logger for an app downloaded from TestFlight it says "Permission to debug app name was denied". "Recover Suggestion: The app must be debuggable and signed with 'get-task-allow'. How do you make the app debuggable? (I tried creating an archive with the scheme set to Debug, but after uploading that to TestFlight, it doesn't appear. So presumably its not possible to upload an app built with debug scheme builds to TF?). Therefore how can I make a TF build debuggable?, and how to sign it with get-task-allow? Does it have to be a developer distribution .ipa rather than a TestFlight build to enable Instruments/Logger to run it?

I asked a similar question last year, and got no responses. I've written a much simpler (no network extension!) case that seems to demonstrate what I'm confused about. Simple app with an XPC service. I have an ObjectiveC class TestObject which has an NSString* and an NSData* (which I never actually use). I have a protocol defined in Swift: @objc protocol XPCTestServiceProtocol { func logData(entry: TestObject) -> Void func logData(entry: TestObject, completion: ((String) -> Void)) } In the Switt XPC service, the code is: class XPCTestService: NSObject, XPCTestServiceProtocol { var totalBytes = 0 var lastName = "" @objc func logData(entry: TestObject) { totalBytes += (entry.data?.count ?? 0) } @objc func logData(entry: TestObject, completion: ((String) -> Void)) { totalBytes += (entry.data?.count ?? 0) completion("Finished") } I've got this code in the ObjC app: id<XPCTestServiceProtocol> proxy = [self.connection remoteObjectProxyWithErrorHandler:^(NSError* error) { self.stopRun = YES; NSLog(@"Proxy got error %@", error); }]; while (self.stopRun == NO) { @synchronized (self) { NSNumber *objNum = [NSNumber numberWithUnsignedLongLong:self.count++]; NSString *objName = [NSString stringWithFormat:@"Object %@", objNum]; TestObject __weak *toWeak = to; #if USE_COMPLETION [proxy logDataWithEntry:to completion:^(NSString *str) { to = nil; }]; #else [proxy logDataWithEntry:to]; #endif } } attached to a start button (and self.stopRun is set by a stop button, this is all super simple). So I run that, start the test, and things start going (122k calls/second it says). According to Activity Monitor, my app is using about 1gbyte after 20 seconds or so. However, if I run it under Instruments' Leaks template... Activity Monitor says it's used only about 60mbytes. (And at the end of the run, Instruments says it's used about 30mbytes.) Now... if I use the completion and a synchronous proxy, then even without Instruments, Activity Monitor says it's 60mbytes or so. Is the memory reported by Activity Monitor real? Or not real?

Hi, Machine: M1 sonoma 14.1.1 At my test I am using macOS shipped lib of curl, and its default LibreSSL, that is: curl 8.1.2 (x86_64-apple-darwin23.0) libcurl/8.1.2 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.55.1 I am getting memory leaks while running the following test: void CallCurl() { CURL *hnd; hnd = curl_easy_init(); curl_easy_setopt(hnd, CURLOPT_URL, "https://www.google.com"); curl_easy_perform(hnd); curl_easy_cleanup(hnd); } I track the leaks with macOS instruments, and I see that all leaks are from libcrypto. The leaks are measured after curl_easy_cleanup. Examples for the leaks stack frames: serialize_ECPublicKey ECDSA_do_verify_new ossl_ecdsa_verify EVP_DigestVerifyFinal tls13_server_certificate_verify_recv tls13_handshake_perform tls13_legacy_connect ossl_connect_common ssl_cf_connect cf_setup_connect cf_hc_connect Curl_conn_connect multi_runsingle curl_multi_perform curl_easy_perform CallCurl() main start ccMallocECCryptor CCECCryptorImportKey ECDSA_do_verify_new ossl_ecdsa_verify EVP_DigestVerifyFinal tls13_server_certificate_verify_recv tls13_handshake_perform tls13_legacy_connect ossl_connect_common ssl_cf_connect cf_setup_connect cf_hc_connect Curl_conn_connect multi_runsingle curl_multi_perform curl_easy_perform CallCurl() main start ccMallocECCryptor CCECCryptorImportKey ECDSA_do_verify_new ossl_ecdsa_verify EVP_DigestVerifyFinal tls13_server_certificate_verify_recv tls13_handshake_perform tls13_legacy_connect ossl_connect_common ssl_cf_connect cf_setup_connect cf_hc_connect Curl_conn_connect multi_runsingle curl_multi_perform curl_easy_perform CallCurl() main start Any you familiar with memory leaks issues at curl that is shipped with macOS? Is there a workaround? Thx, Moshe.

Hi everyone, I have an AR app that allows for collaborative sessions and synchronizes model state (e.g. rotation, can be changed via slider) using Multipeer Connectivity. The receiving peer parses the data and then uses DispatchQueue.main.async to update the UI (SwiftUI) and the model in SceneKit. Lately I have noticed that this synchronization seems to lag periodically. To analyze the issue better I compiled this minimal reproducible example: https://github.com/MrMuetze/MCSyncTest The repository includes a boiled down "Multipeer Connectivity" project that should make this issue reproducible on local devices (maybe even between one device and the simulator). I have also added a readme with a gif that shows the issue. The synchronization between devices worked like a treat for a long time but recently I have noticed that e.g. a rotation is not as smooth as before on the receiving device. A bit of debugging revealed that the messages are received quickly but then the work that needs to happen on the main thread is periodically delayed. In the example project the relevant code bit that should be executed on the main thread looks like this: func session(_: MCSession, didReceive data: Data, fromPeer _: MCPeerID) { print("received data") DispatchQueue.main.async { print("doing stuff") let doubleVal = data.to(type: Double.self) ?? 0.0 self.internalSliderValue = doubleVal self.sliderValue = doubleVal } } It updates a published variable sliderValue that is connected to a Slider and a Text UI element. Regularly (like every 500ms or so) the execution of work on the main thread seems to be delayed. After a short while all outstanding UI updates are executed at once which leads to visual stuttering. This can be observed by looking at the printed messages: ... received data &lt;-- normal behavior doing stuff received data doing stuff received data doing stuff received data &lt;-- hiccup starts received data received data received data doing stuff doing stuff doing stuff doing stuff received data &lt;-- returns to normal behavior doing stuff received data doing stuff ... I have tried to change the "Quality of Service" to .userInteractive as well as limiting the number of messages that are sent in a certain timeframe (I tried one message every 100ms). Both changes have not helped and even with a much lower number of messages the periodic stuttering remains. Using DispatchQueue.main.sync is also not a solution right now. It does bring the sequence back into original order but the periodic "freeze" of the queue is prevalent there as well. This then leads to a "laggy" execution of what happened on the sending peer device. I am not very familiar with Profiling an app and using Instruments, but I have captured some timings in regards to the usage of the main thread and some backtraces. From what I can understand the workload of the written code should not be the issue, but rather an underlying system function or library. I can provide more information in regards to the backtraces if needed. Right now I can't really say what would be useful. Below is an image that shows the main thread usage at the very top. This happens when the slider lags as shown in the gif. I am working with Xcode 15.2 and run the app on iOS 17.3. For devices I use an iPad Pro (2nd gen.) and an iPhone 15 Pro. The issue happens in Debug as well as in Release mode. I can't quite say when the stuttering appeared initially. I wonder if anyone is aware of any changes to iOS or underlying frameworks that could have caused this issue. I am interested in any information about this, if the issue can be resolved or if I have to look for alternative workarounds. Let me know if I can add any additional information. Best regards! Bjoern

Hi! I watched the 'Analyze hangs with Instruments' video from WWDC2023. It's such a great video! Unfortunately, I found a case that the video doesn't cover when profiling my browser app using Instruments: As shown in the image, the hangs still occur even though my main thread is not busy, and I've also used the 'Thread State Trace instrument' to confirm that the main thread is not blocked either. I'm not sure what the next step is to resolve the hangs. Any insight or guidance would be much appreciated. Thank you!"

Context I'm trying to profile a binary (a simple C++ program compiled into dummy.o) and collect CPU Counters data. I have a configuration that works fine from the Instruments Counters GUI (see Screenshots below). I've exported this configuration to a template file named prof1.tracetemplate. Problem When I try to run a recording with that same template from the command line with xctrace (I also tried with sudo): $ xctrace record --template prof1.tracetemplate --launch dummy.o I get the following errors: Starting recording with the prof1 template. Launching process: dummy.o. Ctrl-C to stop the recording Run issues were detected (trace is still ready to be viewed): [Error] Unexpected failure: Couriers have returned unexpectedly. [Error] Failed to start the recording: Failed to force all hardware CPU counters: 13. [Error] Failed to pause recording session: Cannot pause session session unless it's running. Current state: kSessionError [Error] Unexpected failure: Data source agent failed to arm. Recording failed with errors. Saving output file... Output file saved as: Launch_dummy.o_2024-01-31_14.22.32_0B6E1A78.trace System Chip: Apple M1 macOS: 14.1.1 (23B81) xctrace version: 15.2 (15C500b) xcode version: 15.2 (15C500b) Screenshots

Instruments in XCode 14 used to support CPU counters in A16 with iOS 16.x, but after I upgrade iOS to 17.1 and also XCode to 15.0.1, In "CPU Counters", it says "CPU Name: Unsupported" and thus I cannot choose "Sample by" events etc. Found some link on this:https://stackoverflow.com/questions/77344529/is-latest-instruments-not-support-a17-pro-for-cpu-counters Please help to confirm this is some known issue, and if so, how to fix it. Thanks!

In my iOS project, there is an infrequent crash related to virtual memory problem. Therefore, I plan to use UITest in combination with Product/Perform Action/Profile "TestCaseName" to conduct Game Performance-type testing. This allows the automatic testing to continuously operate until the profile stops recording upon a crash. This enables me to observe the various states of the program at the time of the crash. However, I have found that the UITest using Profile is highly unstable. The UITestCase often terminates unexpectedly during execution, leading to failed tests (Instruments is still working). Sometimes, the app is terminated immediately after startup. It seems that the use of sleep() in the code can easily cause interruption issues, which do not occur during normal UI testing. I am wondering if anyone has experience using Profile for UITest and whether they have encountered the issues I described." Working Environment: XCode14.3.1, iPhone Device iOS17.2

I cannot identify this information on the monitor. Is there something similar to this?

When I use Instruments to record Allocation, the phone will display a dialog box indicating that the phone is unlocked when the screen is locked, as shown in Figure 1. When I have started recording allocation and lock the screen 10s later, the allocation can be recorded normally. For details, see Figure 2. I want to know why. Start recording for 10s and lock the screen on the device. The recording can be performed normally. What is the principle of this?

Instruments freeze when WKWebView is created I create a very simple mac os application If I create a WKWebView like this " (void)viewDidLoad { [super viewDidLoad]; // Do any additional setup after loading the view. self.webview = [[WKWebView alloc] initWithFrame:NSMakeRect(0, 0, 500, 500)]; } " Then the instruments freeze when I record allocations Why? If I remove the creation of WKWebView, everything works fine I'm using Xcode 14.2

I just downloaded Xcode 15 RC and iOS 17 RC on an iPhone Xr. When running the app it seems to run fine however when trying to run in profile mode I get the error: Failed to install embedded profile for com...* : 0xe800801f (Attempted to install a Beta profile without the proper entitlement.) Verify that the Developer App certificate for your account is trusted on your device. Open Settings on the device and navigate to General -> VPN & Device Management, then select your Developer App certificate to trust it. Does anyone have any insight into what the issue may be? There is nothing to select within VPN & Device Management when I navigate there

Steps to reproduce: Open Instruments app Settings Select recording tab (Next to General) Click Open Keyboard Shortcut preferences to produce the aforementioned error. Profiler Version 15.1 (15C65) - Instruments macOs 14.1.2 (23B92) Thanks all.

Hi, I noticed that when I use dyld activity instrument run duration is about 20s Is it possible to customized it? I'd like to set it to something more, so when I start process I would able to capture event that could happen more than 20s after process start thanks

Hey, I'm learning Instruments (Xcode 15.1), and I've encountered a situation for which I haven't found an answer yet. I have an application that loads 12 large images, with the last one taking the most space at 147MB. Instruments on the iOS 15 simulator correctly shows 21 allocations, as in the example from the book, because the last image is split into smaller parts due to poor optimization. But if I run the same example on the iOS 17 simulator, I have even fewer allocations than loaded images. And my question is whether memory allocation for large images is handled differently in iOS 17, or where can I read more about it?

Hi! I have a macOS app and it uses around 2x more CPU when it's not launched by the Xcode debugger. This is not about build optimization or anything. I can use the exact same executable, and when I launch it directly by double clicking it in Finder it's uses 2x as much CPU as when I launch the executable through the Debug > Debug Executable... option in Xcode. I did some CPU profiling in Instruments, and there is only one difference I could find so far when the app is launched by the Xcode debugger: There is an entry in the trace named CA::Context::commit_transaction(CA::Transaction*, double, double) | Quartz Core. This entry always appears. But - If, and only if the app is not launched by the Xcode debugger, this entry has a child entry _dispatch_async_f_slow which itself has children that seem to be related to dispatch queue "introspection". It looks kind of like this: v CA::Context::commit_transaction(CA::Transaction*, double, double) v _dispatch_async_f_slow > _dispatch_introspection_queue_item_enqueue_hook _dispatch_trace_item_push_internal dispatch_introspection_queue_item_get_info > _dispatch_introspection_queue_item_enqueue Now this alone doesn't account for the huge difference in CPU usage, but my best theory is that this dispatch queue introspection stuff is done all over the app, and cumulatively leads to the 2x slowdown. I'm running Xcode Version 15.1 (15C65) macOS 14.1.2 (23B92) M1 MacBook Air If you have any clue how to prevent this slowdown when the Xcode debugger is not attached please let me know. Thank you so much!

Hi, I am trying to debug an issue when running Profile within Xcode, the binary builds and is signed for release. When I inspect the entitlements file, get-task-allow is always false. I have the following settings that I have seen in the forums work for others but to no avail for our setup. CODE_SIGN_INJECT_BASE_ENTITLEMENTS = YES DEPLOYMENT_POSTPROCESSING = NO Using manual signing setup, provisioning profile and certs are working fine and the binary launches fine on device. However when it comes to pressing record in instruments, I get the following: Permission to debug {app bundle ID} was denied. Recovery Suggestion: The app must be debuggable and signed with 'get-task-allow'. I don't have any other ideas on how to debug/troubleshoot this further. Any help would be great, it's an old project so

I'm tracing a process, specifically focusing on the Metal device track, which records frames from other processes like Terminal, WindowServer, and sometimes processes that utilize the GPU. I attempted tracing with all apps closed and only Instruments running. However, it also records traces for Instruments. This behavior wasn't present in previous versions of Instruments. Was there a recent change in Instruments/Xcode 15.0.1? I cannot find any relevant information about this in the release notes either. Is there a way to configure Instruments to record only the running process?

To run UI tests on actual devices, I use the following command to list devices possibly connected to my MAC: xcrun xctrace list devices As you know it shows a list of simulators and actual devices. BUT it also shows actual devices NOT currently connected to my MAC. If they are not currently connected, I do not wish to see them. Once a device is connected, it seems to always show up in the [== Devices ==] list. Even after I disconnect the device it will still show up there. And my software thinks it can run tests on these devices. Does anyone know how to get a correct list of devices which are currently connected to the MAC??