[Bug 794591] New: gst-play-1.0 leaves stdin in non-blocking mode
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Thu Mar 22 10:10:26 UTC 2018
https://bugzilla.gnome.org/show_bug.cgi?id=794591
Bug ID: 794591
Summary: gst-play-1.0 leaves stdin in non-blocking mode
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-plugins-base
Assignee: gstreamer-bugs at lists.freedesktop.org
Reporter: ao2 at ao2.it
QA Contact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
Hi,
I noticed that *after* executing "gst-play-1.0 SOMEFILE" in bash, interactive
cli programs that handle stdin in a special way start to misbehave.
One simple example is:
read SOMEVAR
which fails with the following error:
bash: read: read error: 0: Resource temporarily unavailable
Another command which fails is:
git add -p
where the interactive prompt to choose the action stops working.
The same effect of running gst-play-1.0 can be simulated with this command:
python3 -c $'import os\nos.set_blocking(0, False)'
so it looks like gst-play-1.0 is not resetting the stdin blocking status
correctly.
This is my environment:
Debian Unstable
GStreamer Core Library version 1.14.0
GNU bash, version 4.4.18(1)-release (x86_64-pc-linux-gnu)
The issue does not seem to happen to everybody, Jan Schmidt told me on IRC:
<thaytan> ao2, definitely doesn't happen on Fedora with bash 4.4.19 (or any
other version in the last few years)
The issue does not occur with dash (the Debian POSIX shell), which seems to
reset the blocking status automatically and warns with the following message:
sh: turning off NDELAY mode
However the problem occurs every time here with bash.
I took a look at the code and I am going to send a proof-of-concept patch which
fixes the issue.
Thanks,
Antonio
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list