[FFmpeg-devel] Fwd: [PATCH 1/2] ffmpeg: reset tty state correctly

[Ganesh Ajjanagadde]

On Mon, Jul 27, 2015 at 9:06 AM, Nicolas George <george at nsup.org> wrote:
> Le nonidi 9 thermidor, an CCXXIII, Ganesh Ajjanagadde a écrit :
>> Apologies for this; I accidentally replied just to the responder and
>> not the mailing list.
>
> I replied:
>
>> Apparently zsh was not doing it.
>
> ttyctl -f

Sure, but this is a command invoked once ffmpeg exits.
What I meant to say was that ffmpeg changes tty state,
and upon a sigsegv, it did not change the state back, leaving  the
terminal messed up.
This is not automatically handled by the shell, and needs manual
intervention such as above command,
or stty -sane and the like.

The point of this patch is to try to fix 2964 while still not
clobbering the terminal.
BTW, I do not know whose responsibility this is (process or shell invoking it):
a shell could theoretically save the termios state before invoking the pipeline,
and restore it at the end of the pipeline-
in the event that a process (like ffmpeg) fails to clean up after
changing terminal state,
the terminal is still fine at the end of the pipeline since the shell
can restore from the saved termios.
My original comment reflected that this is not being done by zsh at
least, don't know about bash.

>
>> Core is still being dumped due to the abort call.
>> The handler is pretty minimal, just restoring tty state (necessary due
>> to above), writing a message, and then calling abort.
>
> It still obscures the state that caused the signal in the first place, and
> thus make debugging harder. I consider this unacceptable and will still
> object the patch.

Ok. But then you realize that there is no solution that will fix 2964
(and my related trivial
piping input from /dev/null) and not clobber the terminal
as far as I can tell:
a sigsegv can occur, and since we do not handle this signal, the terminal state
will have to be restored via manual intervention.

>
> Regarding casting to void: if there is no non-intrusive and portable to
> silence that warning, then that warning is badly implemented and should be
> disabled.

Agreed completely, I do not like this ugly hack,
and wanted to clarify the hack needed to disable this warning.
BTW, it is actually more of a glibc thing,
as seen from the GCC bugzilla discussion:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
>
> Regards,
>
> --
>   Nicolas George
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>