Package: emacs;
Reported by: Markus Triska <triska <at> metalevel.at>
Date: Mon, 5 Jan 2026 01:17:02 UTC
Severity: normal
Found in version 30.2
To reply to this bug, email your comments to 80131 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#80131; Package emacs.
(Mon, 05 Jan 2026 01:17:02 GMT) Full text and rfc822 format available.Markus Triska <triska <at> metalevel.at>:bug-gnu-emacs <at> gnu.org.
(Mon, 05 Jan 2026 01:17:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Markus Triska <triska <at> metalevel.at> To: bug-gnu-emacs <at> gnu.org Subject: 30.2; Emacs sometimes no longer reacts to keyboard events Date: Mon, 05 Jan 2026 02:18:45 +0100 (CET)
In rare situations, Emacs no longer reacts to any keyboard events.
When this occurs, I can still select text with the mouse, and also
move point by clicking around in the window, and Emacs also displays
text such as "Mark set" when I double-click on a word. However, it no
longer reacts to any keyboard events, neither characters nor any other
key seem to have the slightest effect.
If it were not for the working mouse interaction, the impression would
be that Emacs hangs completely. CPU usage remains very low.
One point that may be important to reproduce this issue: I was using a
wireless keyboard, connected via Bluetooth, every time the issue
arose. Due to the nature of the wireless connection, the keyboard may
intermittently disappear from the connected devices, and return
shortly after that. Could this play a role?
Please find below the output of "bt" and "bt full" in one recent
instance where this happened a few minutes ago.
My keyboard is currently (wirelessly) connected and working: I am
writing this report in a fresh Emacs instance, while the other one
still does not react in any way to keyboard input, also after
continuing its execution with "c" after producing the backtrace.
I will try to find a way to produce this situation reliably. Until I
find such a case, does the existing backtrace already help?
Thank you and all the best!
Markus
Program received signal SIGTSTP, Stopped (user).
0x00007ffff73a9687 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0 0x00007ffff73a9687 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff73a96ad in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff742780c in pselect () from /lib/x86_64-linux-gnu/libc.so.6
#3 0x00005555557bb4de in really_call_select (arg=0x7fffffffcdf0) at thread.c:624
#4 0x00005555557bbc10 in flush_stack_call_func (func=0x5555557bb480 <really_call_select>, arg=0x7fffffffcdf0)
at /home/username/emacs-30.2/src/lisp.h:4509
#5 thread_select (func=<optimized out>, max_fds=<optimized out>, rfds=rfds <at> entry=0x7fffffffd0c0, wfds=<optimized out>,
efds=<optimized out>, timeout=<optimized out>, sigmask=0x0) at thread.c:656
#6 0x0000555555797920 in wait_reading_process_output (time_limit=time_limit <at> entry=0, nsecs=nsecs <at> entry=0,
read_kbd=read_kbd <at> entry=-1, do_display=true, wait_for_cell=wait_for_cell <at> entry=0x0, wait_proc=wait_proc <at> entry=0x0,
just_wait_proc=0) at process.c:5757
#7 0x00005555556bec0a in kbd_buffer_get_event (kbp=<synthetic pointer>, used_mouse_menu=<optimized out>, end_time=<optimized out>)
at keyboard.c:4094
#8 read_event_from_main_queue (end_time=<optimized out>, local_getcjmp=<optimized out>, used_mouse_menu=<optimized out>)
at keyboard.c:2330
#9 read_decoded_event_from_main_queue (end_time=<optimized out>, local_getcjmp=<optimized out>, prev_event=<optimized out>,
used_mouse_menu=<optimized out>) at keyboard.c:2394
#10 read_char (commandflag=1, map=map <at> entry=0x55555cc008d3, prev_event=0x0, used_mouse_menu=used_mouse_menu <at> entry=0x7fffffffd94b,
end_time=end_time <at> entry=0x0) at keyboard.c:3015
#11 0x00005555556c1a8d in read_key_sequence (keybuf=keybuf <at> entry=0x7fffffffda80, prompt=prompt <at> entry=0x0,
dont_downcase_last=dont_downcase_last <at> entry=false, can_return_switch_frame=can_return_switch_frame <at> entry=true,
fix_current_buffer=fix_current_buffer <at> entry=true, prevent_redisplay=prevent_redisplay <at> entry=false,
disable_text_conversion_p=false) at keyboard.c:10743
#12 0x00005555556c36c4 in command_loop_1 () at keyboard.c:1429
#13 0x000055555573d497 in internal_condition_case (bfun=bfun <at> entry=0x5555556c3510 <command_loop_1>, handlers=handlers <at> entry=0x90,
hfun=hfun <at> entry=0x5555556b6b90 <cmd_error>) at eval.c:1613
#14 0x00005555556aee7e in command_loop_2 (handlers=handlers <at> entry=0x90) at keyboard.c:1168
#15 0x000055555573d3f1 in internal_catch (tag=tag <at> entry=0x11cd0, func=func <at> entry=0x5555556aee50 <command_loop_2>,
arg=arg <at> entry=0x90) at eval.c:1292
#16 0x00005555556aee13 in command_loop () at keyboard.c:1146
#17 0x00005555556b6731 in recursive_edit_1 () at keyboard.c:754
#18 0x00005555556b6ac0 in Frecursive_edit () at keyboard.c:837
#19 0x000055555559dd25 in main (argc=2, argv=<optimized out>) at emacs.c:2646
(gdb) bt full
#0 0x00007ffff73a9687 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1 0x00007ffff73a96ad in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2 0x00007ffff742780c in pselect () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#3 0x00005555557bb4de in really_call_select (arg=0x7fffffffcdf0) at thread.c:624
sa = 0x7fffffffcdf0
self = 0x555555de7480 <main_thread>
oldset = {__val = {0, 93825097736515, 0, 1, 341, 140737341513369, 341, 93824994961470, 1767574835, 215808822, 0,
93824993694046, 4294967293, 18446744073709551615, 1767574835, 215808822}}
#4 0x00005555557bbc10 in flush_stack_call_func (func=0x5555557bb480 <really_call_select>, arg=0x7fffffffcdf0)
at /home/username/emacs-30.2/src/lisp.h:4509
No locals.
#5 thread_select (func=<optimized out>, max_fds=<optimized out>, rfds=rfds <at> entry=0x7fffffffd0c0, wfds=<optimized out>,
efds=<optimized out>, timeout=<optimized out>, sigmask=0x0) at thread.c:656
sa = {func = 0x7ffff74277c0 <pselect>, max_fds = 12, rfds = 0x7fffffffd0c0, wfds = 0x7fffffffd140, efds = 0x0,
timeout = 0x7fffffffcf90, sigmask = 0x0, result = 1}
#6 0x0000555555797920 in wait_reading_process_output (time_limit=time_limit <at> entry=0, nsecs=nsecs <at> entry=0,
read_kbd=read_kbd <at> entry=-1, do_display=true, wait_for_cell=wait_for_cell <at> entry=0x0, wait_proc=wait_proc <at> entry=0x0,
just_wait_proc=0) at process.c:5757
tls_nfds = 0
tls_available = {fds_bits = {0 <repeats 16 times>}}
process_skipped = <optimized out>
wrapped = <optimized out>
channel_start = <optimized out>
child_fd = <optimized out>
last_read_channel = -1
channel = 1024
nfds = <optimized out>
Available = {fds_bits = {2104, 0 <repeats 15 times>}}
Writeok = {fds_bits = {0 <repeats 16 times>}}
check_write = true
check_delay = <optimized out>
no_avail = <optimized out>
xerrno = 11
proc = <optimized out>
timeout = {tv_sec = 100000, tv_nsec = 0}
end_time = {tv_sec = 93824994237600, tv_nsec = 93825004558752}
timer_delay = <optimized out>
got_output_end_time = {tv_sec = 0, tv_nsec = -1}
MINIMUM = MINIMUM
TIMEOUT = TIMEOUT
FOREVER = FOREVER
wait = <optimized out>
got_some_output = -1
--Type <RET> for more, q to quit, c to continue without paging--
prev_wait_proc_nbytes_read = 0
retry_for_async = <optimized out>
count = <optimized out>
now = <optimized out>
#7 0x00005555556bec0a in kbd_buffer_get_event (kbp=<synthetic pointer>, used_mouse_menu=<optimized out>, end_time=<optimized out>)
at keyboard.c:4094
do_display = <optimized out>
obj = <optimized out>
str = <optimized out>
had_pending_selection_requests = false
had_pending_conversion_events = false
obj = <optimized out>
str = <optimized out>
had_pending_selection_requests = <optimized out>
had_pending_conversion_events = <optimized out>
now = <optimized out>
duration = <optimized out>
do_display = <optimized out>
tty = <optimized out>
first = <optimized out>
event = <optimized out>
copy = <optimized out>
f = <optimized out>
frame = <optimized out>
focus = <optimized out>
pinch_dx = <optimized out>
pinch_dy = <optimized out>
pinch_angle = <optimized out>
maybe_event = <optimized out>
f = <optimized out>
movement_frame = <optimized out>
bar_window = <optimized out>
part = <optimized out>
x = <optimized out>
y = <optimized out>
t = <optimized out>
frame = <optimized out>
#8 read_event_from_main_queue (end_time=<optimized out>, local_getcjmp=<optimized out>, used_mouse_menu=<optimized out>)
at keyboard.c:2330
c = 0x0
count = <optimized out>
save_jump = {{__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = {__val = {0 <repeats 16 times>}}}}
kb = 0x555555eceef0
c = <optimized out>
save_jump = <optimized out>
kb = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
start = <optimized out>
count = <optimized out>
last = <optimized out>
#9 read_decoded_event_from_main_queue (end_time=<optimized out>, local_getcjmp=<optimized out>, prev_event=<optimized out>,
used_mouse_menu=<optimized out>) at keyboard.c:2394
nextevt = <optimized out>
frame = <optimized out>
terminal = <optimized out>
events = {0x0, 0x1, 0x1, 0x7fffffffd5d8, 0x5555557423a0 <funcall_nil>, 0x7fffffffd568, 0x0,
0x55555573df3d <Frun_hooks+77>, 0x2, 0x4650, 0x1, 0x180, 0x7fffffffd5d8, 0x0, 0x55555655b9b0, 0x8dc0}
n = <optimized out>
events = <optimized out>
n = <optimized out>
nextevt = <optimized out>
frame = <optimized out>
terminal = <optimized out>
meta_key = <optimized out>
coding = <optimized out>
i = <optimized out>
c = <optimized out>
modifier = <optimized out>
src = <optimized out>
dest = <optimized out>
i = <optimized out>
p = <optimized out>
c = <optimized out>
modifier = <optimized out>
#10 read_char (commandflag=1, map=map <at> entry=0x55555cc008d3, prev_event=0x0, used_mouse_menu=used_mouse_menu <at> entry=0x7fffffffd94b,
end_time=end_time <at> entry=0x0) at keyboard.c:3015
c = 0x0
local_getcjmp = {{__jmpbuf = {93825001784640, 6711161210319875479, 1, 1, 4611686019484352512, 93825116670099,
610104453443169687, 6711159407562665367}, __mask_was_saved = 0, __saved_mask = {__val = {46560, 46560, 110038,
27509, 3, 0, 93824994683503, 0, 4295013856, 46560, 93825009039797, 46560, 110038, 27509, 93825009039792, 0}}}}
save_jump = {{__jmpbuf = {46560, 93825009039792, 140737488344752, 0, 0, 140737488344800, 93825009039792, 0},
__mask_was_saved = 0, __saved_mask = {__val = {27508, 27510, 128, 128, 0, 0, 93824995160520, 93825009039797,
93824994240500, 27509, 3, 11, 93825009006384, 93825008443360, 93824994159938, 7192144}}}}
tem = <optimized out>
save = <optimized out>
previous_echo_area_message = 0x0
also_record = 0x0
reread = false
recorded = false
polling_stopped_here = true
orig_kboard = 0x555555eceef0
retry = <optimized out>
jmpcount = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
#11 0x00005555556c1a8d in read_key_sequence (keybuf=keybuf <at> entry=0x7fffffffda80, prompt=prompt <at> entry=0x0,
dont_downcase_last=dont_downcase_last <at> entry=false, can_return_switch_frame=can_return_switch_frame <at> entry=true,
fix_current_buffer=fix_current_buffer <at> entry=true, prevent_redisplay=prevent_redisplay <at> entry=false,
disable_text_conversion_p=false) at keyboard.c:10743
interrupted_kboard = 0x555555eceef0
interrupted_frame = <optimized out>
key = <optimized out>
used_mouse_menu = false
echo_local_start = 0
last_real_key_start = <optimized out>
keys_local_start = 0
new_binding = <optimized out>
count = <optimized out>
t = <optimized out>
echo_start = 0
keys_start = 0
current_binding = 0x55555cc008d3
first_unbound = 31
mock_input = <optimized out>
used_mouse_menu_history = {false <repeats 30 times>}
fkey = {parent = 0x7ffff60e5273, map = <optimized out>, start = 0, end = 0}
keytran = {parent = 0x7ffff69decab, map = <optimized out>, start = 0, end = 0}
indec = {parent = 0x7ffff60e5263, map = <optimized out>, start = 0, end = 0}
shift_translated = <optimized out>
delayed_switch_frame = <optimized out>
original_uppercase = <optimized out>
original_uppercase_position = <optimized out>
disabled_conversion = <optimized out>
starting_buffer = <optimized out>
fake_prefixed_keys = 0x0
first_event = 0x0
second_event = <optimized out>
#12 0x00005555556c36c4 in command_loop_1 () at keyboard.c:1429
cmd = <optimized out>
keybuf = {0x55555cc02a33, 0x1a, 0x4141414141414141, 0x60, 0x60, 0x0, 0x0, 0x55555581f1c8, 0x55555dc3bf35,
0x55555573e7f4 <unbind_to+244>, 0x0, 0x555562630373, 0xb, 0x10bc0, 0x30, 0x55555dc3bf35, 0x2aaaa0979208, 0x555562630373,
0x60, 0x7fffffffdb50, 0x7fffffffdcd4, 0x2, 0x7ffff61d88b3, 0x5555556b6ce9 <cmd_error+345>, 0x0, 0x0, 0x0, 0x0, 0xb,
0xad10}
i = <optimized out>
last_pt = <optimized out>
prev_modiff = 199809
prev_buffer = 0x55555655b9b0
#13 0x000055555573d497 in internal_condition_case (bfun=bfun <at> entry=0x5555556c3510 <command_loop_1>, handlers=handlers <at> entry=0x90,
hfun=hfun <at> entry=0x5555556b6b90 <cmd_error>) at eval.c:1613
val = <optimized out>
c = 0x555555f16fc0
--Type <RET> for more, q to quit, c to continue without paging--
#14 0x00005555556aee7e in command_loop_2 (handlers=handlers <at> entry=0x90) at keyboard.c:1168
val = <optimized out>
#15 0x000055555573d3f1 in internal_catch (tag=tag <at> entry=0x11cd0, func=func <at> entry=0x5555556aee50 <command_loop_2>,
arg=arg <at> entry=0x90) at eval.c:1292
val = <optimized out>
c = 0x555555f16e80
#16 0x00005555556aee13 in command_loop () at keyboard.c:1146
No locals.
#17 0x00005555556b6731 in recursive_edit_1 () at keyboard.c:754
count = <optimized out>
val = <optimized out>
#18 0x00005555556b6ac0 in Frecursive_edit () at keyboard.c:837
count = <optimized out>
buffer = <optimized out>
#19 0x000055555559dd25 in main (argc=2, argv=<optimized out>) at emacs.c:2646
stack_bottom_variable = 0x0
old_argc = <optimized out>
dump_file = 0x0
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = <optimized out>
dump_mode = <optimized out>
skip_args = 0
temacs = 0x0
attempt_load_pdump = <optimized out>
only_version = false
rlim = {rlim_cur = 10022912, rlim_max = 18446744073709551615}
lc_all = <optimized out>
sockfd = -1
module_assertions = <optimized out>
In GNU Emacs 30.2 (build 2, x86_64-pc-linux-gnu, X toolkit, Xaw scroll
bars) of 2025-09-03 built on beelink-ser8
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: Debian GNU/Linux 13 (trixie)
Configured using:
'configure --with-x-toolkit=lucid --with-tiff=ifavailable'
Configured features:
FREETYPE GIF GMP GNUTLS JPEG LIBXML2 MODULES NOTIFY INOTIFY PDUMPER
PNG SECCOMP SOUND THREADS TOOLKIT_SCROLL_BARS X11 XDBE XFT XIM XPM
LUCID ZLIB
Important settings:
value of $LC_MONETARY: de_AT.UTF-8
value of $LC_NUMERIC: de_AT.UTF-8
value of $LC_TIME: de_AT.UTF-8
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
bug-gnu-emacs <at> gnu.org:bug#80131; Package emacs.
(Mon, 05 Jan 2026 12:43:02 GMT) Full text and rfc822 format available.Message #8 received at 80131 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Markus Triska <triska <at> metalevel.at>, Po Lu <luangruo <at> yahoo.com> Cc: 80131 <at> debbugs.gnu.org Subject: Re: bug#80131: 30.2; Emacs sometimes no longer reacts to keyboard events Date: Mon, 05 Jan 2026 14:42:24 +0200
> From: Markus Triska <triska <at> metalevel.at> > Date: Mon, 05 Jan 2026 02:18:45 +0100 (CET) > > In rare situations, Emacs no longer reacts to any keyboard events. > > When this occurs, I can still select text with the mouse, and also > move point by clicking around in the window, and Emacs also displays > text such as "Mark set" when I double-click on a word. However, it no > longer reacts to any keyboard events, neither characters nor any other > key seem to have the slightest effect. > > If it were not for the working mouse interaction, the impression would > be that Emacs hangs completely. CPU usage remains very low. So Emacs accepts input, just not from the keyboard. > One point that may be important to reproduce this issue: I was using a > wireless keyboard, connected via Bluetooth, every time the issue > arose. Due to the nature of the wireless connection, the keyboard may > intermittently disappear from the connected devices, and return > shortly after that. Could this play a role? It could. Maybe Emacs thinks there's no keyboard to read from or something? I don't know how this disconnection expresses itself to Emacs on GNU/Linux systems. Does anyone know? > Please find below the output of "bt" and "bt full" in one recent > instance where this happened a few minutes ago. Thanks, but the backtrace basically says that Emacs is idle and waiting for input (from 12 different file descriptors, no less!). Which is consistent with what you describe, but doesn't tell me anything about the possible cause(s) of this. Does anyone else see anything useful or unusual in this backtrace?
bug-gnu-emacs <at> gnu.org:bug#80131; Package emacs.
(Tue, 06 Jan 2026 02:13:02 GMT) Full text and rfc822 format available.Message #11 received at 80131 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: Markus Triska <triska <at> metalevel.at>, 80131 <at> debbugs.gnu.org Subject: Re: bug#80131: 30.2; Emacs sometimes no longer reacts to keyboard events Date: Tue, 06 Jan 2026 10:12:00 +0800
Eli Zaretskii <eliz <at> gnu.org> writes: >> From: Markus Triska <triska <at> metalevel.at> >> Date: Mon, 05 Jan 2026 02:18:45 +0100 (CET) >> >> In rare situations, Emacs no longer reacts to any keyboard events. >> >> When this occurs, I can still select text with the mouse, and also >> move point by clicking around in the window, and Emacs also displays >> text such as "Mark set" when I double-click on a word. However, it no >> longer reacts to any keyboard events, neither characters nor any other >> key seem to have the slightest effect. >> >> If it were not for the working mouse interaction, the impression would >> be that Emacs hangs completely. CPU usage remains very low. > > So Emacs accepts input, just not from the keyboard. What's the value of interrupt_input_blocked during periods of such unresponsiveness, just to be certain? >> One point that may be important to reproduce this issue: I was using a >> wireless keyboard, connected via Bluetooth, every time the issue >> arose. Due to the nature of the wireless connection, the keyboard may >> intermittently disappear from the connected devices, and return >> shortly after that. Could this play a role? > > It could. Maybe Emacs thinks there's no keyboard to read from or > something? I don't know how this disconnection expresses itself to > Emacs on GNU/Linux systems. Does anyone know? It is possible. Please set a breakpoint at: This illustration may reflect the treatment taken towards core key events to some degree. */ device = xi_device_from_id (dpyinfo, xev->deviceid); ---> source = xi_device_from_id (dpyinfo, xev->sourceid); and, in an Emacs session which is not responding to key events, ascertain whether `device' is NULL after a key event is registered. In the event that it is, post the output of: (gdb) p *xev and the shell command: $ xinput list Thanks. (Be aware that it is xev->deviceid which is material, not xev->sourceid.)
bug-gnu-emacs <at> gnu.org:bug#80131; Package emacs.
(Tue, 06 Jan 2026 08:11:01 GMT) Full text and rfc822 format available.Message #14 received at 80131 <at> debbugs.gnu.org (full text, mbox):
From: Markus Triska <triska <at> metalevel.at> To: Po Lu <luangruo <at> yahoo.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 80131 <at> debbugs.gnu.org Subject: Re: bug#80131: 30.2; Emacs sometimes no longer reacts to keyboard events Date: Tue, 06 Jan 2026 09:10:38 +0100
Thank you a lot for looking into this! The hang happens very rarely, and
I want to make sure that everything is correctly prepared when it
happens again. Could you therefore please help me with the breakpoint:
When I do:
(gdb) break xterm.c:24085
Then GDB responds with:
Breakpoint 3 at 0x13aa69: file xterm.c, line 25235.
The line in the response is not the one I stated and intended, and when
I start Emacs, it breaks on that other line instead of at line 24085
which contains the snippet you posted.
I will perform the other steps the next time the hang happens.
All the best,
Markus
bug-gnu-emacs <at> gnu.org:bug#80131; Package emacs.
(Tue, 06 Jan 2026 13:27:01 GMT) Full text and rfc822 format available.Message #17 received at 80131 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Markus Triska <triska <at> metalevel.at> Cc: luangruo <at> yahoo.com, 80131 <at> debbugs.gnu.org Subject: Re: bug#80131: 30.2; Emacs sometimes no longer reacts to keyboard events Date: Tue, 06 Jan 2026 15:25:04 +0200
> From: Markus Triska <triska <at> metalevel.at> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 80131 <at> debbugs.gnu.org > Date: Tue, 06 Jan 2026 09:10:38 +0100 > > Thank you a lot for looking into this! The hang happens very rarely, and > I want to make sure that everything is correctly prepared when it > happens again. Could you therefore please help me with the breakpoint: > > When I do: > > (gdb) break xterm.c:24085 > > Then GDB responds with: > > Breakpoint 3 at 0x13aa69: file xterm.c, line 25235. This means that code is not being compiled in your build. Po Lu, what is the alternative place to put a breakpoint in Markus's build?
bug-gnu-emacs <at> gnu.org:bug#80131; Package emacs.
(Wed, 07 Jan 2026 02:54:01 GMT) Full text and rfc822 format available.Message #20 received at 80131 <at> debbugs.gnu.org (full text, mbox):
From: Po Lu <luangruo <at> yahoo.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: Markus Triska <triska <at> metalevel.at>, 80131 <at> debbugs.gnu.org Subject: Re: bug#80131: 30.2; Emacs sometimes no longer reacts to keyboard events Date: Wed, 07 Jan 2026 10:53:24 +0800
Eli Zaretskii <eliz <at> gnu.org> writes:
> Po Lu, what is the alternative place to put a breakpoint in Markus's
> build?
I'm not certain--if the OP's build isn't configured with XInput2, a
different component is probably at fault. If you place a breakpoint
here:
if (f != 0)
{
KeySym keysym, orig_keysym;
/* al%imercury <at> uunet.uu.net says that making this 81
instead of 80 fixed a bug whereby meta chars made
his Emacs hang.
It seems that some version of XmbLookupString has
a bug of not returning XBufferOverflow in
status_return even if the input is too long to
fit in 81 bytes. So, we must prepare sufficient
bytes for copy_buffer. 513 bytes (256 chars for
two-byte character set) seems to be a fairly good
approximation. -- 2000.8.10 handa <at> gnu.org */
unsigned char copy_buffer[513];
unsigned char *copy_bufptr = copy_buffer;
int copy_bufsiz = sizeof (copy_buffer);
int modifiers;
Lisp_Object c;
/* `xkey' will be modified, but it's not important to modify
`event' itself. */
XKeyEvent xkey = event->xkey;
--> if (event->xkey.window == FRAME_X_WINDOW (f))
Is it triggered? I refer to the block which is contingent on `f != 0'
itself, not the conditional statement which tests `event->xkey.window',
of course.
bug-gnu-emacs <at> gnu.org:bug#80131; Package emacs.
(Wed, 07 Jan 2026 06:50:02 GMT) Full text and rfc822 format available.Message #23 received at 80131 <at> debbugs.gnu.org (full text, mbox):
From: Markus Triska <triska <at> metalevel.at> To: Po Lu <luangruo <at> yahoo.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 80131 <at> debbugs.gnu.org Subject: Re: bug#80131: 30.2; Emacs sometimes no longer reacts to keyboard events Date: Wed, 07 Jan 2026 07:49:14 +0100
Po Lu <luangruo <at> yahoo.com> writes: > Is it triggered? I refer to the block which is contingent on `f != 0' > itself, not the conditional statement which tests `event->xkey.window', > of course. To ensure that I set the breakpoint at the right place, could you please post the GDB command I should issue for this exact location? I am using Emacs 30.2 from the distribution tarball. Currently, #80120 overshadows the present issue in the sense that when I try to reproduce the hang, I tend to run into #80120 instead, so I will continue trying to reproduce the hang after #80120 is addressed. Thank you a lot! Markus
bug-gnu-emacs <at> gnu.org:bug#80131; Package emacs.
(Wed, 07 Jan 2026 12:54:02 GMT) Full text and rfc822 format available.Message #26 received at 80131 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Markus Triska <triska <at> metalevel.at> Cc: luangruo <at> yahoo.com, 80131 <at> debbugs.gnu.org Subject: Re: bug#80131: 30.2; Emacs sometimes no longer reacts to keyboard events Date: Wed, 07 Jan 2026 14:53:08 +0200
> From: Markus Triska <triska <at> metalevel.at> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 80131 <at> debbugs.gnu.org > Date: Wed, 07 Jan 2026 07:49:14 +0100 > > Po Lu <luangruo <at> yahoo.com> writes: > > > Is it triggered? I refer to the block which is contingent on `f != 0' > > itself, not the conditional statement which tests `event->xkey.window', > > of course. > > To ensure that I set the breakpoint at the right place, could you please > post the GDB command I should issue for this exact location? > > I am using Emacs 30.2 from the distribution tarball. The GDB command should be (gdb) break xterm.c:20294 for the source files from Emacs 30.2.
bug-gnu-emacs <at> gnu.org:bug#80131; Package emacs.
(Thu, 08 Jan 2026 22:25:02 GMT) Full text and rfc822 format available.Message #29 received at 80131 <at> debbugs.gnu.org (full text, mbox):
From: Markus Triska <triska <at> metalevel.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: luangruo <at> yahoo.com, 80131 <at> debbugs.gnu.org Subject: Re: bug#80131: 30.2; Emacs sometimes no longer reacts to keyboard events Date: Thu, 08 Jan 2026 23:23:58 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:
> (gdb) break xterm.c:20294
>
> for the source files from Emacs 30.2.
Thank you, this is triggered already on the first key I press:
For example, the frame appears, I switch to it and press C-x to do
something, and get the backtrace below.
When I continue and try to do something, it runs again into this.
(gdb) break xterm.c:20294
Breakpoint 3 at 0x13e395: file xterm.c, line 20294.
(gdb) r
Starting program: /home/username/emacs-30.2/src/emacs
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after vfork from child process 55238]
[Detaching after vfork from child process 55239]
Breakpoint 3, handle_one_xevent (dpyinfo=dpyinfo <at> entry=0x5555561a0700,
event=event <at> entry=0x7fffffffcb80, finish=finish <at> entry=0x7fffffffcb7c,
hold_quit=hold_quit <at> entry=0x7fffffffcc70) at xterm.c:20294
20294 if (event->xkey.window == FRAME_X_WINDOW (f))
bug-gnu-emacs <at> gnu.org:bug#80131; Package emacs.
(Mon, 12 Jan 2026 02:35:01 GMT) Full text and rfc822 format available.Message #32 received at 80131 <at> debbugs.gnu.org (full text, mbox):
From: Mike Kupfer <kupfer <at> rawbw.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: Po Lu <luangruo <at> yahoo.com>, Markus Triska <triska <at> metalevel.at>, 80131 <at> debbugs.gnu.org Subject: Re: bug#80131: 30.2; Emacs sometimes no longer reacts to keyboard events Date: Sun, 11 Jan 2026 18:34:40 -0800
[Message part 1 (text/plain, inline)]
Eli Zaretskii wrote: > > From: Markus Triska <triska <at> metalevel.at> > > Date: Mon, 05 Jan 2026 02:18:45 +0100 (CET) [...] > > One point that may be important to reproduce this issue: I was using a > > wireless keyboard, connected via Bluetooth, every time the issue > > arose. Due to the nature of the wireless connection, the keyboard may > > intermittently disappear from the connected devices, and return > > shortly after that. Could this play a role? FWIW, I was seeing similar hangs for awhile (see #74535), using a USB (non-wireless) keyboard. > It could. Maybe Emacs thinks there's no keyboard to read from or > something? I don't know how this disconnection expresses itself to > Emacs on GNU/Linux systems. Does anyone know? > > > Please find below the output of "bt" and "bt full" in one recent > > instance where this happened a few minutes ago. > > Thanks, but the backtrace basically says that Emacs is idle and > waiting for input (from 12 different file descriptors, no less!). > Which is consistent with what you describe, but doesn't tell me > anything about the possible cause(s) of this. > > Does anyone else see anything useful or unusual in this backtrace? FWIW, the backtrace is similar to, but not exactly the same as, the one in #74535. I've only seen the hang once in the not-quite-year since #74535 was closed. I was able to get the output from view-lossage. The last keyboard events were from typing "C-x 5 0". For reasons I no longer recall, I took a photo of the view-lossage output, rather than getting a simple screenshot. But I've attached a screenshot of a portion of the photo. Pretty much everything after that excerpt was related to mwheel-scroll. If I see the problem again, I'll try the troubleshooting steps that Po Lu suggested (thanks for those!). regards, mike
[Screenshot at 2026-01-11 18-24-21.png (image/png, attachment)]
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.