GNU bug report logs - #41239
GTK builds crashing in XTread_socket after deleting a frame

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 41239 in the body.
You can then email your comments to 41239 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Subject: GTK builds crashing in XTread_socket after deleting a frame
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.  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 <at> entry=0x7ffff57e3c40 <main_arena>, bytes=bytes <at> entry=16) at malloc.c:3620
3620	malloc.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0x00007ffff56aeb71 in _int_malloc (av=av <at> entry=0x7ffff57e3c40 <main_arena>, bytes=bytes <at> 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 <at> entry=0x7ffff57e3c40 <main_arena>, bytes=bytes <at> entry=16) at malloc.c:3620
3620	malloc.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0x00007ffff56aeb71 in _int_malloc (av=av <at> entry=0x7ffff57e3c40 <main_arena>, bytes=bytes <at> 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)

Message #8 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting a
 frame
Date: Wed, 13 May 2020 21:04:28 +0300

> From: martin rudalics <rudalics <at> 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.

Message #11 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting a
 frame
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?

> 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

Message #14 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting a
 frame
Date: Thu, 14 May 2020 17:22:32 +0300

> Cc: 41239 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> 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.

Message #17 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting a
 frame
Date: Fri, 15 May 2020 20:07:57 +0200

[Message part 1 (text/plain, inline)]

>> 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

[tooltip-crash.diff (text/x-patch, attachment)]

Message #20 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting a
 frame
Date: Fri, 15 May 2020 21:58:20 +0300

> Cc: 41239 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> 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?

Message #23 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting a
 frame
Date: Sat, 16 May 2020 10:45:10 +0200

> 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

Message #26 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting
 a frame
Date: Tue, 19 May 2020 21:50:35 -0400

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> 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].

[valgrind.log.gz (application/gzip, attachment)]

[Message part 3 (text/plain, inline)]

[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

Message #29 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Noam Postavsky <npostavs <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting a
 frame
Date: Wed, 20 May 2020 11:06:30 +0200

> 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

Message #34 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: rudalics <at> gmx.at, 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting
 a frame
Date: Wed, 20 May 2020 19:07:50 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: martin rudalics <rudalics <at> gmx.at>,  41239 <at> 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.

Message #37 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting
 a frame
Date: Thu, 21 May 2020 21:23:49 -0400

Eli Zaretskii <eliz <at> 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));
     }
 }

Message #40 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Noam Postavsky <npostavs <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting a
 frame
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.  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

Message #43 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 41239 <at> debbugs.gnu.org, npostavs <at> gmail.com
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting a
 frame
Date: Fri, 22 May 2020 14:05:33 +0300

> Cc: 41239 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> 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.

Message #46 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting
 a frame
Date: Fri, 22 May 2020 07:25:43 -0400

martin rudalics <rudalics <at> 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 <at> gnu.org> writes:

>> It fixes the crash and I think you should apply it.
>
> I agree.

For emacs-27 or master?

Message #49 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: rudalics <at> gmx.at, 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting
 a frame
Date: Fri, 22 May 2020 15:08:46 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  41239 <at> 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?

Message #52 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting
 a frame
Date: Fri, 22 May 2020 08:22:10 -0400

Eli Zaretskii <eliz <at> 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.

Message #55 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: rudalics <at> gmx.at, 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting
 a frame
Date: Fri, 22 May 2020 15:37:04 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: rudalics <at> gmx.at,  41239 <at> debbugs.gnu.org
> Date: Fri, 22 May 2020 08:22:10 -0400
> 
> Eli Zaretskii <eliz <at> 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.

Message #58 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting a
 frame
Date: Fri, 22 May 2020 15:03:34 +0200

>> 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

Message #61 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting
 a frame
Date: Fri, 22 May 2020 22:58:53 -0400

[Message part 1 (text/plain, inline)]

martin rudalics <rudalics <at> 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.
>
> I still get it but it may need a couple of C-x 5 2's and possibly
> showing the tooltip on different locations.

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.  Not sure what to do
about it though.

[g_log.backtrace (text/plain, attachment)]

Message #64 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: rudalics <at> gmx.at, 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting
 a frame
Date: Sat, 23 May 2020 09:21:12 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  41239 <at> debbugs.gnu.org
> Date: Fri, 22 May 2020 22:58:53 -0400
> 
> >>> (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.
> 
> 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.  Not sure what to do
> about it though.

Did you succeed in understanding what is that "ID 356" about which it
complains, and why it wasn't found?

Message #67 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting a
 frame
Date: Sat, 23 May 2020 10:22:30 +0200

> 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?

> Not sure what to do
> about it though.

Ignore it, I'd say.

martin

Message #70 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting
 a frame
Date: Sat, 23 May 2020 08:08:42 -0400

Eli Zaretskii <eliz <at> 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 <at> 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.

Message #73 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Noam Postavsky <npostavs <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting a
 frame
Date: Sat, 23 May 2020 14:38:03 +0200

> 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

Message #76 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting
 a frame
Date: Sun, 24 May 2020 20:11:42 -0400

martin rudalics <rudalics <at> 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.

Message #79 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting
 a frame
Date: Sun, 24 May 2020 20:31:21 -0400

fixed 41239 28.1
quit

Eli Zaretskii <eliz <at> 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

Message #84 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting a
 frame
Date: Tue, 26 May 2020 10:03:09 +0200

> 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

Message #87 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: rudalics <at> gmx.at, Eli Zaretskii <eliz <at> gnu.org>, 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting
 a frame
Date: Sun, 27 Sep 2020 16:43:38 +0200

Noam Postavsky <npostavs <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.