I can't foreground or background mpv from terminal after suspending it with Ctrl-Z

[walterigle]

mpv Information

mpv 0.38.0 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
 built on Jun  6 2024 18:51:45
libplacebo version: v6.338.2
FFmpeg version: 4.4.4
FFmpeg library versions:
   libavutil       56.70.100
   libavcodec      58.134.100
   libavformat     58.76.100
   libswscale      5.9.100
   libavfilter     7.110.100
   libswresample   3.9.100

Important Information

• Platform version: OpenBSD current
• GPU model, driver and version: Intel 82Q965 Video
• Source:
• Introduced in version: 0.38.0

Reproduction Steps

• Play something from the terminal
• Press Ctrl-Z
• Execute bg
• Execute fg

The more similar issue I found reported is the one described in this report in 2020:

https://github.com/mpv-player/mpv/issues/8120

Except for in my case pressing Enter doesn't work, I have to kill the process.

It doesn't happen with mpv 0.38.0 under Debian testing, nor with mpv 0.37 under Freebsd 14.1. So far this only happens on OpenBSD.

Expected Behavior

mpv should leave the suspended state.

Actual Behavior

mpv stays in suspended state.

Log File

output.txt

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

• [X] I tested with the latest mpv version to validate that the issue is not already fixed.
• [X] I provided all required information including system and mpv version.
• [X] I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• [X] I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• [X] I attached the full, untruncated log file.
• [X] I attached the backtrace in the case of a crash.

[guidocella]

Can't reproduce on Linux.

[guidocella]

Probably caused by something in b75b56f910. But none of the developers use BSD.

[kasper93]

@N-R-K: Do you want to take a look into it?

[N-R-K]

@N-R-K: Do you want to take a look into it?

Sure, I'll look at it. But it may take me a bit.

In the meanwhile, if you (@walterigle) can use gdb to step through what's going on in osdep/terminal-unix.c::terminal_thread() when you press ctrl+z, that would help out a lot since I don't use openbsd myself.

[avih]

Guys, wouldn't be easier to use a mailing list?

To some for sure, but for many it would become much less accessible.

Anyway, it is what it is... and it's not too hard to click the "reopen" button either ;)

[N-R-K]

I think gdb was not a good suggestion. What I really wanted was some overview of what the hell is going on. Here's a quick and dirty patch that adds some logging (untested, not sure if it even compiles):

diff --git a/osdep/terminal-unix.c b/osdep/terminal-unix.c
index 6f7054887..892570b68 100644
--- a/osdep/terminal-unix.c
+++ b/osdep/terminal-unix.c
@@ -437,6 +437,8 @@ static void quit_request_sighandler(int signum)
     errno = saved_errno;
 }
 
+#define LOG(MSG) (fprintf(stderr, "%d: " MSG "\n", __LINE__), fflush(stderr))
+
 static MP_THREAD_VOID terminal_thread(void *ptr)
 {
     mp_thread_set_name("terminal/input");
@@ -461,13 +463,16 @@ static MP_THREAD_VOID terminal_thread(void *ptr)
         bool is_fg = tcgetpgrp(tty_in) == getpgrp();
         int r = polldev(fds, stdin_ok && is_fg ? 3 : 2, buf.len ? ESC_TIMEOUT : INPUT_TIMEOUT);
         if (fds[0].revents) {
+            LOG("got death pipe activity");
             do_deactivate_getch2();
             break;
         }
         if (fds[1].revents & POLLIN) {
+            LOG("got stop/cont pipe activity");
             int8_t c = -1;
             (void)read(stop_cont_pipe[0], &c, 1);
             if (c == PIPE_STOP) {
+                LOG("stopping");
                 do_deactivate_getch2();
                 if (isatty(STDERR_FILENO)) {
                     (void)write(STDERR_FILENO, TERM_ESC_RESTORE_CURSOR,
@@ -479,13 +484,16 @@ static MP_THREAD_VOID terminal_thread(void *ptr)
                 // effectively the same thing.
                 raise(SIGSTOP);
             } else if (c == PIPE_CONT) {
+                LOG("continuing");
                 getch2_poll();
             }
         }
         if (fds[2].revents) {
             int retval = read(tty_in, &buf.b[buf.len], BUF_LEN - buf.len);
-            if (!retval || (retval == -1 && errno != EINTR && errno != EAGAIN && errno != EIO))
+            if (!retval || (retval == -1 && errno != EINTR && errno != EAGAIN && errno != EIO)) {
+                LOG("breaking out");
                 break; // EOF/closed
+            }
             if (retval > 0) {
                 buf.len += retval;
                 process_input(input_ctx, false);

Not sure if it will reveal anything interesting or not, but worth a shot.

[brad0]

@N-R-K I can give you access to a VM if you want to test anything out.

[N-R-K]

Took some cursory glance at the code and I'm not seeing anything obviously wrong.

I can give you access to a VM if you want to test anything out.

Thanks for the offer. I already have qemu installed locally. I'll look into installing an openbsd image and setting up a dev environment on it sometime this week.