Repository navigation
Stop xclip from holding a launcher's captured output streams - #9419
Conversation
ClipboardXclip._clip only redirected the stream it actively uses, so the xclip selection owner inherited the launcher's remaining stdout/stderr. When a launcher captures Kivy's output, that surviving process keeps the pipe open after the Kivy child exits, so the launcher never sees EOF. Redirect all three streams to DEVNULL and pipe only the one in use. Add a regression test that round-trips both selections through real xclip/X11 and requires captured-output EOF once the child exits. Fixes kivy#9418 Signed-off-by: Charan Rathore <[email protected]>
|
Thanks for the fix. I reproduced the problem and confirmed the change works. I ran your test logic on Ubuntu (WSL) under Xvfb with real BLOCKER: the new tests don't run in CI. Small suggestion:
|
The new tests were skipped in CI because xclip was not installed there. Also fail with 'xclip is still holding the output pipe' instead of a raw TimeoutExpired when communicate() times out. Signed-off-by: Charan Rathore <[email protected]>
|
Thanks for verifying on real xclip. Both points are in 17de9ec: xclip is added to the Ubuntu CI apt line so the tests actually run there, and a communicate() timeout now fails with "xclip is still holding the output pipe" instead of a raw TimeoutExpired. |
|
@kuzeyron I have tested this fix and it is ready for approval |
|
The backport to To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-devel-2.3.x devel-2.3.x
# Navigate to the new working tree
cd .worktrees/backport-devel-2.3.x
# Create a new branch
git switch --create backport-9419-to-devel-2.3.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 261b89e28032cc9aaaae87220bb587c345cb3ee4
# Push it to GitHub
git push --set-upstream origin backport-9419-to-devel-2.3.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-devel-2.3.xThen, create a pull request where the |
On X11, quitting an app that had used the xclip clipboard left the process's captured output streams open: xclip forks to keep serving the selection and inherits the launcher's pipes, so anything reading them (a test runner, a supervisor, a shell pipeline) never saw EOF and the process looked hung after exit.
Fix
kivy/core/clipboard/clipboard_xclip.py: redirect the two streams xclip does not use to/dev/null; only the pipe for the requested selection direction stays connected.Testing
kivy/tests/test_clipboard_xclip.pystart xclip through the clipboard and assert the parent's output pipe reaches EOF, for both the clipboard and the primary selection.