Hi guys,
I observed the infinite connection callback(inSelector) for some Bluetooth devices (such as an iPhone SE or Mac Mini) even when I powered off them. However, the issue is not reproducible easily.
(IOBluetoothUserNotification *)registerForConnectNotifications:(id)observer
selector:(SEL)inSelector
ble.txt
Looks like there are many -[CBManager xpcConnectionDidReceiveMsg:args:] calls when the issue occurs based on the sample, so it might be caused by the XPC connection with bluetoothd?
Has anyone else experienced this issue, or any workaround for it? such as should I restart the bluetoothd?
Post
Replies
Boosts
Views
Activity
Hi Experts,
When experimenting with NEFilterDataProvider, I observed that whole ICMP data flows are visible on the local machine when pinging a remote machine from it. However, no ICMP data flows are observed on the local machine when the remote machine pings it.
Below is the rule for filtering any protocol with any direction.
NEFilterRule(networkRule: .init(
remoteNetwork: nil,
remotePrefix: 0,
localNetwork: nil,
localPrefix: 0,
protocol: .any,
direction: .any), action: .filterData)
There is no issue for TCP/UDP. May I know it's a bug or by design?
Please anyone suggest how to disable App Transport Security completely by enabling NSAllowsArbitraryLoads for the daemon process since it does not have info.plist on macOS? or can I add those config in the corresponding ***.plist in /Library/LaunchDaemon/? Thanks in advance.
Hi Experts,
My app contains a system extension(VPN network extension), but it somehow can not be launched after multiple activations(via OSSystemExtensionRequest activationRequestForExtension) without deactivation.
I just found my extension can be restarted automatically if I kill nesessionmanager in such case, so 2 questions:
it's a system bug or misuse API that my system extension can not restart after several activations by activationRequestForExtension without deactivation first?
is there any official way to restart nesessionmanger instead of killing it?
Hi Experts,
I found the request for PAC was not triggered each time when using CFNetworkExecuteProxyAutoConfigurationURL.
Looks like there is a cache inside, if so how can I disable that cache? like NSURLRequestReloadIgnoringLocalCacheData?
Thanks in advance.
Btw, so far if I update any proxy setting of the system or wait for some time, then the "cache" will be refreshed and new request will be sent when using CFNetworkExecuteProxyAutoConfigurationURL.
let query: [String: Any] = [
kSecClass as String: kSecClassCertificate,
kSecMatchLimit as String: kSecMatchLimitAll
]
var result: CFTypeRef?
let status = SecItemCopyMatching(query as CFDictionary, &result)
guard status == errSecSuccess else {
print("Error retrieving certificates: \(status)")
return true
}
It works on macOS, but always gets -25300(errSecItemNotFound) on iOS, so looks it won't be possible to do an equivalent in iOS given the app ecosystem is sandboxed?
Hi Experts,
I created a simple application with the following code to retrieve the proxy info based on PAC file or PAC URL such as Xcode:
NSString *strURL = @"http://example.com";
NSString *pacFileData = @"function FindProxyForURL(url, host) {if (dnsDomainIs(host, \"example.com\") || dnsDomainIs(host, \"www.example.com\")) {return \"PROXY 192.168.1.2:8888;DIRECT\";}return \"DIRECT\";}";
CFStringRef tempPacdata = CFStringCreateCopy(kCFAllocatorDefault, (__bridge CFStringRef)pacFileData);
CFURLRef tempURLref = CFURLCreateWithString(kCFAllocatorDefault, (__bridge CFStringRef)strURL, nil);
CFArrayRef proxies = CFNetworkCopyProxiesForAutoConfigurationScript(tempPacdata, tempURLref, &err);
strURL = nil;
if (proxies != NULL)
{
CFRelease(proxies);
proxies = NULL;
}
if (tempPacdata != NULL)
{
CFRelease(tempPacdata);
tempPacdata = NULL;
}
if (tempURLref != NULL)
{
CFRelease(tempURLref);
tempURLref = NULL;
}
The output of leaks:
Report Version: 7
Analysis Tool: /usr/bin/leaks
Physical footprint: 2700K
Physical footprint (peak): 2700K
----
leaks Report Version: 4.0
Process 43271: 783 nodes malloced for 85 KB
Process 43271: 17 leaks for 1232 total leaked bytes.
17 (1.20K) ROOT CYCLE: <CFRunLoopSource 0x6000002f8000> [192]
16 (1.02K) ROOT CYCLE: 0x600000ef80e0 [224]
CYCLE BACK TO <CFRunLoopSource 0x6000002f8000> [192]
5 (352 bytes) ROOT CYCLE: 0x6000019f4400 [128]
2 (80 bytes) ROOT CYCLE: 0x6000037e8220 [32]
1 (48 bytes) ROOT CYCLE: <__NSMallocBlock__ 0x6000039e8030> [48] CFNetwork <unknown-symbol> 0x7ff819c39000 + 1605859 0x7ff819dc10e3
1 (32 bytes) ROOT CYCLE: 0x6000037e8240 [32]
1 (112 bytes) <NSURL 0x600001cf4000> [112] "http://example.com/"
9 (432 bytes) <CFArray 0x6000022f87c0> [64] item count: 2
5 (240 bytes) <NSDictionary 0x6000022f8780> [64] item count: 3
1 (48 bytes) <CFString 0x6000039f8c60> [48] length: 16 "kCFProxyTypeHTTP"
1 (48 bytes) <CFString 0x6000039f8d50> [48] length: 21 "kCFProxyPortNumberKey"
1 (48 bytes) _list --> <CFString 0x6000039f8cf0> [48] length: 19 "kCFProxyHostNameKey"
1 (32 bytes) <CFString 0x6000037fab00> [32] length: 11 "192.168.1.2"
3 (128 bytes) <NSDictionary 0x6000037fab20> [32]
1 (48 bytes) _key --> <CFString 0x6000039f8c00> [48] length: 15 "kCFProxyTypeKey"
1 (48 bytes) _obj --> <CFString 0x6000039f8cc0> [48] length: 16 "kCFProxyTypeNone"
1 (32 bytes) 0x6000037fab40 [32]
Does that mean some bugs in those APIs?
According to the document:
"the URL Loading System handles various aspects of the HTTP protocol for you (HTTP 1.1 persistent connections, proxies, authentication, and so on). As part of this support, the URL Loading System takes responsibility for certain HTTP headers:
Content-Length
Authorization
Connection
Host
Proxy-Authenticate
Proxy-Authorization
WWW-Authenticate
If you set a value for one of these reserved headers, the system may ignore the value you set, or overwrite it with its own value, or simply not send it. Moreover, the exact behavior may change over time. To avoid confusing problems like this, do not set these headers directly."
Looks like we'd better avoid setting "proxy-authorization" directly:
[req setValue:authenticationValue forHTTPHeaderField:@"Proxy-Authorization"]; or [config setHTTPAdditionalHeaders:@{@"Proxy-Authorization": authHeader } ];, instead, should go to the session delegate.
However, we would have 2 "requests" if we follow the authentication challenge if we have credentials already: https://developer.apple.com/documentation/foundation/url_loading_system/handling_an_authentication_challenge?language=objc.
So is there any API or other safe way to set "Proxy-Authorization" for nsurlsessionconfig at the "beginning" if we got the credential already?
Thanks in advance.
Hi @eskimo and experts,
I created a simple code and found there is a memory leak:
#import <Foundation/Foundation.h>
#include <functional>
void testLeaks(const std::function <void (int)>& inCallback) {
NSTask* task = [[NSTask alloc] init];
[task setTerminationHandler:^(NSTask* inTask) {
inCallback(inTask.terminationStatus);
}];
[task release];
}
int main(int argc, const char * argv[]) {
auto callback = [](int result) {
NSLog(@"callback");
};
testLeaks(callback);
NSLog(@"done");
return 0;
}
The output of leaks:
Process: testLeaks2 [13084]
Path: /Users/USER/Library/Developer/Xcode/DerivedData/Build/Products/Debug/testLeaks2
Load Address: 0x10a04d000
Identifier: testLeaks2
Version: ???
Code Type: X86-64
Platform: macOS
Parent Process: leaks [13083]
Date/Time: 2022-02-28 23:34:28.374 +0800
Launch Time: 2022-02-28 23:34:27.939 +0800
OS Version: Mac OS X 10.15.6 (19G73)
Report Version: 7
Analysis Tool: /Applications/Xcode.app/Contents/Developer/usr/bin/leaks
Analysis Tool Version: Xcode 12.4 (12D4e)
----
leaks Report Version: 4.0
Process 13084: 596 nodes malloced for 59 KB
Process 13084: 1 leak for 48 total leaked bytes.
1 (48 bytes) ROOT LEAK: <__NSMallocBlock__ 0x7fbbc2704350> [48] testLeaks2 invocation function for block in testLeaks(std::__1::function<void (int)> const&) 0..."
Looks the issue is in the block of setTerminationHandler. How do I address this memory leak issue if I want to keep using std::function as a callback?
Hi Experts,
I created a simple application with the following code to retrieve the signing info from Apps such as Xcode:
CFURLRef appURLRef = NULL;
SecStaticCodeRef staticCodeRef = NULL;
CFDictionaryRef signatureInfoRef = NULL;
do {
appURLRef = CFURLCreateWithFileSystemPath(kCFAllocatorDefault, CFSTR("/Applications/Xcode.app"), kCFURLPOSIXPathStyle, YES);
if(!appURLRef) {
break;
}
OSStatus status = SecStaticCodeCreateWithPath(appURLRef, kSecCSDefaultFlags, &staticCodeRef);
if(errSecSuccess != status) {
break;
}
status = SecCodeCopySigningInformation(staticCodeRef, kSecCSSigningInformation, &signatureInfoRef);
if(errSecSuccess != status) {
break;
}
} while(0);
if(staticCodeRef) {
CFRelease(staticCodeRef);
staticCodeRef = NULL;
}
if(signatureInfoRef) {
CFRelease(signatureInfoRef);
signatureInfoRef = NULL;
}
if(appURLRef) {
CFRelease(appURLRef);
appURLRef = NULL;
}
then I use leaks to check if any memory issues, the output is:
Process: checksig [4733]
Path: /Users/USER/Library/Developer/Xcode/DerivedData/Build/Products/Debug/checksig
Load Address: 0x10e033000
Identifier: checksig
Version: ???
Code Type: X86-64
Platform: macOS
Parent Process: leaks [4732]
Date/Time: 2022-02-13 23:10:32.606 +0800
Launch Time: 2022-02-13 23:10:32.109 +0800
OS Version: Mac OS X 10.15.6 (19G73)
Report Version: 7
Analysis Tool: /Applications/Xcode.app/Contents/Developer/usr/bin/leaks
Analysis Tool Version: Xcode 12.4 (12D4e)
----
leaks Report Version: 4.0
Process 4733: 3725 nodes malloced for 456 KB
Process 4733: 1 leak for 32 total leaked bytes.
1 (32 bytes) ROOT LEAK: 0x7ffc33d04c00 [32] length: 23 ",CSSMERR_CL_UNKNOWN_TAG"
If I remove the SecCodeCopySigningInformation line, then the issue is gone.
So there is a memory leak in API SecCodeCopySigningInformation? or in my code or sth incorrect in the report of leaks?
Did anybody see the same issue before? thanks a lot!
Hi Experts,
Looks like es_mute_path_*** are deprecated, so does anyone know if there has some new APIs? Thanks!
https://developer.apple.com/documentation/endpointsecurity/3366123-es_mute_path_prefix
Hi Expert,
When I launched my App, just saw the following crash once:
crash log
Looks like there is something dead loop in the system libraries? related to NSNotificationCenter? any clue on this? Thanks a lot.
Hi Expert,
I found the value of kDADiskDescriptionVolumeUUIDKey changed after upgrading to BigSur from Catalina, so it should not be used to identify a unique machine?
Btw: I found there is another unique hardware UUID in "system_profiler SPHardwareDataType"
NEFilterManager * mgr = [NEFilterManager sharedManager];
...
NSString *description = [mgr localizedDescription]
Hi Experts,
I can get another NEFilterManager instance if there are multi-network profilers in the Network panel.
The above code is in a different background process(bundle id) than the main process without any entitlement. I can only get the correct NEFilterManager instance associated with the main process, is it by design? how to get a specified NEFilterManager instance in the background process?
I ran a test code with ThreadSanitizer, it throws a race condition in the block of xpcconnectionseteventhandler even I set a sync queue to the connection. xpc_connection_set_event_handler(conn, ^(xpc_object_t event) {
xpc_type_t type = xpc_get_type(event);
if (xpc_get_type(event) == XPC_TYPE_DICTIONARY) {
		// race condition here
		// WARNING: ThreadSanitizer: data race
// ...
} else {
if (event == XPCERRORCONNECTIONINVALID) {
// Error indicates the peer has closed the connection.
// Tear down any associated data structures.
} else {
// Error indicates that service will terminate soon.
// Flush all buffers, finish all work, etc.
}
xpcrelease(peer);
}
});
https://developer.apple.com/documentation/xpc/1448786-xpc_connection_set_target_queue?language=objc:
"the XPC runtime guarantees that, when the target queue is a serial queue, the event handler block will execute synchronously with respect to other blocks submitted to that same queue. When the target queue is a concurrent queue, the event handler block may run concurrently with other blocks submitted to that queue, but it will never run concurrently with other invocations of itself for the same connection"
looks like there should have no race condition according to the above description, but why I encounter the race condition issue reported by ThreadSanitizer?
Does the block of xpcconnectionseteventhandler need sync to avoid race condition?