Thanks, Eskimo. The testing code is intentional not for singleton, just want to confirm there is no memory leak if I did so:)

Thanks OOPer, I just wan to compare the app path for different OS version: std::vector<Config> gConfigs = { {@APP_PATH, @OSVersion}, ...}; ... In the compare: if (@available(@OSVersion, *) {...} Is there any avaiable API?

[[NSProcessInfo processInfo] operatingSystemVersion] 

Thanks, OOPer. I just do [[NSNotificationCenter defaultCenter] removeObserver:self] inside the block. There are only call stacks of system libraries in the crash log, not my own app stack involved. I only see this crash once. Btw: why I can see NSWindow _finishClosingWindow when launching my App?

Thanks, OOPer. I remove the observer in the notification block. Btw: I just saw this crash once and there have call stacks of the system only, also I am not sure when there is -[NSWindow _finishClosingWindow] when launching my App.

could be a system bug? since looks like the infinite "close" send from _NSThemeCloseWidget, no stack of the App is involved...

I will do it, thanks a lot! @eskimo. Btw: I feel there is a security concern if a process is muted by path, let's say if I muted a trusted process by path, however, the process might be replaced by a totally different one with the same path, then the events of the "new" one also are muted, right?

Hi @eskimo, I verified this issue can not be reproduced on 12.0.1. Looks Apple fixed it:)

just found if any variable even primitive types captured by the block of setTerminationHandler, then there is a leak: void testLeaks() {    int abc = 123; NSTask* task = [[NSTask alloc] init]; [task setTerminationHandler:^(NSTask* inTask) { NSLog(@"setTerminationHandler %d %d", inTask.terminationStatus, abc);    }];    [task release]; } The output is the same: Process 10635: 593 nodes malloced for 59 KB Process 10635: 1 leak for 48 total leaked bytes. 1 (48 bytes) ROOT LEAK: <__NSMallocBlock__ 0x7f935ed09690> [48] testLeaks2 invocation function for block in testLeaks() 0x10a6a27e0

Thanks a lot, @eskimo. Please refer to FB9942875.

For CFNetwork, we could set credentials by CFHTTPMessageApplyCredentialDictionary before the request if we got it already.

Thanks eskimo. Could we do: reduce the first "CONNECT" by adding a "Proxy-Authorization" header if we already got the credential? it's ok for the 2 "CONNECTs" for the 1st request, but how about the following requests? Do we have the same 2 "CONNECTs" for each request to the same proxy server? is there any way in "NSURLSession" to reuse the credential from 1st request for the following request? If we use CFNetwork, then we can use CFHTTPMessageApplyCredentialDictionary to set the credential which is from the 1st request for the following request to avoid 2 "CONNECTS".

Thanks, @eskimo for your help. Yes, I still see the leaks caused by cycle reference? Report Version: 7 Analysis Tool:  /usr/bin/leaks Physical footprint:     2720K Physical footprint (peak): 2720K ---- leaks Report Version: 4.0 Process 43967: 787 nodes malloced for 85 KB Process 43967: 8 leaks for 800 total leaked bytes.   8 (800 bytes) ROOT CYCLE: <CFRunLoopSource 0x600003034000> [192]     7 (608 bytes) ROOT CYCLE: 0x600003c30000 [224]      CYCLE BACK TO <CFRunLoopSource 0x600003034000> [192]      5 (352 bytes) ROOT CYCLE: 0x600002b34a80 [128]        2 (80 bytes) ROOT CYCLE: 0x600000536c80 [32]         1 (48 bytes) ROOT CYCLE: <__NSMallocBlock__ 0x600000b34c00> [48] CFNetwork <unknown-symbol> 0x7ff819c39000 + 1605859 0x7ff819dc10e3        1 (32 bytes) ROOT CYCLE: 0x600000536ce0 [32]        1 (112 bytes) <NSURL 0x600002e344d0> [112] "http://example.com/"      1 (32 bytes) 0x600000538140 [32] Btw: If I use __bridge_transfer to replace the CFBridgingRelease in your code, then I get more leaks including the proxies. CFArrayRef proxiesArray = CFNetworkCopyProxiesForAutoConfigurationScript((__bridge CFStringRef)pac, (__bridge CFURLRef) url, &err); NSArray *proxies = (__bridge_transfer NSArray *)proxiesArray; more leaks: Report Version: 7 Analysis Tool:  /usr/bin/leaks Physical footprint:     2764K Physical footprint (peak): 2764K ---- leaks Report Version: 4.0 Process 44061: 786 nodes malloced for 85 KB Process 44061: 17 leaks for 1232 total leaked bytes.   17 (1.20K) ROOT CYCLE: <CFRunLoopSource 0x600003888000> [192]     16 (1.02K) ROOT CYCLE: 0x60000348c000 [224]      CYCLE BACK TO <CFRunLoopSource 0x600003888000> [192]      5 (352 bytes) ROOT CYCLE: 0x60000239c280 [128]        2 (80 bytes) ROOT CYCLE: 0x600000d9c220 [32]         1 (48 bytes) ROOT CYCLE: <__NSMallocBlock__ 0x60000039c000> [48] CFNetwork <unknown-symbol> 0x7ff819c39000 + 1605859 0x7ff819dc10e3        1 (32 bytes) ROOT CYCLE: 0x600000d9c280 [32]        1 (112 bytes) <NSURL 0x6000026980e0> [112] "http://example.com/"      9 (432 bytes) <CFArray 0x600001884200> [64] item count: 2        5 (240 bytes) <NSDictionary 0x6000018841c0> [64] item count: 3         1 (48 bytes) <CFString 0x600000384060> [48] length: 21 "kCFProxyPortNumberKey"         1 (48 bytes) <CFString 0x6000003840c0> [48] length: 16 "kCFProxyTypeHTTP"         1 (48 bytes) _list --> <CFString 0x600000384090> [48] length: 19 "kCFProxyHostNameKey"         1 (32 bytes) <CFString 0x600000d84060> [32] length: 11 "192.168.1.2"        3 (128 bytes) <NSDictionary 0x600000d84080> [32]         1 (48 bytes) _key --> <CFString 0x600000384030> [48] length: 15 "kCFProxyTypeKey"         1 (48 bytes) _obj --> <CFString 0x6000003840f0> [48] length: 16 "kCFProxyTypeNone"      1 (32 bytes) 0x600000d840a0 [32] What's the difference between __bridge_transfer and CFBridgingRelease? Both are used to transfer ownership of a Core Foundation object to an Objective-C object, right?

Instead of traversing certs to check, I just found a API which can help to check customized cert installed and trusted: SecTrustCreateWithCertificates.

Thanks, @meaton. What I am asking is for CFNetworkExecuteProxyAutoConfigurationURL(https://developer.apple.com/documentation/cfnetwork/1426392-cfnetworkexecuteproxyautoconfigu?language=objc), such as below code: CFRunLoopSourceRef source(CFNetworkExecuteProxyAutoConfigurationURL(pacURLRef, targetURLRef, callback, &context)); It would download a PAC and executes it. However, looks like it would not download PAC for each invocation. I think there might have a cache related to CFNetwork in its implementation. I want it to send a new request to download PAC for each invocation instead of using a cached one. So far I can reach that goal by implementing the download PAC part and feeding its content to CFNetworkExecuteProxyAutoConfigurationScript. Not sure if there is a simple way to disable the "cache" for API CFNetworkExecuteProxyAutoConfigurationURL or not.