-
Notifications
You must be signed in to change notification settings - Fork 20
Description
Commit: 1cece54
I'm running into an interesting issue. Both my XPC server and client are sandboxed and have the requirement .sameTeamIdentifier. After handling about 2000 XPC requests, the following error is logged for every single XPC request:
YourAppNameHere exhausted sandbox memory capacity; may be leaking extensionsThe problem originates here:
| _ = try URL(resolvingBookmarkData: clientBookmark, bookmarkDataIsStale: &isStale) |
The resulting URL is a security-scoped bookmark, meaning a sandbox exception is temporarily granted by the kernel (which stores this information in wired memory, which is finite).
To revoke the exception and release the kernel resources, the following method has to be called on the URL: stopAccessingSecurityScopedResource()
This currently doesn't happen in SecureXPC, so the app leaks kernel memory.
However, the security-scoped resource needs to stay alive until the XPC request is handled, so calling stopAccessingSecurityScopedResource() right after creating the URL won't work (XPC requests will fail).
I've implemented a simple workaround, but that 1) still leaks the first bookmark 2) only works on macOS 11.2 and up, so it's probably not up to this project's standards:
Of course, stopAccessingSecurityScopedResource() could also be called in the XPC client app after the XPC request succeeded or failed.
I'm willing to work on this if you tell me your preferred way.