One could probably come up with a minimal repro case, but I'm not an experienced MacOS dev so I don't think it's worth me spending many hours to learn how to write one.
I work on Warp, a MacOS terminal - http://warp.dev - which does a lot of process spawning via fork/exec (as one would expect from a terminal). I discovered that processes run by shells that we spawn contain an open file descriptor like /Users/david/Library/Caches/SentryCrash/WarpDev/Data/ConsoleLog.txt.
Here are the steps I take to reproduce it:
Install and launch Warp
Run a process (I use htop here)
In a separate session, use ps to get the process ID of htop and then use lsof -p $PID to look at the list of open file descriptors for the htop process
Expected Result
I would expect there to be no Sentry-related file descriptors open in subprocesses spawned from a Sentry-monitored application. (One possible fix would be passing O_CLOEXEC on calls to open() to ensure these file descriptors get closed whenever an exec() call occurs.)
Actual Result
Here's what I get when running lsof -p $PID for htop (with some irrelevant entries elided):
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
htop 97835 david cwd DIR 1,16 288 15732236 /Users/david/src/channel-versions
htop 97835 david txt REG 1,16 244272 21141391 /opt/homebrew/Cellar/htop/3.2.1/bin/htop
htop 97835 david txt REG 1,16 350016 3252093 /opt/homebrew/Cellar/ncurses/6.3/lib/libncursesw.6.dylib
htop 97835 david txt REG 1,16 2160656 1152921500312781597 /usr/lib/dyld
htop 97835 david 0u CHR 16,9 0t228056 5365 /dev/ttys009
htop 97835 david 1u CHR 16,9 0t228056 5365 /dev/ttys009
htop 97835 david 2u CHR 16,9 0t228056 5365 /dev/ttys009
htop 97835 david 23w REG 1,16 0 513077 /Users/david/Library/Caches/SentryCrash/WarpDev/Data/ConsoleLog.txt
Platform
macOS
Installed
Carthage
Version
7.20.0
Steps to Reproduce
One could probably come up with a minimal repro case, but I'm not an experienced MacOS dev so I don't think it's worth me spending many hours to learn how to write one.
I work on Warp, a MacOS terminal - http://warp.dev - which does a lot of process spawning via fork/exec (as one would expect from a terminal). I discovered that processes run by shells that we spawn contain an open file descriptor like
/Users/david/Library/Caches/SentryCrash/WarpDev/Data/ConsoleLog.txt
.Here are the steps I take to reproduce it:
htop
here)ps
to get the process ID ofhtop
and then uselsof -p $PID
to look at the list of open file descriptors for thehtop
processExpected Result
I would expect there to be no Sentry-related file descriptors open in subprocesses spawned from a Sentry-monitored application. (One possible fix would be passing
O_CLOEXEC
on calls toopen()
to ensure these file descriptors get closed whenever anexec()
call occurs.)Actual Result
Here's what I get when running
lsof -p $PID
forhtop
(with some irrelevant entries elided):