mirror of
https://github.com/wanghongenpin/proxypin.git
synced 2026-05-14 15:48:03 +08:00
71e49421ae
Three issues raised by ultrareview on top of the previous review pass:
1. (regression) findPidByLocalTcpPort accepted any TCP socket whose
insi_lport matched, including LISTEN sockets. The original
`lsof | grep "${port}->"` excluded LISTEN entries implicitly via the
"->" filter (LISTEN renders as `*:port (LISTEN)`, no `->`). When a
long-running daemon LISTENs on a port that coincides with a client's
ephemeral source port, proc_listpids hits the lower-PID daemon first
and misattributes the request; with the new 30s pid cache the wrong
PID stuck for 30s of follow-up requests. Now skip sockets with
insi_fport == 0 (the LISTEN signature) to mirror the old grep filter
exactly.
2. (pre-existing) getProcess in the macOS path unconditionally appended
".app" to the executable path, producing non-existent paths like
"/usr/bin/curl.app" for non-bundle binaries. This poisoned the icon
cache with empty bytes for 5 minutes. Now only append when the path
actually contains ".app/"; standalone binaries use the executable
path verbatim.
3. (nit) pidBuf/sockBuf were allocated before the outer try, leaking on
the (extremely rare) case that the second calloc throws. Moved both
allocations inside the try with null-aware free in finally, matching
the pattern the inner fdBuf loop already uses.
Verified:
- LISTEN-only port -> FFI returns null (matches lsof+grep behavior)
- ESTABLISHED outbound -> FFI returns the correct client PID
- 500 concurrent curl through proxy -> single ProxyPin process, no
fork leaks (original #763 fix preserved)