- Guard against `getProcess` returning null in the macOS FFI path
(`proc_pidpath` can fail with EPERM or for an already-exited PID).
Stop unwrapping with `!` and only populate the ProcessInfoCache on
success; the previous code threw NullThrownError there, which the
outer try/catch silently swallowed and prevented caching of valid
later results.
- Add a 5-second negative cache for ports whose owner can't be
resolved (typical for short-lived clients that exited before we
scanned). Without it every such request triggered a full PID list
rescan, defeating the point of the pid cache for the failure path.
- Add a debug-only assert that the host is little-endian. The libproc
parsing reads `(int)htons(port)` by treating the low two bytes as a
big-endian uint16, which requires a little-endian host. All shipping
macOS hardware satisfies this; the assert fails loudly if the
assumption is ever broken (stripped from release builds).
Re-verified on macOS 26.4: 500 concurrent curl through the proxy,
single ProxyPin process throughout, 9099 freed immediately on exit.
- Add 30s (host:port) -> pid cache in ProcessInfoUtils so the synchronous
libproc scan stays off the request hot path for keep-alive flows
(typical HTTP client reuses the same source port across requests in
a connection).
- Lift sockView ByteData out of the inner fd loop so the buffer wrapper
is reused across all fds in a scan (saves per-fd allocations).
- Bail out of the scan after 16 consecutive proc_pidfdinfo size
mismatches, in case a future macOS bumps the socket_fdinfo layout --
avoids wasted syscalls instead of scanning every fd just to return
null at the end.
Re-verified end-to-end on macOS 26.4: 500 concurrent curl, 0 fork
leaks, 9099 freed immediately on app exit, no errors in logs.
Replace Process.run('lsof') and Process.run('ps') in the request hot
path with direct libproc syscalls (proc_listpids, proc_pidinfo,
proc_pidfdinfo, proc_pidpath) via dart:ffi.
Each Process.run on macOS goes through fork()+execvp(). In a
multi-threaded Dart VM the forked child can deadlock before exec on
mutexes that were held by other threads at fork time (POSIX fork()
only clones the calling thread, leaving cloned mutex state with no
owners in the child). Under proxy load (~500 concurrent requests),
roughly 2% of the fork()s deadlock; the orphaned children inherit the
listening proxy fd and pin it for the lifetime of the system, so the
port stays bound even after the parent app exits.
libproc syscalls do not spawn child processes, so they avoid the fork
problem entirely. They are also about an order of magnitude faster
than spawning lsof per request.
Windows and Linux paths are unchanged (independent follow-up).
Verified end-to-end on macOS 26.4 / Darwin 25.4:
- 500 concurrent curl through the proxy: 0 fork leaks (was ~2% before)
- Process icons still resolve correctly for .app bundles (Chrome,
Safari, Lark, etc.)
- 9099 frees immediately on app exit (no orphan listeners)
Fixes#763
