You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 extensions
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:
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 extensions
The problem originates here:
SecureXPC/Sources/SecureXPC/Server/ClientRequirement.swift
Line 380 in 1cece54
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 theURL
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:
andreasley@0b65dbb
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.
The text was updated successfully, but these errors were encountered: