* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
@ 2020-05-13 17:42 martin rudalics
2020-05-13 18:04 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: martin rudalics @ 2020-05-13 17:42 UTC (permalink / raw)
To: 41239
This looks like yet another GTK specific crash where we apparently can't
do much. But maybe someone can spot a pattern we could employ to avoid
the XTread_socket calls when deleting a frame. Otherwise, we probably
should mention this in PROBLEMS.
Recipe with emacs -Q (here on Debian 10 with various master and release
builds):
C-x 5 2
Move the mouse to some sensitive part of the mode line in either of the
frames such that a GTK tooltip pops up. Make sure the tooltip doesn't
disappear.
Type Alt-F4.
This gets me backtraces like the ones listed below. In addition, I am told
(emacs:3116): GLib-CRITICAL **: 19:00:56.620: Source ID 1394 was not found when attempting to remove it
martin
Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x00007ffff56aeb71 in _int_malloc (av=av@entry=0x7ffff57e3c40 <main_arena>, bytes=bytes@entry=16) at malloc.c:3620
3620 malloc.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0 0x00007ffff56aeb71 in _int_malloc (av=av@entry=0x7ffff57e3c40 <main_arena>, bytes=bytes@entry=16) at malloc.c:3620
#1 0x00007ffff56b0877 in __GI___libc_malloc (bytes=16) at malloc.c:3073
#2 0x00007ffff66533ff in () at /lib/x86_64-linux-gnu/libxcb.so.1
#3 0x00007ffff6653958 in () at /lib/x86_64-linux-gnu/libxcb.so.1
#4 0x00007ffff66b65ee in () at /lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007ffff66b6760 in () at /lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007ffff66b6a5d in _XEventsQueued () at /lib/x86_64-linux-gnu/libX11.so.6
#7 0x00007ffff66a87b7 in XPending () at /lib/x86_64-linux-gnu/libX11.so.6
#8 0x00007ffff6f5220d in () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#9 0x00007ffff6a2b669 in g_main_context_prepare () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007ffff6a2c06b in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007ffff6a2c207 in g_main_context_pending () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007ffff7220b9d in gtk_events_pending () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#13 0x000000000071dda2 in XTread_socket (terminal=0xf0b6d0, hold_quit=0x7fffffffc4c0) at ../../src/xterm.c:9402
#14 0x0000000000778e85 in gobble_input () at ../../src/keyboard.c:6885
#15 0x0000000000779365 in handle_async_input () at ../../src/keyboard.c:7122
#16 0x0000000000779384 in process_pending_signals () at ../../src/keyboard.c:7136
#17 0x0000000000841b43 in maybe_quit () at ../../src/eval.c:1545
#18 0x0000000000789da3 in access_keymap_1 (map=XIL(0x7ffff3d6de63), idx=XIL(0x9390), t_ok=true, noinherit=false, autoload=true) at ../../src/keymap.c:522
#19 0x0000000000789ea6 in access_keymap (map=XIL(0x7ffff3d6de63), idx=XIL(0x9390), t_ok=true, noinherit=false, autoload=true) at ../../src/keymap.c:533
#20 0x0000000000779c8d in menu_bar_items (old=XIL(0x1a5d555)) at ../../src/keyboard.c:7477
#21 0x00000000004a6307 in update_menu_bar (f=0x1300c40, save_match_data=false, hooks_run=true) at ../../src/xdisp.c:12681
#22 0x00000000004a5e77 in prepare_menu_bars () at ../../src/xdisp.c:12578
#23 0x00000000004aaf20 in redisplay_internal () at ../../src/xdisp.c:15392
#24 0x00000000004acdf6 in redisplay_preserve_echo_area (from_where=5) at ../../src/xdisp.c:16102
#25 0x000000000076905a in read_char (commandflag=1, map=XIL(0x128a083), prev_event=XIL(0), used_mouse_menu=0x7fffffffe13f, end_time=0x0) at ../../src/keyboard.c:2491
#26 0x000000000078028e in read_key_sequence (keybuf=0x7fffffffe2d0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9547
#27 0x0000000000765645 in command_loop_1 () at ../../src/keyboard.c:1350
#28 0x00000000008414e8 in internal_condition_case (bfun=0x7651c9 <command_loop_1>, handlers=XIL(0x90), hfun=0x7647d8 <cmd_error>) at ../../src/eval.c:1355
#29 0x0000000000764dae in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1091
#30 0x000000000084099c in internal_catch (tag=XIL(0xd200), func=0x764d81 <command_loop_2>, arg=XIL(0)) at ../../src/eval.c:1116
#31 0x0000000000764d4c in command_loop () at ../../src/keyboard.c:1070
#32 0x00000000007642bf in recursive_edit_1 () at ../../src/keyboard.c:714
#33 0x00000000007644b7 in Frecursive_edit () at ../../src/keyboard.c:786
#34 0x000000000076063a in main (argc=2, argv=0x7fffffffe7c8) at ../../src/emacs.c:2035
Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
(gdb)
-----
Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x00007ffff56aeb71 in _int_malloc (av=av@entry=0x7ffff57e3c40 <main_arena>, bytes=bytes@entry=16) at malloc.c:3620
3620 malloc.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0 0x00007ffff56aeb71 in _int_malloc (av=av@entry=0x7ffff57e3c40 <main_arena>, bytes=bytes@entry=16) at malloc.c:3620
#1 0x00007ffff56b0877 in __GI___libc_malloc (bytes=16) at malloc.c:3073
#2 0x00007ffff66533ff in () at /lib/x86_64-linux-gnu/libxcb.so.1
#3 0x00007ffff6653958 in () at /lib/x86_64-linux-gnu/libxcb.so.1
#4 0x00007ffff66b65ee in () at /lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007ffff66b6760 in () at /lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007ffff66b6a5d in _XEventsQueued () at /lib/x86_64-linux-gnu/libX11.so.6
#7 0x00007ffff66a87b7 in XPending () at /lib/x86_64-linux-gnu/libX11.so.6
#8 0x00007ffff6f5220d in () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#9 0x00007ffff6a2b669 in g_main_context_prepare () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007ffff6a2c06b in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007ffff6a2c207 in g_main_context_pending () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007ffff7220b9d in gtk_events_pending () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#13 0x000000000071dda2 in XTread_socket (terminal=0xf0b6d0, hold_quit=0x7fffffffafa0) at ../../src/xterm.c:9402
#14 0x0000000000778e85 in gobble_input () at ../../src/keyboard.c:6885
#15 0x0000000000779365 in handle_async_input () at ../../src/keyboard.c:7122
#16 0x0000000000779384 in process_pending_signals () at ../../src/keyboard.c:7136
#17 0x0000000000841b43 in maybe_quit () at ../../src/eval.c:1545
#18 0x00000000008453aa in Ffuncall (nargs=2, args=0x7fffffffb0f0) at ../../src/eval.c:2766
#19 0x000000000089cf80 in exec_byte_code (bytestr=XIL(0x7ffff3cd2534), vector=XIL(0x7ffff3cd2515), maxdepth=make_fixnum(4), args_template=make_fixnum(256), nargs=1, args=0x7fffffffb5a0) at ../../src/bytecode.c:633
#20 0x0000000000846188 in funcall_lambda (fun=XIL(0x7ffff3cd24e5), nargs=1, arg_vector=0x7fffffffb598) at ../../src/eval.c:2989
#21 0x0000000000845548 in Ffuncall (nargs=2, args=0x7fffffffb590) at ../../src/eval.c:2796
#22 0x000000000089cf80 in exec_byte_code (bytestr=XIL(0x7ffff3cf2c54), vector=XIL(0x7ffff3cf2c3d), maxdepth=make_fixnum(3), args_template=make_fixnum(256), nargs=1, args=0x7fffffffba30) at ../../src/bytecode.c:633
#23 0x0000000000846188 in funcall_lambda (fun=XIL(0x7ffff3cf2c0d), nargs=1, arg_vector=0x7fffffffba28) at ../../src/eval.c:2989
#24 0x0000000000845548 in Ffuncall (nargs=2, args=0x7fffffffba20) at ../../src/eval.c:2796
#25 0x000000000089cf80 in exec_byte_code (bytestr=XIL(0x7ffff3fc2c94), vector=XIL(0x7ffff3fc2b0d), maxdepth=make_fixnum(5), args_template=make_fixnum(0), nargs=0, args=0x7fffffffbed0) at ../../src/bytecode.c:633
#26 0x0000000000846188 in funcall_lambda (fun=XIL(0x7ffff3fc2add), nargs=0, arg_vector=0x7fffffffbed0) at ../../src/eval.c:2989
#27 0x0000000000845548 in Ffuncall (nargs=1, args=0x7fffffffbec8) at ../../src/eval.c:2796
#28 0x000000000089cf80 in exec_byte_code (bytestr=XIL(0x7ffff3fc2e44), vector=XIL(0x7ffff3d999c5), maxdepth=make_fixnum(4), args_template=make_fixnum(0), nargs=0, args=0x7fffffffc378) at ../../src/bytecode.c:633
#29 0x0000000000846188 in funcall_lambda (fun=XIL(0x7ffff3d99995), nargs=0, arg_vector=0x7fffffffc378) at ../../src/eval.c:2989
#30 0x0000000000845548 in Ffuncall (nargs=1, args=0x7fffffffc370) at ../../src/eval.c:2796
#31 0x000000000089cf80 in exec_byte_code (bytestr=XIL(0x7ffff3debd04), vector=XIL(0x7ffff3debced), maxdepth=make_fixnum(2), args_template=make_fixnum(256), nargs=1, args=0x7fffffffc9f8) at ../../src/bytecode.c:633
#32 0x0000000000846188 in funcall_lambda (fun=XIL(0x7ffff3debcbd), nargs=1, arg_vector=0x7fffffffc9f0) at ../../src/eval.c:2989
#33 0x0000000000845548 in Ffuncall (nargs=2, args=0x7fffffffc9e8) at ../../src/eval.c:2796
#34 0x000000000084477d in funcall_nil (nargs=2, args=0x7fffffffc9e8) at ../../src/eval.c:2435
#35 0x0000000000844ca7 in run_hook_with_args (nargs=2, args=0x7fffffffc9e8, funcall=0x84475a <funcall_nil>) at ../../src/eval.c:2612
#36 0x0000000000844803 in Frun_hook_with_args (nargs=2, args=0x7fffffffc9e8) at ../../src/eval.c:2477
#37 0x000000000084592e in funcall_subr (subr=0xe0f180 <Srun_hook_with_args>, numargs=2, args=0x7fffffffc9e8) at ../../src/eval.c:2847
#38 0x0000000000845504 in Ffuncall (nargs=3, args=0x7fffffffc9e0) at ../../src/eval.c:2794
#39 0x0000000000841797 in internal_condition_case_n (bfun=0x845388 <Ffuncall>, nargs=3, args=0x7fffffffc9e0, handlers=XIL(0x30), hfun=0x481a69 <safe_eval_handler>) at ../../src/eval.c:1435
#40 0x0000000000481cbc in safe__call (inhibit_quit=false, nargs=3, func=XIL(0xb9a0), ap=0x7fffffffca90) at ../../src/xdisp.c:2820
#41 0x0000000000481d8d in safe_call (nargs=3, func=XIL(0xb9a0)) at ../../src/xdisp.c:2835
#42 0x0000000000481f1e in safe_call2 (fn=XIL(0xb9a0), arg1=XIL(0x2940), arg2=XIL(0x125cc05)) at ../../src/xdisp.c:2879
#43 0x000000000043458a in delete_frame (frame=XIL(0x125cc05), force=XIL(0x30)) at ../../src/frame.c:2268
#44 0x0000000000434859 in Fdelete_frame (frame=XIL(0x125cc05), force=XIL(0x30)) at ../../src/frame.c:2326
#45 0x0000000000845a5b in funcall_subr (subr=0xe01200 <Sdelete_frame>, numargs=2, args=0x7fffffffcdf0) at ../../src/eval.c:2869
#46 0x0000000000845504 in Ffuncall (nargs=3, args=0x7fffffffcde8) at ../../src/eval.c:2794
#47 0x000000000089cf80 in exec_byte_code (bytestr=XIL(0x7ffff3fe33a4), vector=XIL(0x7ffff3d6e68d), maxdepth=make_fixnum(7), args_template=make_fixnum(257), nargs=1, args=0x7fffffffd3f8) at ../../src/bytecode.c:633
#48 0x0000000000846188 in funcall_lambda (fun=XIL(0x7ffff3d6e655), nargs=1, arg_vector=0x7fffffffd3f0) at ../../src/eval.c:2989
#49 0x0000000000845548 in Ffuncall (nargs=2, args=0x7fffffffd3e8) at ../../src/eval.c:2796
#50 0x0000000000839ba8 in Ffuncall_interactively (nargs=2, args=0x7fffffffd3e8) at ../../src/callint.c:254
#51 0x000000000084592e in funcall_subr (subr=0xe0e900 <Sfuncall_interactively>, numargs=2, args=0x7fffffffd3e8) at ../../src/eval.c:2847
#52 0x0000000000845504 in Ffuncall (nargs=3, args=0x7fffffffd3e0) at ../../src/eval.c:2794
#53 0x000000000083c20f in Fcall_interactively (function=XIL(0x7ffff2eebd40), record_flag=XIL(0), keys=XIL(0x200a9d5)) at ../../src/callint.c:783
#54 0x0000000000845a87 in funcall_subr (subr=0xe0e940 <Scall_interactively>, numargs=3, args=0x7fffffffd7c0) at ../../src/eval.c:2872
#55 0x0000000000845504 in Ffuncall (nargs=4, args=0x7fffffffd7b8) at ../../src/eval.c:2794
#56 0x000000000089cf80 in exec_byte_code (bytestr=XIL(0x7ffff3e1e284), vector=XIL(0x7ffff3e1dda5), maxdepth=make_fixnum(13), args_template=make_fixnum(1025), nargs=4, args=0x7fffffffdd38) at ../../src/bytecode.c:633
#57 0x0000000000846188 in funcall_lambda (fun=XIL(0x7ffff3e1dd75), nargs=4, arg_vector=0x7fffffffdd18) at ../../src/eval.c:2989
#58 0x0000000000845548 in Ffuncall (nargs=5, args=0x7fffffffdd10) at ../../src/eval.c:2796
#59 0x0000000000844f15 in call4 (fn=XIL(0x41a0), arg1=XIL(0x7ffff2eebd40), arg2=XIL(0), arg3=XIL(0x200a9d5), arg4=XIL(0x30)) at ../../src/eval.c:2676
#60 0x000000000076a5f0 in read_char (commandflag=1, map=XIL(0x1fef813), prev_event=XIL(0), used_mouse_menu=0x7fffffffe13f, end_time=0x0) at ../../src/keyboard.c:2882
#61 0x000000000078028e in read_key_sequence (keybuf=0x7fffffffe2d0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9547
#62 0x0000000000765645 in command_loop_1 () at ../../src/keyboard.c:1350
#63 0x00000000008414e8 in internal_condition_case (bfun=0x7651c9 <command_loop_1>, handlers=XIL(0x90), hfun=0x7647d8 <cmd_error>) at ../../src/eval.c:1355
#64 0x0000000000764dae in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1091
#65 0x000000000084099c in internal_catch (tag=XIL(0xd200), func=0x764d81 <command_loop_2>, arg=XIL(0)) at ../../src/eval.c:1116
#66 0x0000000000764d4c in command_loop () at ../../src/keyboard.c:1070
#67 0x00000000007642bf in recursive_edit_1 () at ../../src/keyboard.c:714
#68 0x00000000007644b7 in Frecursive_edit () at ../../src/keyboard.c:786
#69 0x000000000076063a in main (argc=2, argv=0x7fffffffe7c8) at ../../src/emacs.c:2035
Lisp Backtrace:
"framep-on-display" (0xffffb598)
"display-graphic-p" (0xffffba28)
"blink-cursor--should-blink" (0xffffbed0)
"blink-cursor-check" (0xffffc378)
"blink-cursor--rescan-frames" (0xffffc9f0)
"run-hook-with-args" (0xffffc9e8)
"delete-frame" (0xffffcdf0)
"handle-delete-frame" (0xffffd3f0)
"funcall-interactively" (0xffffd3e8)
"call-interactively" (0xffffd7c0)
"command-execute" (0xffffdd18)
(gdb)
-----
Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x00007ffff6a499ea in g_slice_alloc () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff6a499ea in g_slice_alloc () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x00007ffff6a49e69 in g_slice_alloc0 () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff718666c in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#3 0x00007ffff716dd22 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#4 0x00007ffff716df2d in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#5 0x00007ffff717ea74 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#6 0x00007ffff716a2ca in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#7 0x00007ffff717e9ac in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#8 0x00007ffff716c865 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#9 0x00007ffff716b634 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#10 0x00007ffff716c35d in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#11 0x00007ffff7152cfe in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#12 0x00007ffff6b0dc8d in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#13 0x00007ffff6b21365 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#14 0x00007ffff6b2a2be in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#15 0x00007ffff6b2a97f in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#16 0x00007ffff6f2a9ba in () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#17 0x00007ffff6f15c08 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#18 0x00007ffff6a2c863 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007ffff6a2bdd8 in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007ffff6a2c1c8 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x00007ffff6a2c25c in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#22 0x00007ffff7220bc5 in gtk_main_iteration () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#23 0x000000000071dd74 in XTread_socket (terminal=0xf0b6d0, hold_quit=0x7fffffffb8c0) at ../../src/xterm.c:9407
#24 0x0000000000778e85 in gobble_input () at ../../src/keyboard.c:6885
#25 0x0000000000779365 in handle_async_input () at ../../src/keyboard.c:7122
#26 0x0000000000779384 in process_pending_signals () at ../../src/keyboard.c:7136
#27 0x0000000000841b43 in maybe_quit () at ../../src/eval.c:1545
#28 0x00000000008453aa in Ffuncall (nargs=2, args=0x7fffffffba20) at ../../src/eval.c:2766
#29 0x000000000089cf80 in exec_byte_code (bytestr=XIL(0x7ffff3fc2c94), vector=XIL(0x7ffff3fc2b0d), maxdepth=make_fixnum(5), args_template=make_fixnum(0), nargs=0, args=0x7fffffffbed0) at ../../src/bytecode.c:633
#30 0x0000000000846188 in funcall_lambda (fun=XIL(0x7ffff3fc2add), nargs=0, arg_vector=0x7fffffffbed0) at ../../src/eval.c:2989
#31 0x0000000000845548 in Ffuncall (nargs=1, args=0x7fffffffbec8) at ../../src/eval.c:2796
#32 0x000000000089cf80 in exec_byte_code (bytestr=XIL(0x7ffff3fc2e44), vector=XIL(0x7ffff3d999c5), maxdepth=make_fixnum(4), args_template=make_fixnum(0), nargs=0, args=0x7fffffffc378) at ../../src/bytecode.c:633
#33 0x0000000000846188 in funcall_lambda (fun=XIL(0x7ffff3d99995), nargs=0, arg_vector=0x7fffffffc378) at ../../src/eval.c:2989
#34 0x0000000000845548 in Ffuncall (nargs=1, args=0x7fffffffc370) at ../../src/eval.c:2796
#35 0x000000000089cf80 in exec_byte_code (bytestr=XIL(0x7ffff3debd04), vector=XIL(0x7ffff3debced), maxdepth=make_fixnum(2), args_template=make_fixnum(256), nargs=1, args=0x7fffffffc9f8) at ../../src/bytecode.c:633
#36 0x0000000000846188 in funcall_lambda (fun=XIL(0x7ffff3debcbd), nargs=1, arg_vector=0x7fffffffc9f0) at ../../src/eval.c:2989
#37 0x0000000000845548 in Ffuncall (nargs=2, args=0x7fffffffc9e8) at ../../src/eval.c:2796
#38 0x000000000084477d in funcall_nil (nargs=2, args=0x7fffffffc9e8) at ../../src/eval.c:2435
#39 0x0000000000844ca7 in run_hook_with_args (nargs=2, args=0x7fffffffc9e8, funcall=0x84475a <funcall_nil>) at ../../src/eval.c:2612
#40 0x0000000000844803 in Frun_hook_with_args (nargs=2, args=0x7fffffffc9e8) at ../../src/eval.c:2477
#41 0x000000000084592e in funcall_subr (subr=0xe0f180 <Srun_hook_with_args>, numargs=2, args=0x7fffffffc9e8) at ../../src/eval.c:2847
#42 0x0000000000845504 in Ffuncall (nargs=3, args=0x7fffffffc9e0) at ../../src/eval.c:2794
#43 0x0000000000841797 in internal_condition_case_n (bfun=0x845388 <Ffuncall>, nargs=3, args=0x7fffffffc9e0, handlers=XIL(0x30), hfun=0x481a69 <safe_eval_handler>) at ../../src/eval.c:1435
#44 0x0000000000481cbc in safe__call (inhibit_quit=false, nargs=3, func=XIL(0xb9a0), ap=0x7fffffffca90) at ../../src/xdisp.c:2820
#45 0x0000000000481d8d in safe_call (nargs=3, func=XIL(0xb9a0)) at ../../src/xdisp.c:2835
#46 0x0000000000481f1e in safe_call2 (fn=XIL(0xb9a0), arg1=XIL(0x2940), arg2=XIL(0x12ffd95)) at ../../src/xdisp.c:2879
#47 0x000000000043458a in delete_frame (frame=XIL(0x12ffd95), force=XIL(0x30)) at ../../src/frame.c:2268
#48 0x0000000000434859 in Fdelete_frame (frame=XIL(0x12ffd95), force=XIL(0x30)) at ../../src/frame.c:2326
#49 0x0000000000845a5b in funcall_subr (subr=0xe01200 <Sdelete_frame>, numargs=2, args=0x7fffffffcdf0) at ../../src/eval.c:2869
#50 0x0000000000845504 in Ffuncall (nargs=3, args=0x7fffffffcde8) at ../../src/eval.c:2794
#51 0x000000000089cf80 in exec_byte_code (bytestr=XIL(0x7ffff3fe33a4), vector=XIL(0x7ffff3d6e68d), maxdepth=make_fixnum(7), args_template=make_fixnum(257), nargs=1, args=0x7fffffffd3f8) at ../../src/bytecode.c:633
#52 0x0000000000846188 in funcall_lambda (fun=XIL(0x7ffff3d6e655), nargs=1, arg_vector=0x7fffffffd3f0) at ../../src/eval.c:2989
#53 0x0000000000845548 in Ffuncall (nargs=2, args=0x7fffffffd3e8) at ../../src/eval.c:2796
#54 0x0000000000839ba8 in Ffuncall_interactively (nargs=2, args=0x7fffffffd3e8) at ../../src/callint.c:254
#55 0x000000000084592e in funcall_subr (subr=0xe0e900 <Sfuncall_interactively>, numargs=2, args=0x7fffffffd3e8) at ../../src/eval.c:2847
#56 0x0000000000845504 in Ffuncall (nargs=3, args=0x7fffffffd3e0) at ../../src/eval.c:2794
#57 0x000000000083c20f in Fcall_interactively (function=XIL(0x7ffff2eebd40), record_flag=XIL(0), keys=XIL(0x1fe1df5)) at ../../src/callint.c:783
#58 0x0000000000845a87 in funcall_subr (subr=0xe0e940 <Scall_interactively>, numargs=3, args=0x7fffffffd7c0) at ../../src/eval.c:2872
#59 0x0000000000845504 in Ffuncall (nargs=4, args=0x7fffffffd7b8) at ../../src/eval.c:2794
#60 0x000000000089cf80 in exec_byte_code (bytestr=XIL(0x7ffff3e1e284), vector=XIL(0x7ffff3e1dda5), maxdepth=make_fixnum(13), args_template=make_fixnum(1025), nargs=4, args=0x7fffffffdd38) at ../../src/bytecode.c:633
#61 0x0000000000846188 in funcall_lambda (fun=XIL(0x7ffff3e1dd75), nargs=4, arg_vector=0x7fffffffdd18) at ../../src/eval.c:2989
#62 0x0000000000845548 in Ffuncall (nargs=5, args=0x7fffffffdd10) at ../../src/eval.c:2796
#63 0x0000000000844f15 in call4 (fn=XIL(0x41a0), arg1=XIL(0x7ffff2eebd40), arg2=XIL(0), arg3=XIL(0x1fe1df5), arg4=XIL(0x30)) at ../../src/eval.c:2676
#64 0x000000000076a5f0 in read_char (commandflag=1, map=XIL(0x17cde83), prev_event=XIL(0), used_mouse_menu=0x7fffffffe13f, end_time=0x0) at ../../src/keyboard.c:2882
#65 0x000000000078028e in read_key_sequence (keybuf=0x7fffffffe2d0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9547
#66 0x0000000000765645 in command_loop_1 () at ../../src/keyboard.c:1350
#67 0x00000000008414e8 in internal_condition_case (bfun=0x7651c9 <command_loop_1>, handlers=XIL(0x90), hfun=0x7647d8 <cmd_error>) at ../../src/eval.c:1355
#68 0x0000000000764dae in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1091
#69 0x000000000084099c in internal_catch (tag=XIL(0xd200), func=0x764d81 <command_loop_2>, arg=XIL(0)) at ../../src/eval.c:1116
#70 0x0000000000764d4c in command_loop () at ../../src/keyboard.c:1070
#71 0x00000000007642bf in recursive_edit_1 () at ../../src/keyboard.c:714
#72 0x00000000007644b7 in Frecursive_edit () at ../../src/keyboard.c:786
#73 0x000000000076063a in main (argc=2, argv=0x7fffffffe7c8) at ../../src/emacs.c:2035
Lisp Backtrace:
"blink-cursor--should-blink" (0xffffbed0)
"blink-cursor-check" (0xffffc378)
"blink-cursor--rescan-frames" (0xffffc9f0)
"run-hook-with-args" (0xffffc9e8)
"delete-frame" (0xffffcdf0)
"handle-delete-frame" (0xffffd3f0)
"funcall-interactively" (0xffffd3e8)
"call-interactively" (0xffffd7c0)
"command-execute" (0xffffdd18)
(gdb)
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-13 17:42 bug#41239: GTK builds crashing in XTread_socket after deleting a frame martin rudalics
@ 2020-05-13 18:04 ` Eli Zaretskii
2020-05-14 7:54 ` martin rudalics
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2020-05-13 18:04 UTC (permalink / raw)
To: martin rudalics; +Cc: 41239
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 13 May 2020 19:42:43 +0200
>
> This looks like yet another GTK specific crash where we apparently can't
> do much. But maybe someone can spot a pattern we could employ to avoid
> the XTread_socket calls when deleting a frame.
Isn't block_input inside Fdelete_frame what you want?
However, the first backtrace doesn't show Fdelete_frame in the
backtrace, so I'm not sure what's going on there.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-13 18:04 ` Eli Zaretskii
@ 2020-05-14 7:54 ` martin rudalics
2020-05-14 14:22 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: martin rudalics @ 2020-05-14 7:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 41239
>> This looks like yet another GTK specific crash where we apparently can't
>> do much. But maybe someone can spot a pattern we could employ to avoid
>> the XTread_socket calls when deleting a frame.
>
> Isn't block_input inside Fdelete_frame what you want?
Do you mean the already existing one in delete_frame or adding a new
one?
> However, the first backtrace doesn't show Fdelete_frame in the
> backtrace, so I'm not sure what's going on there.
Neither do I. Note some of the prerequisites:
- Tooltips must be GTK+ native ones - no crash with our tooltips.
- There must be two frames - no crash with just one frame.
- Deleting the frame must be via Alt-F4 - no crash with C-x 5 0.
martin
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-14 7:54 ` martin rudalics
@ 2020-05-14 14:22 ` Eli Zaretskii
2020-05-15 18:07 ` martin rudalics
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2020-05-14 14:22 UTC (permalink / raw)
To: martin rudalics; +Cc: 41239
> Cc: 41239@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 14 May 2020 09:54:02 +0200
>
> >> This looks like yet another GTK specific crash where we apparently can't
> >> do much. But maybe someone can spot a pattern we could employ to avoid
> >> the XTread_socket calls when deleting a frame.
> >
> > Isn't block_input inside Fdelete_frame what you want?
>
> Do you mean the already existing one in delete_frame or adding a new
> one?
The existing ones cover only small parts of delete_frame, and the
safe_call2 call is outside both of them, AFAICT. So yes, I mean
blocking input around the safe_call2 call.
> > However, the first backtrace doesn't show Fdelete_frame in the
> > backtrace, so I'm not sure what's going on there.
>
> Neither do I. Note some of the prerequisites:
>
> - Tooltips must be GTK+ native ones - no crash with our tooltips.
>
> - There must be two frames - no crash with just one frame.
>
> - Deleting the frame must be via Alt-F4 - no crash with C-x 5 0.
What about the frame whose menu bar is being updated -- is that the
frame we deleted, by any chance? Is it a live frame?
The crashes are all in memory allocation routines, so another
possibility is that we have some memory corruption.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-14 14:22 ` Eli Zaretskii
@ 2020-05-15 18:07 ` martin rudalics
2020-05-15 18:58 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: martin rudalics @ 2020-05-15 18:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 41239
[-- Attachment #1: Type: text/plain, Size: 6062 bytes --]
>> Do you mean the already existing one in delete_frame or adding a new
>> one?
>
> The existing ones cover only small parts of delete_frame, and the
> safe_call2 call is outside both of them, AFAICT. So yes, I mean
> blocking input around the safe_call2 call.
Wouldn't that also block any 'yes-or-no-p' questions we ask when running
these hooks. Anyway, it doesn't help. It crashes as soon as we unblock
input, for example, thusly
--------------------------
Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
tcache_get (tc_idx=0) at malloc.c:2951
2951 malloc.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0 0x00007ffff549a7be in tcache_get (tc_idx=0) at malloc.c:2951
#1 0x00007ffff549a7be in __GI___libc_malloc (bytes=16) at malloc.c:3058
#2 0x00007ffff66533ff in () at /lib/x86_64-linux-gnu/libxcb.so.1
#3 0x00007ffff6650fb5 in () at /lib/x86_64-linux-gnu/libxcb.so.1
#4 0x00007ffff66513b1 in () at /lib/x86_64-linux-gnu/libxcb.so.1
#5 0x00007ffff665143d in xcb_writev () at /lib/x86_64-linux-gnu/libxcb.so.1
#6 0x00007ffff66b697e in _XSend () at /lib/x86_64-linux-gnu/libX11.so.6
#7 0x00007ffff66b6a89 in _XEventsQueued () at /lib/x86_64-linux-gnu/libX11.so.6
#8 0x00007ffff66a87b7 in XPending () at /lib/x86_64-linux-gnu/libX11.so.6
#9 0x00007ffff6f5220d in () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#10 0x00007ffff6a2b669 in g_main_context_prepare () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007ffff6a2c06b in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007ffff6a2c207 in g_main_context_pending () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007ffff7220b9d in gtk_events_pending () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#14 0x00000000005cf188 in XTread_socket (terminal=0x1093280, hold_quit=0x7fffffffcab0) at ../../src/xterm.c:9377
#15 0x000000000065a86d in gobble_input () at ../../src/keyboard.c:6891
#16 0x000000000065ad4d in handle_async_input () at ../../src/keyboard.c:7128
#17 0x000000000065ad6c in process_pending_signals () at ../../src/keyboard.c:7142
#18 0x000000000065adac in unblock_input_to (level=0) at ../../src/keyboard.c:7157
#19 0x000000000065add0 in unblock_input () at ../../src/keyboard.c:7176
#20 0x000000000043c478 in delete_frame (frame=XIL(0x1498445), force=XIL(0x30)) at ../../src/frame.c:2146
#21 0x000000000043cdff in Fdelete_frame (frame=XIL(0x1498445), force=XIL(0x30)) at ../../src/frame.c:2333
#22 0x00000000007b3c79 in funcall_subr (subr=0xf86040 <Sdelete_frame>, numargs=2, args=0x7fffffffcdf0) at ../../src/eval.c:2869
#23 0x00000000007b3722 in Ffuncall (nargs=3, args=0x7fffffffcde8) at ../../src/eval.c:2794
#24 0x0000000000836d18 in exec_byte_code (bytestr=XIL(0x7ffff3dd8ff4), vector=XIL(0x7ffff3c510bd), maxdepth=make_fixnum(7), args_template=make_fixnum(257), nargs=1, args=0x7fffffffd3f8) at ../../src/bytecode.c:633
#25 0x00000000007b43a6 in funcall_lambda (fun=XIL(0x7ffff3c51085), nargs=1, arg_vector=0x7fffffffd3f0) at ../../src/eval.c:2989
#26 0x00000000007b3766 in Ffuncall (nargs=2, args=0x7fffffffd3e8) at ../../src/eval.c:2796
#27 0x00000000007a235a in Ffuncall_interactively (nargs=2, args=0x7fffffffd3e8) at ../../src/callint.c:254
#28 0x00000000007b3b4c in funcall_subr (subr=0xf934c0 <Sfuncall_interactively>, numargs=2, args=0x7fffffffd3e8) at ../../src/eval.c:2847
#29 0x00000000007b3722 in Ffuncall (nargs=3, args=0x7fffffffd3e0) at ../../src/eval.c:2794
#30 0x00000000007a4b24 in Fcall_interactively (function=XIL(0x7ffff2c49b90), record_flag=XIL(0), keys=XIL(0x2191f35)) at ../../src/callint.c:783
#31 0x00000000007b3ca5 in funcall_subr (subr=0xf93500 <Scall_interactively>, numargs=3, args=0x7fffffffd7c0) at ../../src/eval.c:2872
#32 0x00000000007b3722 in Ffuncall (nargs=4, args=0x7fffffffd7b8) at ../../src/eval.c:2794
#33 0x0000000000836d18 in exec_byte_code (bytestr=XIL(0x7ffff3d8182c), vector=XIL(0x7ffff3d81585), maxdepth=make_fixnum(13), args_template=make_fixnum(1025), nargs=4, args=0x7fffffffdd38) at ../../src/bytecode.c:633
#34 0x00000000007b43a6 in funcall_lambda (fun=XIL(0x7ffff3d81555), nargs=4, arg_vector=0x7fffffffdd18) at ../../src/eval.c:2989
#35 0x00000000007b3766 in Ffuncall (nargs=5, args=0x7fffffffdd10) at ../../src/eval.c:2796
#36 0x00000000007b3133 in call4 (fn=XIL(0x41a0), arg1=XIL(0x7ffff2c49b90), arg2=XIL(0), arg3=XIL(0x2191f35), arg4=XIL(0x30)) at ../../src/eval.c:2676
#37 0x00000000006502dd in read_char (commandflag=1, map=XIL(0x1e7aeb3), prev_event=XIL(0), used_mouse_menu=0x7fffffffe13f, end_time=0x0) at ../../src/keyboard.c:2882
#38 0x0000000000661c76 in read_key_sequence (keybuf=0x7fffffffe2d0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9553
#39 0x000000000064b214 in command_loop_1 () at ../../src/keyboard.c:1350
#40 0x00000000007af706 in internal_condition_case (bfun=0x64ad98 <command_loop_1>, handlers=XIL(0x90), hfun=0x64a3a7 <cmd_error>) at ../../src/eval.c:1355
#41 0x000000000064a97d in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1091
#42 0x00000000007aebba in internal_catch (tag=XIL(0xd110), func=0x64a950 <command_loop_2>, arg=XIL(0)) at ../../src/eval.c:1116
#43 0x000000000064a91b in command_loop () at ../../src/keyboard.c:1070
#44 0x0000000000649e8e in recursive_edit_1 () at ../../src/keyboard.c:714
#45 0x000000000064a086 in Frecursive_edit () at ../../src/keyboard.c:786
#46 0x000000000064048f in main (argc=2, argv=0x7fffffffe7c8) at ../../src/emacs.c:2054
Lisp Backtrace:
"delete-frame" (0xffffcdf0)
"handle-delete-frame" (0xffffd3f0)
"funcall-interactively" (0xffffd3e8)
"call-interactively" (0xffffd7c0)
"command-execute" (0xffffdd18)
------------------------------
Incidentally, a pure-GTK build does not crash but leaves behind all
tooltips that were open when their frame was deleted until the emacs
session is closed. So it seems that we have to take care of these
tooltips ourselves.
The attached patch avoids the crash (and by side effect removes all
tooltips when a frame gets deleted). The GTK warnings still appear.
martin
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: tooltip-crash.diff --]
[-- Type: text/x-patch; name="tooltip-crash.diff", Size: 606 bytes --]
diff --git a/src/frame.c b/src/frame.c
index 4dd8bb1804..e5bf21bd3f 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -2011,6 +2011,12 @@ delete_frame (Lisp_Object frame, Lisp_Object force)
/* At this point, we are committed to deleting the frame.
There is no more chance for errors to prevent it. */
+
+ /* Hide any pending tooltip (Bug#41239) unless FRAME itself is a
+ tooltip frame. */
+ if (!is_tooltip_frame)
+ Fx_hide_tip ();
+
minibuffer_selected = EQ (minibuf_window, selected_window);
sf = SELECTED_FRAME ();
/* Don't let the frame remain selected. */
^ permalink raw reply related [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-15 18:07 ` martin rudalics
@ 2020-05-15 18:58 ` Eli Zaretskii
2020-05-16 8:45 ` martin rudalics
2020-05-20 1:50 ` Noam Postavsky
0 siblings, 2 replies; 24+ messages in thread
From: Eli Zaretskii @ 2020-05-15 18:58 UTC (permalink / raw)
To: martin rudalics; +Cc: 41239
> Cc: 41239@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Fri, 15 May 2020 20:07:57 +0200
>
> Wouldn't that also block any 'yes-or-no-p' questions we ask when running
> these hooks. Anyway, it doesn't help. It crashes as soon as we unblock
> input, for example, thusly
So we need to understand why that crashes.
> tcache_get (tc_idx=0) at malloc.c:2951
> 2951 malloc.c: Datei oder Verzeichnis nicht gefunden.
> (gdb) bt
> #0 0x00007ffff549a7be in tcache_get (tc_idx=0) at malloc.c:2951
> #1 0x00007ffff549a7be in __GI___libc_malloc (bytes=16) at malloc.c:3058
Once again, all the crashes are inside memory-allocation functions,
which suggests some kind of memory corruption. Did someone try to run
this scenario under valgrind?
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-15 18:58 ` Eli Zaretskii
@ 2020-05-16 8:45 ` martin rudalics
2020-05-20 1:50 ` Noam Postavsky
1 sibling, 0 replies; 24+ messages in thread
From: martin rudalics @ 2020-05-16 8:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 41239
> Once again, all the crashes are inside memory-allocation functions,
> which suggests some kind of memory corruption.
But we can't exclude that this corruption happens in the GTK code, I
presume.
> Did someone try to run
> this scenario under valgrind?
I don't have it installed and never used it. So I'm afraid that
someone else would have to chime in.
martin
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-15 18:58 ` Eli Zaretskii
2020-05-16 8:45 ` martin rudalics
@ 2020-05-20 1:50 ` Noam Postavsky
2020-05-20 9:06 ` martin rudalics
2020-05-20 16:07 ` Eli Zaretskii
1 sibling, 2 replies; 24+ messages in thread
From: Noam Postavsky @ 2020-05-20 1:50 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 41239
[-- Attachment #1: Type: text/plain, Size: 372 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
> Once again, all the crashes are inside memory-allocation functions,
> which suggests some kind of memory corruption. Did someone try to run
> this scenario under valgrind?
I've tried it now, log attached (minus what I believe are some false
positives that printed during startup). This is against latest master
[1: 5352bda4ee].
[-- Attachment #2: valgrind log --]
[-- Type: application/gzip, Size: 1035 bytes --]
[-- Attachment #3: Type: text/plain, Size: 168 bytes --]
[1: 5352bda4ee]: 2020-05-20 00:15:11 +0100
Add test for bug#39680
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=5352bda4eeb7415ad2bda5d74e007b4f36021e68
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-20 1:50 ` Noam Postavsky
@ 2020-05-20 9:06 ` martin rudalics
2020-05-20 16:07 ` Eli Zaretskii
1 sibling, 0 replies; 24+ messages in thread
From: martin rudalics @ 2020-05-20 9:06 UTC (permalink / raw)
To: Noam Postavsky, Eli Zaretskii; +Cc: 41239
> I've tried it now, log attached (minus what I believe are some false
> positives that printed during startup). This is against latest master
> [1: 5352bda4ee].
Thank you! Hopefully, Eli will be able to derive a fix from it. I
can't.
martin
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-20 1:50 ` Noam Postavsky
2020-05-20 9:06 ` martin rudalics
@ 2020-05-20 16:07 ` Eli Zaretskii
2020-05-22 1:23 ` Noam Postavsky
1 sibling, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2020-05-20 16:07 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 41239
> From: Noam Postavsky <npostavs@gmail.com>
> Cc: martin rudalics <rudalics@gmx.at>, 41239@debbugs.gnu.org
> Date: Tue, 19 May 2020 21:50:35 -0400
>
> > Once again, all the crashes are inside memory-allocation functions,
> > which suggests some kind of memory corruption. Did someone try to run
> > this scenario under valgrind?
>
> I've tried it now, log attached (minus what I believe are some false
> positives that printed during startup). This is against latest master
Thanks. This seems to say that we cause some memory allocation in
functions called by xg_prepare_tooltip, but the allocated memory
region is not large enough, and that causes invalid reads beyond end
of allocated region when we call xg_free_frame_widgets (as side effect
of deleting the tooltip frame, I suppose).
Can someone spot where we pass some wrong parameters to GTK/GIO
functions in xg_prepare_tooltip? Or something we do wrong in
xg_free_frame_widgets? Failing that, I guess we will need to step
through the GTK functions mentioned by valgrind and see what's going
on there.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-20 16:07 ` Eli Zaretskii
@ 2020-05-22 1:23 ` Noam Postavsky
2020-05-22 9:31 ` martin rudalics
0 siblings, 1 reply; 24+ messages in thread
From: Noam Postavsky @ 2020-05-22 1:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 41239
Eli Zaretskii <eliz@gnu.org> writes:
> Can someone spot where we pass some wrong parameters to GTK/GIO
> functions in xg_prepare_tooltip? Or something we do wrong in
> xg_free_frame_widgets?
The patch below seems to fix it.
--- i/src/gtkutil.c
+++ w/src/gtkutil.c
@@ -1404,10 +1404,15 @@ xg_free_frame_widgets (struct frame *f)
FRAME_X_WINDOW (f) = 0; /* Set to avoid XDestroyWindow in xterm.c */
FRAME_X_RAW_DRAWABLE (f) = 0;
FRAME_GTK_OUTER_WIDGET (f) = 0;
+ if (x->ttip_widget)
+ {
+ /* Remove ttip_lbl from ttip_widget's custom slot before
+ destroying it, to avoid double-free (Bug#41239). */
+ gtk_tooltip_set_custom (x->ttip_widget, NULL);
+ g_object_unref (G_OBJECT (x->ttip_widget));
+ }
if (x->ttip_lbl)
gtk_widget_destroy (x->ttip_lbl);
- if (x->ttip_widget)
- g_object_unref (G_OBJECT (x->ttip_widget));
}
}
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-22 1:23 ` Noam Postavsky
@ 2020-05-22 9:31 ` martin rudalics
2020-05-22 11:05 ` Eli Zaretskii
2020-05-22 11:25 ` Noam Postavsky
0 siblings, 2 replies; 24+ messages in thread
From: martin rudalics @ 2020-05-22 9:31 UTC (permalink / raw)
To: Noam Postavsky, Eli Zaretskii; +Cc: 41239
> The patch below seems to fix it.
It fixes the crash and I think you should apply it. It doesn't fix the
(emacs:4258): GLib-CRITICAL **: 10:02:32.377: Source ID 356 was not found when attempting to remove it
issue though, just like the more intrusive fix I posted earlier.
Thanks, martin
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-22 9:31 ` martin rudalics
@ 2020-05-22 11:05 ` Eli Zaretskii
2020-05-22 11:25 ` Noam Postavsky
1 sibling, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2020-05-22 11:05 UTC (permalink / raw)
To: martin rudalics; +Cc: 41239, npostavs
> Cc: 41239@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Fri, 22 May 2020 11:31:17 +0200
>
> > The patch below seems to fix it.
>
> It fixes the crash and I think you should apply it.
I agree.
Thanks.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-22 9:31 ` martin rudalics
2020-05-22 11:05 ` Eli Zaretskii
@ 2020-05-22 11:25 ` Noam Postavsky
2020-05-22 12:08 ` Eli Zaretskii
2020-05-22 13:03 ` martin rudalics
1 sibling, 2 replies; 24+ messages in thread
From: Noam Postavsky @ 2020-05-22 11:25 UTC (permalink / raw)
To: martin rudalics; +Cc: 41239
martin rudalics <rudalics@gmx.at> writes:
> It doesn't fix the
>
> (emacs:4258): GLib-CRITICAL **: 10:02:32.377: Source ID 356 was not found when attempting to remove it
>
> issue though, just like the more intrusive fix I posted earlier.
Oh, hmm, I don't get that (with or without the patch) here actually.
Eli Zaretskii <eliz@gnu.org> writes:
>> It fixes the crash and I think you should apply it.
>
> I agree.
For emacs-27 or master?
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-22 11:25 ` Noam Postavsky
@ 2020-05-22 12:08 ` Eli Zaretskii
2020-05-22 12:22 ` Noam Postavsky
2020-05-22 13:03 ` martin rudalics
1 sibling, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2020-05-22 12:08 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 41239
> From: Noam Postavsky <npostavs@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 41239@debbugs.gnu.org
> Date: Fri, 22 May 2020 07:25:43 -0400
>
> >> It fixes the crash and I think you should apply it.
> >
> > I agree.
>
> For emacs-27 or master?
I thought about master. Are there good reasons to put this on
emacs-27?
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-22 12:08 ` Eli Zaretskii
@ 2020-05-22 12:22 ` Noam Postavsky
2020-05-22 12:37 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: Noam Postavsky @ 2020-05-22 12:22 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 41239
Eli Zaretskii <eliz@gnu.org> writes:
> Are there good reasons to put this on emacs-27?
I thought the fix could be simple enough to consider for emacs-27, but
master is fine by me. I'll push tomorrow.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-22 12:22 ` Noam Postavsky
@ 2020-05-22 12:37 ` Eli Zaretskii
2020-05-25 0:31 ` Noam Postavsky
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2020-05-22 12:37 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 41239
> From: Noam Postavsky <npostavs@gmail.com>
> Cc: rudalics@gmx.at, 41239@debbugs.gnu.org
> Date: Fri, 22 May 2020 08:22:10 -0400
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Are there good reasons to put this on emacs-27?
>
> I thought the fix could be simple enough to consider for emacs-27
It is indeed simple, but is it safe enough? If you think it is, and
cannot cause inadvertent problems, let's install this on emacs-27.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-22 11:25 ` Noam Postavsky
2020-05-22 12:08 ` Eli Zaretskii
@ 2020-05-22 13:03 ` martin rudalics
[not found] ` <87d06vl5le.fsf@gmail.com>
1 sibling, 1 reply; 24+ messages in thread
From: martin rudalics @ 2020-05-22 13:03 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 41239
>> It doesn't fix the
>>
>> (emacs:4258): GLib-CRITICAL **: 10:02:32.377: Source ID 356 was not found when attempting to remove it
>>
>> issue though, just like the more intrusive fix I posted earlier.
>
> Oh, hmm, I don't get that (with or without the patch) here actually.
I still get it but it may need a couple of C-x 5 2's and possibly
showing the tooltip on different locations. On
GNU Emacs 27.0.91 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.5)
of 2020-05-20
run under GDB.
martin
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
[not found] ` <83r1vb189z.fsf@gnu.org>
@ 2020-05-23 12:08 ` Noam Postavsky
2020-05-23 12:38 ` martin rudalics
0 siblings, 1 reply; 24+ messages in thread
From: Noam Postavsky @ 2020-05-23 12:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 41239
Eli Zaretskii <eliz@gnu.org> writes:
>
> Did you succeed in understanding what is that "ID 356" about which it
> complains, and why it wasn't found?
Not really no, but I have what might be a clue. I can trigger this
condition much more reliably (about 3 in 4, instead of 1 in 10; perhaps
1 in 10 times I was doing the following thing by accident), by
intentionally moving the mouse over another popup location without
letting it pop up, before doing the 'wait for popup and kill frame'
procedure. So maybe our cleanup is too thorough in the case where we
call xg_prepare_tooltip but the tooltip ends up not being shown.
I've tried setting a breakpoint in g_remove_source, but then I'm
flooded: it seems to be called every time the mouse moves even a little.
martin rudalics <rudalics@gmx.at> writes:
>> Ah, I did manage to get it after repeating about 10 times. Following
>> https://stackoverflow.com/questions/23199699/glib-critical-source-id-xxx-was-not-found-when-attempting-to-remove-it
>> I got a backtrace by putting a breakpoint on g_log.
>
> How did you do that? Did you build GTK with debugging information?
No, just 'break g_log' in gdb works.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-23 12:08 ` Noam Postavsky
@ 2020-05-23 12:38 ` martin rudalics
2020-05-25 0:11 ` Noam Postavsky
0 siblings, 1 reply; 24+ messages in thread
From: martin rudalics @ 2020-05-23 12:38 UTC (permalink / raw)
To: Noam Postavsky, Eli Zaretskii; +Cc: 41239
> Not really no, but I have what might be a clue. I can trigger this
> condition much more reliably (about 3 in 4, instead of 1 in 10; perhaps
> 1 in 10 times I was doing the following thing by accident), by
> intentionally moving the mouse over another popup location without
> letting it pop up, before doing the 'wait for popup and kill frame'
> procedure.
Does not seem to help here.
> So maybe our cleanup is too thorough in the case where we
> call xg_prepare_tooltip but the tooltip ends up not being shown.
One observation I've made is that with emacs -Q and switching between
two frames I can occasionally pop up an Emacs tooltip which means that
preparing the GTK tooltip failed for whatever reason.
>> How did you do that? Did you build GTK with debugging information?
>
> No, just 'break g_log' in gdb works.
What did you install for that to work? Would
https://wiki.gnome.org/Newcomers/DebianSourceDebugging
cover it?
martin
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-23 12:38 ` martin rudalics
@ 2020-05-25 0:11 ` Noam Postavsky
2020-05-26 8:03 ` martin rudalics
0 siblings, 1 reply; 24+ messages in thread
From: Noam Postavsky @ 2020-05-25 0:11 UTC (permalink / raw)
To: martin rudalics; +Cc: 41239
martin rudalics <rudalics@gmx.at> writes:
>> No, just 'break g_log' in gdb works.
>
> What did you install for that to work?
Nothing. But I see a possible point of confusion: if you run that
command just after starting gdb, before you've run emacs, then you get
the prompt
Make breakpoint pending on future shared library load? (y or [n])
You might have reflexively answered 'n' to it, since it usually happens
after typoing the function name given to 'break'. But this is a case
where 'y' is the correct answer since g_log is in the glib shared
library, not emacs.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-22 12:37 ` Eli Zaretskii
@ 2020-05-25 0:31 ` Noam Postavsky
2020-09-27 14:43 ` Lars Ingebrigtsen
0 siblings, 1 reply; 24+ messages in thread
From: Noam Postavsky @ 2020-05-25 0:31 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 41239
fixed 41239 28.1
quit
Eli Zaretskii <eliz@gnu.org> writes:
> It is indeed simple, but is it safe enough? If you think it is, and
> cannot cause inadvertent problems, let's install this on emacs-27.
I've decided I don't know enough about gtk to declare it safe. Pushed
to master.
[1: 3b65fb7658]: 2020-05-24 20:14:48 -0400
Fix segfault on closing frame with tooltip (Bug#41239)
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3b65fb7658c2717457c033c6704cf3b007804226
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-25 0:11 ` Noam Postavsky
@ 2020-05-26 8:03 ` martin rudalics
0 siblings, 0 replies; 24+ messages in thread
From: martin rudalics @ 2020-05-26 8:03 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 41239
> Nothing. But I see a possible point of confusion: if you run that
> command just after starting gdb, before you've run emacs, then you get
> the prompt
>
> Make breakpoint pending on future shared library load? (y or [n])
>
> You might have reflexively answered 'n' to it, since it usually happens
> after typoing the function name given to 'break'. But this is a case
> where 'y' is the correct answer since g_log is in the glib shared
> library, not emacs.
I wasn't prompted but just informed that
Function "g_log" not defined.
Breakpoint 3 (g_log) pending.
so I decided that it wouldn't work. But as you pointed out, it does
work.
Thanks again, martin
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#41239: GTK builds crashing in XTread_socket after deleting a frame
2020-05-25 0:31 ` Noam Postavsky
@ 2020-09-27 14:43 ` Lars Ingebrigtsen
0 siblings, 0 replies; 24+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-27 14:43 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 41239
Noam Postavsky <npostavs@gmail.com> writes:
> I've decided I don't know enough about gtk to declare it safe. Pushed
> to master.
>
> [1: 3b65fb7658]: 2020-05-24 20:14:48 -0400
> Fix segfault on closing frame with tooltip (Bug#41239)
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3b65fb7658c2717457c033c6704cf3b007804226
It looks like the reported bug was fixed, but then there was some
additional discussion of some somewhat related gtk warnings. If these
persists, perhaps that warrants opening a new bug report? But I'm
closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2020-09-27 14:43 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-05-13 17:42 bug#41239: GTK builds crashing in XTread_socket after deleting a frame martin rudalics
2020-05-13 18:04 ` Eli Zaretskii
2020-05-14 7:54 ` martin rudalics
2020-05-14 14:22 ` Eli Zaretskii
2020-05-15 18:07 ` martin rudalics
2020-05-15 18:58 ` Eli Zaretskii
2020-05-16 8:45 ` martin rudalics
2020-05-20 1:50 ` Noam Postavsky
2020-05-20 9:06 ` martin rudalics
2020-05-20 16:07 ` Eli Zaretskii
2020-05-22 1:23 ` Noam Postavsky
2020-05-22 9:31 ` martin rudalics
2020-05-22 11:05 ` Eli Zaretskii
2020-05-22 11:25 ` Noam Postavsky
2020-05-22 12:08 ` Eli Zaretskii
2020-05-22 12:22 ` Noam Postavsky
2020-05-22 12:37 ` Eli Zaretskii
2020-05-25 0:31 ` Noam Postavsky
2020-09-27 14:43 ` Lars Ingebrigtsen
2020-05-22 13:03 ` martin rudalics
[not found] ` <87d06vl5le.fsf@gmail.com>
[not found] ` <83r1vb189z.fsf@gnu.org>
2020-05-23 12:08 ` Noam Postavsky
2020-05-23 12:38 ` martin rudalics
2020-05-25 0:11 ` Noam Postavsky
2020-05-26 8:03 ` martin rudalics
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).