bug#48629: 28.0.50; GUI emacsclient frames stop accepting keyboard input around recv

["Basil L. Contovounesios" <contovob@tcd.ie>]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>> On Mai 24 2021, Basil L. Contovounesios wrote:
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>> or you are asking why it becomes stuck in recv for prolonged times?
>>> Not just prolonged, but indefinite.
>> But emacsclient is just waiting for the answer from Emacs, so it is
>> behaving as expected.
>
> Right, I just attached GDB to a non-frozen emacsclient process, and it's
> exactly the same story as in the OP.  Sorry for the misleading report.
>>> I have yet to find a way to restore these graphical sessions to
>>> normal operation,
>> That must be something else, not related to emacsclient.
>
> ...whatever elusive cause is making my GUI emacsclient frames stop
> accepting keyboard input.  Perhaps then the issue lies in the Emacs
> keyboard input code, and I'd be able to reproduce the hang even in
> non-daemon Emacs sessions?
>
> Any ideas on how to debug that next time it happens?

It happened again, and this time I attached GDB to the 'emacs --daemon'
process:

Attaching to process 39876
[New LWP 39877]
[New LWP 39878]
[New LWP 39879]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f8bc8e3e9c6 in __pselect (nfds=26, readfds=0x7fff028412f0, writefds=0x7fff02841370, exceptfds=0x0, 
    timeout=<optimized out>, sigmask=0x7fff02841140) at ../sysdeps/unix/sysv/linux/pselect.c:48
48	../sysdeps/unix/sysv/linux/pselect.c: No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = :0
TERM = xterm-256color
Breakpoint 1 at 0x5585832d279e
.gdbinit:1239: Error in sourced command file:
No symbol "defined_HAVE_X_WINDOWS" in current context.
(gdb) bt full
#0  0x00007f8bc8e3e9c6 in __pselect
    (nfds=26, readfds=0x7fff028412f0, writefds=0x7fff02841370,
     exceptfds=0x0, timeout=<optimized out>, sigmask=0x7fff02841140)
    at ../sysdeps/unix/sysv/linux/pselect.c:48
        resultvar = 18446744073709551102
        sc_cancel_oldtype = 0
        tval = {
          tv_sec = 2,
          tv_nsec = 908570849
        }
        data = {
          ss = 0,
          ss_len = 8
        }
#1  0x00005585834a85b6 in really_call_select ()
#2  0x00005585834a9320 in thread_select ()
#3  0x00005585834c5f58 in xg_select ()
#4  0x000055858348689d in wait_reading_process_output ()
#5  0x00005585832e5660 in sit_for ()
#6  0x00005585833cd024 in read_char ()
#7  0x00005585833cd822 in read_key_sequence ()
#8  0x00005585833cf22c in command_loop_1 ()
#9  0x000055858343d3d7 in internal_condition_case ()
#10 0x00005585833c03e4 in command_loop_2 ()
#11 0x000055858343f9d3 in internal_catch ()
#12 0x00005585833c0383 in command_loop ()
#13 0x00005585833c5976 in recursive_edit_1 ()
#14 0x00005585833c5ca1 in Frecursive_edit ()
#15 0x00005585832db09e in main ()
'backtrace_top' has unknown return type; cast the call to its declared return type

I then entered 'n' a few times followed unfortunately by C-c, which
killed the process (I would have tried 'thread apply all bt full' next).

So it looks like it's actually pselect that's blocking?

-- 
Basil