Repository navigation
application: Wait for cancellation when stdin is at EOF - #214
Merged
Merged
Conversation
Member
|
Thanks! 🙌 |
With stdin redirected from /dev/null, readline() returns "" right away, so await_enter() stopped the reactor before frida-pull and frida-push did their work, and await_ctrl_c() spun at 100% CPU. When stdin is not a terminal, EOF means no line will ever arrive, so block until cancelled. On a terminal an empty read is Ctrl-D, which still returns as before.
oleavr
force-pushed
the
fix-stdin-eof-wait
branch
from
November 9, 2026 21:13
e525b32 to
30a3a88
Compare
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When stdin is redirected from /dev/null, as it is in CI or under a script,
readline()returns""immediately.await_enter()takes that as Enter and stops the reactor before the tool's work has run, andawait_ctrl_c()keeps calling it in a loop.On main (6bbae44), Linux, local device:
frida-pullprints nothing, exits 0 and writes no file.frida-push $PWD/a.txt $PWD/p.txt </dev/nullcreatesp.txtempty and then hangs. The worker thread is still waiting on a reactor that has stopped, so SIGTERM doesn't end it either and it needskill -9.frida-trace -p <pid> -i nanosleep </dev/nullandfrida-compile -w index.js </dev/nullrun, but at 100% CPU: 498 CPU ticks over 5 s of steady state forfrida-traceon main, 0 with this change.With stdin kept open (
sleep 10 | frida-pull ...) the pull and the push both work.When stdin isn't a terminal, EOF means no line will ever arrive. So
input_with_cancellable()now blocks on the cancellable's fd until it's cancelled, instead of returning the empty string. The Windows path already waits like this, sincemsvcrt.kbhit()never sees stdin's EOF. On a terminal an empty read means Ctrl-D, and that still returns as before. Enter and Ctrl-D still stop a tool that's waiting on them.This does change one thing:
frida-discover </dev/nullused to stop straight away, and now it runs until it's interrupted or the target exits, the same asfrida-trace. If you'd rather EOF on a pipe still meant "stop" there, I can makefrida-discoverkeep the old behaviour.Testing:
tests/test_application.py: a line read from a pipe is returned; at EOF on a pipe the call raisesOperationCancelledErroronce the cancellable is cancelled; and Ctrl-D on a pty still returns"". The pipe EOF test fails on main withOperationCancelledError not raised.python -m unittest discover -s tests -t .: 50 tests OK on main, 53 OK with this change. black, isort and pyflakes are clean.frida-pull,frida-push,frida-rm,frida-lsandfrida-pswith</dev/nullagainst the local device: they finish the same way they do with a terminal.frida-tracestill exits on SIGTERM.