From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 30 08:51:41 2015 Received: (at submit) by debbugs.gnu.org; 30 Aug 2015 12:51:41 +0000 Received: from localhost ([127.0.0.1]:42533 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW25D-0001pR-WF for submit@debbugs.gnu.org; Sun, 30 Aug 2015 08:51:41 -0400 Received: from eggs.gnu.org ([208.118.235.92]:43544) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW25A-0001pG-Bu for submit@debbugs.gnu.org; Sun, 30 Aug 2015 08:51:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZW257-0003dv-A6 for submit@debbugs.gnu.org; Sun, 30 Aug 2015 08:51:35 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:48838) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZW257-0003dr-6h for submit@debbugs.gnu.org; Sun, 30 Aug 2015 08:51:33 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZW254-0001Yn-QA for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 08:51:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZW251-0003dA-UF for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 08:51:30 -0400 Received: from mail-io0-x22d.google.com ([2607:f8b0:4001:c06::22d]:34416) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZW251-0003cy-Mg for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 08:51:27 -0400 Received: by iofe124 with SMTP id e124so68364776iof.1 for ; Sun, 30 Aug 2015 05:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gv2S2cRDhZOePH4g5XFP4KbY6WPQWL/Oa/Ot3oMsvX4=; b=vYb++J3ux+gSq4me9zO/ReNn62k/f3BTp3f90i5svKf7eXDYlzyAVWM/X0+ZrrJSqF QKRa+CHX2u0J6PtJeYXub0dInkGc48a7nnXrWC7/P6OVmCS0VlAOOb+8HKyx3Qq+yqsL 1USv0vW370wUrd5LBm+vIT6nSYbongdTFvjbnQNuOhtG9Pfr0nWqOpVLfhH2Xeg8mJ/v 0doybC/nn+qe5kIqimn/0tjdAz+ZlRcVPuTCiTEHRmV8hBnAFk4GamdldTy8fPOXnL1g U3RUeroa0dCZxslYcTQ08/Go/3nzQ7TmjC+TagRImXKhATQ1ibqjT17FDbYCsEj9bDuW IRyQ== MIME-Version: 1.0 X-Received: by 10.107.47.97 with SMTP id j94mr20915836ioo.136.1440939086746; Sun, 30 Aug 2015 05:51:26 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 05:51:26 -0700 (PDT) Date: Sun, 30 Aug 2015 12:51:26 +0000 Message-ID: Subject: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook From: Pip Cet To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary=001a1144ac34689f02051e86c67d X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --001a1144ac34689f02051e86c67d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It appears it's unsafe to schedule an immediate timer in window-configuration-change-hook: (add-hook 'window-configuration-change-hook (lambda () (run-with-timer 0 nil 'exwm-layout--refresh))) I saw the following segfault: #0 0x0000000000547ec0 in XSETCAR (c=3D0, n=3D51872517) at lisp.h:1188 #1 0x00000000005efdb3 in concat (nargs=3D1, args=3D0x7fffffffd868, target_type=3DLisp_Cons, last_special=3Dfalse) at fns.c:747 #2 0x00000000005ef0f3 in Fcopy_sequence (arg=3D53371635) at fns.c:510 #3 0x0000000000557252 in timer_check () at keyboard.c:4569 #4 0x0000000000639f1b in wait_reading_process_output (time_limit=3D30, nsecs=3D0, read_kbd=3D-1, do_display=3Dtrue, wait_for_cell=3D0, wait_proc= =3D0x0, just_wait_proc=3D0) at process.c:4611 #5 0x00000000004233b2 in sit_for (timeout=3D122, reading=3Dtrue, display_option=3D1) at dispnew.c:5756 #6 0x0000000000553942 in read_char (commandflag=3D1, map=3D53372867, prev_event=3D0, used_mouse_menu=3D0x7fffffffe06f, end_time=3D0x0) at keyboard.c:2775 #7 0x00000000005602ef in read_key_sequence (keybuf=3D0x7fffffffe220, bufsize=3D30, prompt=3D0, dont_downcase_last=3Dfalse, can_return_switch_frame=3Dtrue, fix_current_buffer=3Dtrue, prevent_redisplay=3Dfalse) at keyboard.c:9139 #8 0x00000000005507b1 in command_loop_1 () at keyboard.c:1406 #9 0x00000000005e77e4 in internal_condition_case (bfun=3D0x550386 , handlers=3D18912, hfun=3D0x54fb70 ) at eval.c:= 1293 #10 0x000000000055008d in command_loop_2 (ignore=3D0) at keyboard.c:1138 #11 0x00000000005e6fa6 in internal_catch (tag=3D45264, func=3D0x550064 , arg=3D0) at eval.c:1057 #12 0x000000000055002f in command_loop () at keyboard.c:1117 #13 0x000000000054f738 in recursive_edit_1 () at keyboard.c:723 #14 0x000000000054f8cc in Frecursive_edit () at keyboard.c:794 #15 0x000000000054d706 in main (argc=3D5, argv=3D0x7fffffffe6a8) at emacs.c= :1643 Somehow, the argument to Fcopy_sequence was changed while concat was underway. Further investigation indicates that window-configuration-change-hook was called in the middle of concat: Breakpoint 8, run_window_configuration_change_hook (f=3D0x1718660) at window.c:3141 3141 ptrdiff_t count =3D SPECPDL_INDEX (); #0 run_window_configuration_change_hook (f=3D0x1718660) at window.c:3141 #1 0x0000000000425882 in adjust_frame_size (f=3D0x1718660, new_width=3D824= , new_height=3D516, inhibit=3D5, pretend=3Dfalse, parameter=3D13152) at frame= .c:599 #2 0x0000000000422c01 in change_frame_size_1 (f=3D0x1718660, new_width=3D8= 24, new_height=3D516, pretend=3Dfalse, delay=3Dfalse, safe=3Dfalse, pixelwise= =3Dtrue) at dispnew.c:5507 #3 0x0000000000422c57 in change_frame_size (f=3D0x1718660, new_width=3D824= , new_height=3D516, pretend=3Dfalse, delay=3Dfalse, safe=3Dfalse, pixelwise= =3Dtrue) at dispnew.c:5539 #4 0x0000000000422a2f in do_pending_window_change (safe=3Dfalse) at dispnew.c:5465 #5 0x0000000000536c22 in xg_frame_resized (f=3D0x1718660, pixelwidth=3D842= , pixelheight=3D518) at gtkutil.c:924 #6 0x0000000000518a9f in handle_one_xevent (dpyinfo=3D0x15b07d0, event=3D0x7fffffff7210, finish=3D0xbfaacc, hold_quit=3D0x7fffffff74a0) at xterm.c:8294 #7 0x0000000000516a69 in event_handler_gdk (gxev=3D0x7fffffff7210, ev=3D0x568b410, data=3D0x0) at xterm.c:7294 #8 0x00007ffff6769661 in gdk_event_apply_filters (xevent=3Dxevent@entry=3D0x7fffffff7210, event=3Devent@entry=3D0x568b410, window=3Dwindow@entry=3D0x0) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/x11/gdkeventsource.c:81 #9 0x00007ffff6769929 in gdk_event_source_translate_event (xevent=3D0x7fffffff7210, event_source=3D0x14e4090) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/x11/gdkeventsource.c:195 #10 _gdk_x11_display_queue_events (display=3D0x1506050) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/x11/gdkeventsource.c:338 #11 0x00007ffff673cae9 in gdk_display_get_event (display=3Ddisplay@entry=3D0x1506050) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/gdkdisplay.c:340 #12 0x00007ffff67696e2 in gdk_event_source_dispatch (source=3D, callback=3D, user_data=3D) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/x11/gdkeventsource.c:360 #13 0x00007ffff50bac3d in g_main_dispatch (context=3D0x14f1f80) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3122 #14 g_main_context_dispatch (context=3Dcontext@entry=3D0x14f1f80) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3737 #15 0x00007ffff50baf20 in g_main_context_iterate (context=3Dcontext@entry=3D0x14f1f80, block=3Dblock@entry=3D1, dispatch=3Ddispatch@entry=3D1, self=3D) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3808 #16 0x00007ffff50bafcc in g_main_context_iteration (context=3D0x14f1f80, context@entry=3D0x0, may_block=3Dmay_block@entry=3D1) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3869 #17 0x00007ffff6be1ff5 in gtk_main_iteration () at /tmp/buildd/gtk+3.0-3.16.6/./gtk/gtkmain.c:1320 #18 0x0000000000519220 in XTread_socket (terminal=3D0x11ecdd0, hold_quit=3D0x7fffffff74a0) at xterm.c:8644 #19 0x000000000055bbe2 in gobble_input () at keyboard.c:6893 #20 0x000000000055bfcc in handle_async_input () at keyboard.c:7145 #21 0x000000000055bfeb in process_pending_signals () at keyboard.c:7159 #22 0x00000000005c3d3a in Fmake_list (length=3D0, init=3D0) at alloc.c:2676 #23 0x00000000005ef6f8 in concat (nargs=3D1, args=3D0x7fffffff76e8, target_type=3DLisp_Cons, last_special=3Dfalse) at fns.c:642 #24 0x00000000005ef0f3 in Fcopy_sequence (arg=3D49369891) at fns.c:510 #25 0x0000000000557252 in timer_check () at keyboard.c:4569 #26 0x0000000000555106 in readable_events (flags=3D1) at keyboard.c:3422 #27 0x000000000055ba2b in get_input_pending (flags=3D1) at keyboard.c:6808 #28 0x0000000000556a49 in swallow_events (do_display=3Dfalse) at keyboard.c:4320 #29 0x000000000063af9c in wait_reading_process_output (time_limit=3D1, nsecs=3D0, read_kbd=3D0, do_display=3Dfalse, wait_for_cell=3D0, wait_proc=3D0x2fd6078, just_wait_proc=3D0) at process.c:4992 #30 0x0000000000638f6c in Faccept_process_output (process=3D50159736, seconds=3D6, millisec=3D0, just_this_one=3D0) at process.c:4241 I'm not sure whether the bug is in my code (and, if so, how to fix it=E2=80=94if scheduling an immediate timer isn't safe, what could possibly be?), in Fmake_list, in QUIT, or in the X or GTK code, but at least one of them is buggy. M-x report-emacs-bug information: I have been unable, so far, to reproduce this bug reliably from `emacs -Q'. In GNU Emacs 25.0.50.52 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6) of 2015-08-30 Repository revision: c6af816affb36d512f806725518e6e5f2353b197 Windowing system distributor `The X.Org Foundation', version 11.0.11702000 System Description: Debian GNU/Linux unstable (sid) Configured using: `configure 'CFLAGS=3D-O0 -g3'' Configured features: XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GCONF GSETTINGS NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Text Minor modes in effect: diff-auto-refine-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort gnus-util mail-extr emacsbug message dired format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode cl-loaddefs pcase cl-lib mail-prsvr mail-utils vc-git diff-mode easymenu easy-mmode time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote dbusbind inotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 84908 4447) (symbols 48 19432 0) (miscs 40 43 147) (strings 32 14795 4332) (string-bytes 1 417071) (vectors 16 11731) (vector-slots 8 419664 4375) (floats 8 138 302) (intervals 56 225 13) (buffers 976 12) (heap 1024 19426 1811)) --001a1144ac34689f02051e86c67d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It appears it's unsafe to schedule an immediate timer = in
window-configuration-change-hook:

=C2=A0 (add-hook 'window= -configuration-change-hook (lambda () (run-with-timer
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 0 nil 'exwm-layout--refresh)))

I saw th= e following segfault:
#0=C2=A0 0x0000000000547ec0 in XSETCAR (c=3D0, n= =3D51872517) at lisp.h:1188
#1=C2=A0 0x00000000005efdb3 in concat (nargs= =3D1, args=3D0x7fffffffd868, target_type=3DLisp_Cons, last_special=3Dfalse)= at fns.c:747
#2=C2=A0 0x00000000005ef0f3 in Fcopy_sequence (arg=3D53371= 635) at fns.c:510
#3=C2=A0 0x0000000000557252 in timer_check () at keybo= ard.c:4569
#4=C2=A0 0x0000000000639f1b in wait_reading_process_output (t= ime_limit=3D30, nsecs=3D0, read_kbd=3D-1, do_display=3Dtrue, wait_for_cell= =3D0, wait_proc=3D0x0, just_wait_proc=3D0) at process.c:4611
#5=C2=A0 0x= 00000000004233b2 in sit_for (timeout=3D122, reading=3Dtrue, display_option= =3D1) at dispnew.c:5756
#6=C2=A0 0x0000000000553942 in read_char (comman= dflag=3D1, map=3D53372867, prev_event=3D0, used_mouse_menu=3D0x7fffffffe06f= , end_time=3D0x0) at keyboard.c:2775
#7=C2=A0 0x00000000005602ef in read= _key_sequence (keybuf=3D0x7fffffffe220, bufsize=3D30, prompt=3D0, dont_down= case_last=3Dfalse, can_return_switch_frame=3Dtrue, fix_current_buffer=3Dtru= e, prevent_redisplay=3Dfalse) at keyboard.c:9139
#8=C2=A0 0x000000000055= 07b1 in command_loop_1 () at keyboard.c:1406
#9=C2=A0 0x00000000005e77e4= in internal_condition_case (bfun=3D0x550386 <command_loop_1>, handle= rs=3D18912, hfun=3D0x54fb70 <cmd_error>) at eval.c:1293
#10 0x0000= 00000055008d in command_loop_2 (ignore=3D0) at keyboard.c:1138
#11 0x000= 00000005e6fa6 in internal_catch (tag=3D45264, func=3D0x550064 <command_l= oop_2>, arg=3D0) at eval.c:1057
#12 0x000000000055002f in command_loo= p () at keyboard.c:1117
#13 0x000000000054f738 in recursive_edit_1 () at= keyboard.c:723
#14 0x000000000054f8cc in Frecursive_edit () at keyboard= .c:794
#15 0x000000000054d706 in main (argc=3D5, argv=3D0x7fffffffe6a8) = at emacs.c:1643

Somehow, the argument to Fcopy_sequence was changed = while concat was
underway. Further investigation indicates that
windo= w-configuration-change-hook was called in the middle of concat:

Brea= kpoint 8, run_window_configuration_change_hook (f=3D0x1718660) at window.c:= 3141
3141=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ptrdiff_t count =3D SPECPDL_INDE= X ();
#0=C2=A0 run_window_configuration_change_hook (f=3D0x1718660) at w= indow.c:3141
#1=C2=A0 0x0000000000425882 in adjust_frame_size (f=3D0x171= 8660, new_width=3D824, new_height=3D516, inhibit=3D5, pretend=3Dfalse, para= meter=3D13152) at frame.c:599
#2=C2=A0 0x0000000000422c01 in change_fram= e_size_1 (f=3D0x1718660, new_width=3D824, new_height=3D516, pretend=3Dfalse= , delay=3Dfalse, safe=3Dfalse, pixelwise=3Dtrue) at dispnew.c:5507
#3=C2= =A0 0x0000000000422c57 in change_frame_size (f=3D0x1718660, new_width=3D824= , new_height=3D516, pretend=3Dfalse, delay=3Dfalse, safe=3Dfalse, pixelwise= =3Dtrue) at dispnew.c:5539
#4=C2=A0 0x0000000000422a2f in do_pending_win= dow_change (safe=3Dfalse) at dispnew.c:5465
#5=C2=A0 0x0000000000536c22 = in xg_frame_resized (f=3D0x1718660, pixelwidth=3D842, pixelheight=3D518) at= gtkutil.c:924
#6=C2=A0 0x0000000000518a9f in handle_one_xevent (dpyinfo= =3D0x15b07d0, event=3D0x7fffffff7210, finish=3D0xbfaacc, hold_quit=3D0x7fff= ffff74a0) at xterm.c:8294
#7=C2=A0 0x0000000000516a69 in event_handler_g= dk (gxev=3D0x7fffffff7210, ev=3D0x568b410, data=3D0x0) at xterm.c:7294
#= 8=C2=A0 0x00007ffff6769661 in gdk_event_apply_filters (xevent=3Dxevent@entr= y=3D0x7fffffff7210, event=3Devent@entry=3D0x568b410, window=3Dwindow@entry= =3D0x0) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/x11/gdkeventsource.c:81
#9= =C2=A0 0x00007ffff6769929 in gdk_event_source_translate_event (xevent=3D0x7= fffffff7210, event_source=3D0x14e4090) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/= x11/gdkeventsource.c:195
#10 _gdk_x11_display_queue_events (display=3D0x= 1506050) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/x11/gdkeventsource.c:338
#1= 1 0x00007ffff673cae9 in gdk_display_get_event (display=3Ddisplay@entry=3D0x= 1506050) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/gdkdisplay.c:340
#12 0x0000= 7ffff67696e2 in gdk_event_source_dispatch (source=3D<optimized out>, = callback=3D<optimized out>, user_data=3D<optimized out>) at /tm= p/buildd/gtk+3.0-3.16.6/./gdk/x11/gdkeventsource.c:360
#13 0x00007ffff50= bac3d in g_main_dispatch (context=3D0x14f1f80) at /tmp/buildd/glib2.0-2.44.= 1/./glib/gmain.c:3122
#14 g_main_context_dispatch (context=3Dcontext@ent= ry=3D0x14f1f80) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3737
#15 0x= 00007ffff50baf20 in g_main_context_iterate (context=3Dcontext@entry=3D0x14f= 1f80, block=3Dblock@entry=3D1, dispatch=3Ddispatch@entry=3D1, self=3D<op= timized out>) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3808
#16 0= x00007ffff50bafcc in g_main_context_iteration (context=3D0x14f1f80, context= @entry=3D0x0, may_block=3Dmay_block@entry=3D1) at /tmp/buildd/glib2.0-2.44.= 1/./glib/gmain.c:3869
#17 0x00007ffff6be1ff5 in gtk_main_iteration () at= /tmp/buildd/gtk+3.0-3.16.6/./gtk/gtkmain.c:1320
#18 0x0000000000519220 = in XTread_socket (terminal=3D0x11ecdd0, hold_quit=3D0x7fffffff74a0) at xter= m.c:8644
#19 0x000000000055bbe2 in gobble_input () at keyboard.c:6893#20 0x000000000055bfcc in handle_async_input () at keyboard.c:7145
#21 = 0x000000000055bfeb in process_pending_signals () at keyboard.c:7159
#22 = 0x00000000005c3d3a in Fmake_list (length=3D0, init=3D0) at alloc.c:2676
= #23 0x00000000005ef6f8 in concat (nargs=3D1, args=3D0x7fffffff76e8, target_= type=3DLisp_Cons, last_special=3Dfalse) at fns.c:642
#24 0x00000000005ef= 0f3 in Fcopy_sequence (arg=3D49369891) at fns.c:510
#25 0x00000000005572= 52 in timer_check () at keyboard.c:4569
#26 0x0000000000555106 in readab= le_events (flags=3D1) at keyboard.c:3422
#27 0x000000000055ba2b in get_i= nput_pending (flags=3D1) at keyboard.c:6808
#28 0x0000000000556a49 in sw= allow_events (do_display=3Dfalse) at keyboard.c:4320
#29 0x000000000063a= f9c in wait_reading_process_output (time_limit=3D1, nsecs=3D0, read_kbd=3D0= , do_display=3Dfalse, wait_for_cell=3D0, wait_proc=3D0x2fd6078, just_wait_p= roc=3D0) at process.c:4992
#30 0x0000000000638f6c in Faccept_process_out= put (process=3D50159736, seconds=3D6, millisec=3D0, just_this_one=3D0) at p= rocess.c:4241

I'm not sure whether the bug is in my code (and, i= f so, how to fix
it=E2=80=94if scheduling an immediate timer isn't s= afe, what could possibly
be?), in Fmake_list, in QUIT, or in the X or GT= K code, but at least
one of them is buggy.

M-x report-emacs-bug i= nformation:

I have been unable, so far, to reproduce this bug reliab= ly from `emacs
-Q'.

In GNU Emacs 25.0.50.52 (x86_64-unknown-l= inux-gnu, GTK+ Version 3.16.6)
=C2=A0of 2015-08-30
Repository revisio= n: c6af816affb36d512f806725518e6e5f2353b197
Windowing system distributor= `The X.Org Foundation', version 11.0.11702000
System Description:= =C2=A0=C2=A0=C2=A0 Debian GNU/Linux unstable (sid)

Configured using:=
=C2=A0`configure 'CFLAGS=3D-O0 -g3''

Configured feat= ures:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GCONF GSETTINGS NOTIFY LIBSE= LINUX
GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11
<= br>Important settings:
=C2=A0 value of $LANG: en_US.UTF-8
=C2=A0 loca= le-coding-system: utf-8-unix

Major mode: Text

Minor modes in = effect:
=C2=A0 diff-auto-refine-mode: t
=C2=A0 tooltip-mode: t
=C2= =A0 global-eldoc-mode: t
=C2=A0 electric-indent-mode: t
=C2=A0 mouse-= wheel-mode: t
=C2=A0 tool-bar-mode: t
=C2=A0 menu-bar-mode: t
=C2= =A0 file-name-shadow-mode: t
=C2=A0 global-font-lock-mode: t
=C2=A0 f= ont-lock-mode: t
=C2=A0 blink-cursor-mode: t
=C2=A0 auto-composition-= mode: t
=C2=A0 auto-encryption-mode: t
=C2=A0 auto-compression-mode: = t
=C2=A0 line-number-mode: t
=C2=A0 transient-mark-mode: t

Loa= d-path shadows:
None found.

Features:
(shadow sort gnus-util m= ail-extr emacsbug message dired format-spec
rfc822 mml mml-sec mm-decode= mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader = sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns help-mode cl-loadde= fs pcase cl-lib mail-prsvr
mail-utils vc-git diff-mode easymenu easy-mmo= de time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hoo= ks lisp-float-type
mwheel x-win term/common-win x-dnd tool-bar dnd fonts= et image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mod= e prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar m= ouse jit-lock
font-lock syntax facemenu font-core frame cl-generic cham = georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korea= n
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european<= br>ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-c= mpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs but= ton faces cus-face macroexp files text-properties overlay
sha1 md5 base6= 4 format env code-pages mule custom widget
hashtable-print-readable back= quote dbusbind inotify dynamic-setting
system-font-setting font-render-s= etting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs= )

Memory information:
((conses 16 84908 4447)
=C2=A0(symbols 4= 8 19432 0)
=C2=A0(miscs 40 43 147)
=C2=A0(strings 32 14795 4332)
= =C2=A0(string-bytes 1 417071)
=C2=A0(vectors 16 11731)
=C2=A0(vector-= slots 8 419664 4375)
=C2=A0(floats 8 138 302)
=C2=A0(intervals 56 225= 13)
=C2=A0(buffers 976 12)
=C2=A0(heap 1024 19426 1811))

--001a1144ac34689f02051e86c67d-- From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 30 11:01:50 2015 Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 15:01:50 +0000 Received: from localhost ([127.0.0.1]:42838 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW47B-00061H-HR for submit@debbugs.gnu.org; Sun, 30 Aug 2015 11:01:49 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:58363) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW477-000617-1i for 21380@debbugs.gnu.org; Sun, 30 Aug 2015 11:01:47 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NTW00B00HJO4W00@mtaout28.012.net.il> for 21380@debbugs.gnu.org; Sun, 30 Aug 2015 18:01:20 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTW0054THQ84Z70@mtaout28.012.net.il>; Sun, 30 Aug 2015 18:01:20 +0300 (IDT) Date: Sun, 30 Aug 2015 18:01:37 +0300 From: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet Message-id: <83mvx8252m.fsf@gnu.org> References: X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 30 Aug 2015 12:51:26 +0000 > From: Pip Cet > > It appears it's unsafe to schedule an immediate timer in > window-configuration-change-hook: > > (add-hook 'window-configuration-change-hook (lambda () (run-with-timer > 0 nil 'exwm-layout--refresh))) > > I saw the following segfault: > #0 0x0000000000547ec0 in XSETCAR (c=0, n=51872517) at lisp.h:1188 > #1 0x00000000005efdb3 in concat (nargs=1, args=0x7fffffffd868, > target_type=Lisp_Cons, last_special=false) at fns.c:747 > #2 0x00000000005ef0f3 in Fcopy_sequence (arg=53371635) at fns.c:510 > #3 0x0000000000557252 in timer_check () at keyboard.c:4569 > #4 0x0000000000639f1b in wait_reading_process_output (time_limit=30, nsecs=0, > read_kbd=-1, do_display=true, wait_for_cell=0, wait_proc=0x0, just_wait_proc=0) > at process.c:4611 > #5 0x00000000004233b2 in sit_for (timeout=122, reading=true, display_option=1) > at dispnew.c:5756 > #6 0x0000000000553942 in read_char (commandflag=1, map=53372867, prev_event=0, > used_mouse_menu=0x7fffffffe06f, end_time=0x0) at keyboard.c:2775 > #7 0x00000000005602ef in read_key_sequence (keybuf=0x7fffffffe220, bufsize=30, > prompt=0, dont_downcase_last=false, can_return_switch_frame=true, > fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9139 > #8 0x00000000005507b1 in command_loop_1 () at keyboard.c:1406 > #9 0x00000000005e77e4 in internal_condition_case (bfun=0x550386 > , handlers=18912, hfun=0x54fb70 ) at eval.c:1293 > #10 0x000000000055008d in command_loop_2 (ignore=0) at keyboard.c:1138 > #11 0x00000000005e6fa6 in internal_catch (tag=45264, func=0x550064 > , arg=0) at eval.c:1057 > #12 0x000000000055002f in command_loop () at keyboard.c:1117 > #13 0x000000000054f738 in recursive_edit_1 () at keyboard.c:723 > #14 0x000000000054f8cc in Frecursive_edit () at keyboard.c:794 > #15 0x000000000054d706 in main (argc=5, argv=0x7fffffffe6a8) at emacs.c:1643 > > Somehow, the argument to Fcopy_sequence was changed while concat was > underway. How do you see that? > Further investigation indicates that > window-configuration-change-hook was called in the middle of concat: Did you understand how this fact is related to the segfault? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 30 11:24:29 2015 Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 15:24:29 +0000 Received: from localhost ([127.0.0.1]:42850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW4T6-0006XZ-JN for submit@debbugs.gnu.org; Sun, 30 Aug 2015 11:24:28 -0400 Received: from mail-io0-f175.google.com ([209.85.223.175]:35260) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW4T4-0006XR-Uv for 21380@debbugs.gnu.org; Sun, 30 Aug 2015 11:24:27 -0400 Received: by iog7 with SMTP id 7so12205692iog.2 for <21380@debbugs.gnu.org>; Sun, 30 Aug 2015 08:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R3SFLx8lysYurQ900+tNl6dLusYOdzBYnPV3H76Djew=; b=tKWhBla+3QfoPmGlrW3qXnS7ZsPPhy0aBLVXvwr0N5UKc+zdjnndO1cLPcFvrUrGUO +2H8VSKts6LV5fDUdRImB93tNi/dSLsaBbpqWs+oW3tjKmXIpCa34Xh5z67ogAYYAUKX eIQSCpR8FQHaNiKCbgAMMfFnrc16gnScYEOPc5vPCj3iZh7Ye2+f23D4mPi2jpM9ebuW +P0ZVREiO5M19jSSRDHzvqhyrc5n2ZD0M/c4NfcXBR8KCxElfjcXKiLHvf+YITPiIyJa YicYo94FbBAT5J2GvzvKzaROnGASd/vlSqjG830dAvEl5raglJudILd+4eHXqUUCMLZN s5rQ== MIME-Version: 1.0 X-Received: by 10.107.47.97 with SMTP id j94mr21375441ioo.136.1440948266140; Sun, 30 Aug 2015 08:24:26 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 08:24:26 -0700 (PDT) In-Reply-To: <83mvx8252m.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> Date: Sun, 30 Aug 2015 15:24:26 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook From: Pip Cet To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a1144ac348b0ffa051e88e9e2 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a1144ac348b0ffa051e88e9e2 Content-Type: text/plain; charset=UTF-8 On Sun, Aug 30, 2015 at 3:01 PM, Eli Zaretskii wrote: > > Date: Sun, 30 Aug 2015 12:51:26 +0000 > > From: Pip Cet > > Somehow, the argument to Fcopy_sequence was changed while concat was > > underway. > > How do you see that? > I originally concluded it was the only way to trigger the bug, but I just managed to trigger it again and have it open in a GDB session: #1 0x00000000005efdb3 in concat (nargs=1, args=0x7fffffff76e8, target_type=Lisp_Cons, last_special=false) at fns.c:747 747 XSETCAR (tail, elt); (gdb) p result_len $22 = 4 (gdb) p debug_print(Flength(args[0])) 5 $23 = void (gdb) > > Further investigation indicates that > > window-configuration-change-hook was called in the middle of concat: > > Did you understand how this fact is related to the segfault? > I _think_ I do. 1. concat called with args[0] == Vtimer_list 2. concat stores result_len (=4) 3. concat calls make_list (4) 4. make_list interrupted by QUIT 5. see stack trace 6. window-configuration-change-hook modifies Vtimer_list, which now has length 5 7. control returns to concat 8. concat tries to write 5 elements into a 4-element list, which causes the segfault because `tail' is unexpectedly NULL. Does that make sense to you? Thanks, Pip --001a1144ac348b0ffa051e88e9e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Aug 30, 2015 at 3:01 PM, Eli Zaretskii <eliz@gnu.org>= wrote:
> Date: Sun= , 30 Aug 2015 12:51:26 +0000
> From: Pip Cet <pipcet@gmail.com= >
> Somehow, the argument to Fcopy_sequence was changed while concat was > underway.

How do you see that?

I originally concl= uded it was the only way to trigger the bug, but I just managed to trigger = it again and have it open in a GDB session:

#1= =C2=A0 0x00000000005efdb3 in concat (nargs=3D1, args=3D0x7fffffff76e8, targ= et_type=3DLisp_Cons, last_special=3Dfalse) at fns.c:747
747=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 XSETCAR (tail, elt);
(gdb) p result_le= n
$22 =3D 4
(gdb) p debug_print(Flength(args[0]))
5
$23 =3D voi= d
(gdb)
=C2=A0
> Further investigation indicates that
> window-configuration-change-hook was called in the middle of concat:
Did you understand how this fact is related to the segfault?

I _think_ I do.

1. conca= t called with args[0] =3D=3D Vtimer_list
2. concat stores res= ult_len (=3D4)
3. concat calls make_list (4)
4.= make_list interrupted by QUIT
5. see stack trace
6. window-configuration-change-hook modifies Vtimer_list, which now has = length 5
7. control returns to concat
8. concat= tries to write 5 elements into a 4-element list, which causes the segfault= because `tail' is unexpectedly NULL.

Does= that make sense to you?

Thanks,
Pip
--001a1144ac348b0ffa051e88e9e2-- From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 30 11:27:41 2015 Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 15:27:42 +0000 Received: from localhost ([127.0.0.1]:42854 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW4WD-0006cC-AD for submit@debbugs.gnu.org; Sun, 30 Aug 2015 11:27:41 -0400 Received: from mail-ig0-f180.google.com ([209.85.213.180]:34550) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW4WB-0006c4-3h for 21380@debbugs.gnu.org; Sun, 30 Aug 2015 11:27:39 -0400 Received: by igui7 with SMTP id i7so42650374igu.1 for <21380@debbugs.gnu.org>; Sun, 30 Aug 2015 08:27:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FgO7+UWSEoOq3UPtoAnHSbzwODGunTW3OV6/eMBqlFY=; b=hFDZjxBY6upjL29imHdT4NTqqROZy8KAxMU05FAmkp09hP7gw6QzqwEh+91F8ExqQO FjHULoKgR6o/PdsEiM2t3WpQQeRIBpd/DSUxOIFnURmgN8x9aWlGlLWmFC+6upGWInba jqxSBDZP1vbeDKoA11r2E72iugNNjuRKjnWU9fm8/OHKvxNjgqZbT+yWU4zkQ8oReKAI gUnltS6KbOPYycJqJq3dAJBCrKzyT+w/SUK4Bj8y0s6dabCxi63DPVDhSsa0ZLEsMjqm +NRDe7I96ke658D+bskuZ/uCUH32wIgw+dlALd/J86vp+XMVeCTajZc4N/JjmaDbYItV TnzQ== MIME-Version: 1.0 X-Received: by 10.50.112.227 with SMTP id it3mr11233151igb.93.1440948458490; Sun, 30 Aug 2015 08:27:38 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 08:27:38 -0700 (PDT) In-Reply-To: References: <83mvx8252m.fsf@gnu.org> Date: Sun, 30 Aug 2015 15:27:38 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook From: Pip Cet To: Eli Zaretskii Content-Type: multipart/alternative; boundary=089e0102f83e0213e2051e88f582 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e0102f83e0213e2051e88f582 Content-Type: text/plain; charset=UTF-8 I forgot to make clear that I verified with gdb that args[0] == Vtimer_list. And if there's anything else you would like me to debug, please let me know. It's very unfortunate I can't reproduce it with emacs -Q and I realize that makes it impossible for you to deal with this bug except through information I provide. Thanks for trying anyway, Pip On Sun, Aug 30, 2015 at 3:24 PM, Pip Cet wrote: > > > On Sun, Aug 30, 2015 at 3:01 PM, Eli Zaretskii wrote: > >> > Date: Sun, 30 Aug 2015 12:51:26 +0000 >> > From: Pip Cet >> > Somehow, the argument to Fcopy_sequence was changed while concat was >> > underway. >> >> How do you see that? >> > > I originally concluded it was the only way to trigger the bug, but I just > managed to trigger it again and have it open in a GDB session: > > #1 0x00000000005efdb3 in concat (nargs=1, args=0x7fffffff76e8, > target_type=Lisp_Cons, last_special=false) at fns.c:747 > 747 XSETCAR (tail, elt); > (gdb) p result_len > $22 = 4 > (gdb) p debug_print(Flength(args[0])) > 5 > $23 = void > (gdb) > > >> > Further investigation indicates that >> > window-configuration-change-hook was called in the middle of concat: >> >> Did you understand how this fact is related to the segfault? >> > > I _think_ I do. > > 1. concat called with args[0] == Vtimer_list > 2. concat stores result_len (=4) > 3. concat calls make_list (4) > 4. make_list interrupted by QUIT > 5. see stack trace > 6. window-configuration-change-hook modifies Vtimer_list, which now has > length 5 > 7. control returns to concat > 8. concat tries to write 5 elements into a 4-element list, which causes > the segfault because `tail' is unexpectedly NULL. > > Does that make sense to you? > > Thanks, > Pip > --089e0102f83e0213e2051e88f582 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I forgot to make clear that I verified with gdb = that args[0] =3D=3D Vtimer_list. And if there's anything else you would= like me to debug, please let me know. It's very unfortunate I can'= t reproduce it with emacs -Q and I realize that makes it impossible for you= to deal with this bug except through information I provide.

T= hanks for trying anyway,
Pip
<= br>
On Sun, Aug 30, 2015 at 3:24 PM, Pip Cet <pip= cet@gmail.com> wrote:


<= span class=3D"">On Sun, Aug 30, 2015 at 3:01 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Date: Sun, 30 Aug 2015 12:51:26 +0000
> From: Pip Cet <pipcet@gmail.com>
> Somehow, the argument to Fcopy_sequence was changed while concat was > underway.

How do you see that?

I originall= y concluded it was the only way to trigger the bug, but I just managed to t= rigger it again and have it open in a GDB session:

=
#1=C2=A0 0x00000000005efdb3 in concat (nargs=3D1, args=3D0x7fffffff76e= 8, target_type=3DLisp_Cons, last_special=3Dfalse) at fns.c:747
747=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 XSETCAR (tail, elt);
(gdb) p res= ult_len
$22 =3D 4
(gdb) p debug_print(Flength(args[0]))
5
$23 = =3D void
(gdb)
=C2=A0
> Further investigation indicates that
> window-configuration-change-hook was called in the middle of concat:
Did you understand how this fact is related to the segfault?

I _think_ I do.

1= . concat called with args[0] =3D=3D Vtimer_list
2. concat sto= res result_len (=3D4)
3. concat calls make_list (4)
=
4. make_list interrupted by QUIT
5. see stack trace
<= /div>
6. window-configuration-change-hook modifies Vtimer_list, which n= ow has length 5
7. control returns to concat
8.= concat tries to write 5 elements into a 4-element list, which causes the s= egfault because `tail' is unexpectedly NULL.

Does that make sense to you?

Thanks,
Pip=

--089e0102f83e0213e2051e88f582-- From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 30 12:25:00 2015 Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 16:25:00 +0000 Received: from localhost ([127.0.0.1]:42885 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW5Pf-0007up-5g for submit@debbugs.gnu.org; Sun, 30 Aug 2015 12:24:59 -0400 Received: from mail-io0-f181.google.com ([209.85.223.181]:36732) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW5Pc-0007ud-7m for 21380@debbugs.gnu.org; Sun, 30 Aug 2015 12:24:57 -0400 Received: by iod35 with SMTP id 35so6636349iod.3 for <21380@debbugs.gnu.org>; Sun, 30 Aug 2015 09:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5Zg6HP1gweiQ3HDhGDtCA4dB0UlQD3SyeDixI+5i0Zk=; b=lGn4CFK1puDMlkeq23+W4Brkb5APNaIgABerDtKNRlh6o2uGAd8pKZNICId4G6CGZb hq/FxPbvR4zBUFtu3bKsmrWLDd2EeT6bK+CctVRz7qaHj21krslvZWQMJT9DPjXknYN7 rYNV2vUAv7U2dM/DPGDB9j7NdKfnRyGRTvybKRcbXUOTYpJzuwnwlaEfN/zixm1MTBPb UpT2t5qrUUAqelpQMWXUlR7wQPZ8l9E7UCPZHuGKQzr+Xt4kn9SfDmQ/VgxQGsj3g6I5 oenKE0VtRwKcGJEbtGAG5mlt8zJXeys+57m4MIwd0VvfCu2Ort8P/jrhn5ZagSWijf45 y72g== MIME-Version: 1.0 X-Received: by 10.107.47.97 with SMTP id j94mr21528385ioo.136.1440951895712; Sun, 30 Aug 2015 09:24:55 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 09:24:55 -0700 (PDT) In-Reply-To: References: <83mvx8252m.fsf@gnu.org> Date: Sun, 30 Aug 2015 16:24:55 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook From: Pip Cet To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a1144ac34e1e77f051e89c12a X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org, rudalics@gmx.at X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a1144ac34e1e77f051e89c12a Content-Type: text/plain; charset=UTF-8 I think the problem is the call to do_pending_window_change in xg_frame_resized in gtkutil.c: the commit message (commit 3477e27021db) says: Author: Martin Rudalics AuthorDate: Sun Jul 27 15:21:30 2014 +0200 Commit: Martin Rudalics CommitDate: Sun Jul 27 15:21:30 2014 +0200 Complete pixelwise frame/window resizing, add horizontal scrollbar support. [...] * gtkutil.c (xg_frame_resized): Don't call do_pending_window_change. but the diff is: @@ -883,6 +884,8 @@ xg_frame_resized (struct frame *f, int pixelwidth, int pixelheight) change_frame_size (f, width, height, 0, 1, 0, 1); SET_FRAME_GARBAGED (f); cancel_mouse_face (f); + + do_pending_window_change (0); } } And my current understanding is this bug would not occur if that call were removed. The same issue applies to the change to x_set_window_size, but I'm not certain about removing either call. On Sun, Aug 30, 2015 at 3:27 PM, Pip Cet wrote: > I forgot to make clear that I verified with gdb that args[0] == > Vtimer_list. And if there's anything else you would like me to debug, > please let me know. It's very unfortunate I can't reproduce it with emacs > -Q and I realize that makes it impossible for you to deal with this bug > except through information I provide. > > Thanks for trying anyway, > Pip > > On Sun, Aug 30, 2015 at 3:24 PM, Pip Cet wrote: > >> >> >> On Sun, Aug 30, 2015 at 3:01 PM, Eli Zaretskii wrote: >> >>> > Date: Sun, 30 Aug 2015 12:51:26 +0000 >>> > From: Pip Cet >>> > Somehow, the argument to Fcopy_sequence was changed while concat was >>> > underway. >>> >>> How do you see that? >>> >> >> I originally concluded it was the only way to trigger the bug, but I just >> managed to trigger it again and have it open in a GDB session: >> >> #1 0x00000000005efdb3 in concat (nargs=1, args=0x7fffffff76e8, >> target_type=Lisp_Cons, last_special=false) at fns.c:747 >> 747 XSETCAR (tail, elt); >> (gdb) p result_len >> $22 = 4 >> (gdb) p debug_print(Flength(args[0])) >> 5 >> $23 = void >> (gdb) >> >> >>> > Further investigation indicates that >>> > window-configuration-change-hook was called in the middle of concat: >>> >>> Did you understand how this fact is related to the segfault? >>> >> >> I _think_ I do. >> >> 1. concat called with args[0] == Vtimer_list >> 2. concat stores result_len (=4) >> 3. concat calls make_list (4) >> 4. make_list interrupted by QUIT >> 5. see stack trace >> 6. window-configuration-change-hook modifies Vtimer_list, which now has >> length 5 >> 7. control returns to concat >> 8. concat tries to write 5 elements into a 4-element list, which causes >> the segfault because `tail' is unexpectedly NULL. >> >> Does that make sense to you? >> >> Thanks, >> Pip >> > > --001a1144ac34e1e77f051e89c12a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the problem is the call to do_pending_wi= ndow_change in xg_frame_resized in gtkutil.c: the commit message (commit 34= 77e27021db) says:

Author:=C2=A0=C2=A0=C2=A0=C2=A0 Martin Rudalics &l= t;rudalics@gmx.at&= gt;
AuthorDate: Sun Jul 27 15:21:30 2014 +0200
Commit:=C2=A0=C2=A0=C2= =A0=C2=A0 Martin Rudalics <rudalics@gmx.at>
CommitDate: Sun Jul 27 15:21:30 2014 +02= 00

=C2=A0=C2=A0=C2=A0 Complete pixelwise frame/window resizing, add = horizontal scrollbar support.
=C2=A0=C2=A0=C2=A0 [...]
=C2=A0=C2=A0= =C2=A0 * gtkutil.c (xg_frame_resized): Don't call
=C2=A0=C2=A0=C2=A0= do_pending_window_change.

but the diff is:

@@ -883,6 += 884,8 @@ xg_frame_resized (struct frame *f, int pixelwidth, int pixelheight= )
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 change_frame_size (f, width, heig= ht, 0, 1, 0, 1);
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SET_FRAME_GARBAGED= (f);
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cancel_mouse_face (f);
++=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 do_pending_window_change (0);
=C2=A0= =C2=A0=C2=A0=C2=A0 }
=C2=A0}

And my current= understanding is this bug would not occur if that call were removed. The s= ame issue applies to the change to x_set_window_size, but I'm not certa= in about removing either call.
On Sun, Aug 30, 2015 at 3:27 PM, Pip Cet <pipc= et@gmail.com> wrote:
I forgot to make clear that I verified with gdb that a= rgs[0] =3D=3D Vtimer_list. And if there's anything else you would like = me to debug, please let me know. It's very unfortunate I can't repr= oduce it with emacs -Q and I realize that makes it impossible for you to de= al with this bug except through information I provide.

Thanks = for trying anyway,
Pip

On Sun, A= ug 30, 2015 at 3:24 PM, Pip Cet <pipcet@gmail.com> wrote:
=


On Sun, Aug 30, 2015 at 3:01 PM, E= li Zaretskii <eliz@gnu.org> wrote:
> Date: Sun, 30 Aug 2015 12:51:26= +0000
> From: Pip Cet <pipcet@gmail.com>
 > Somehow, the argument to Fcopy_sequence was changed while concat was > underway.

How do you see that?

I originall= y concluded it was the only way to trigger the bug, but I just managed to t= rigger it again and have it open in a GDB session:

=
#1=C2=A0 0x00000000005efdb3 in concat (nargs=3D1, args=3D0x7fffffff76e= 8, target_type=3DLisp_Cons, last_special=3Dfalse) at fns.c:747
747=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 XSETCAR (tail, elt);
(gdb) p res= ult_len
$22 =3D 4
(gdb) p debug_print(Flength(args[0]))
5
$23 = =3D void
(gdb)
=C2=A0
> Further investigation indicates that
> window-configuration-change-hook was called in the middle of concat:
Did you understand how this fact is related to the segfault?

I _think_ I do.

1= . concat called with args[0] =3D=3D Vtimer_list
2. concat sto= res result_len (=3D4)
3. concat calls make_list (4)
=
4. make_list interrupted by QUIT
5. see stack trace
<= /div>
6. window-configuration-change-hook modifies Vtimer_list, which n= ow has length 5
7. control returns to concat
8.= concat tries to write 5 elements into a 4-element list, which causes the s= egfault because `tail' is unexpectedly NULL.

Does that make sense to you?

Thanks,
Pip=


--001a1144ac34e1e77f051e89c12a-- From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 30 12:39:28 2015 Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 16:39:28 +0000 Received: from localhost ([127.0.0.1]:42890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW5dg-0008Fo-2G for submit@debbugs.gnu.org; Sun, 30 Aug 2015 12:39:28 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:40118) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW5dd-0008Fe-EH for 21380@debbugs.gnu.org; Sun, 30 Aug 2015 12:39:26 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NTW00800LZETN00@mtaout26.012.net.il> for 21380@debbugs.gnu.org; Sun, 30 Aug 2015 19:41:04 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTW000GSMCGF780@mtaout26.012.net.il>; Sun, 30 Aug 2015 19:41:04 +0300 (IDT) Date: Sun, 30 Aug 2015 19:39:05 +0300 From: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet Message-id: <83k2sc20k6.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 30 Aug 2015 15:24:26 +0000 > From: Pip Cet > Cc: 21380@debbugs.gnu.org > > > Further investigation indicates that > > window-configuration-change-hook was called in the middle of concat: > > Did you understand how this fact is related to the segfault? > > > I _think_ I do. > > 1. concat called with args[0] == Vtimer_list > 2. concat stores result_len (=4) > 3. concat calls make_list (4) > 4. make_list interrupted by QUIT > 5. see stack trace > 6. window-configuration-change-hook modifies Vtimer_list, which now has length > 5 > 7. control returns to concat > 8. concat tries to write 5 elements into a 4-element list, which causes the > segfault because `tail' is unexpectedly NULL. > > Does that make sense to you? It does, but there's one additional factor that was supposed to prevent such problems: the first thing timer_check does is copy Vtimer_list to a local variable; then it works on that copy. So whatever happens in the meantime to Vtimer_list should not have affected concat, because concat is called on a copy. Which part of this doesn't work, and why? From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 30 12:42:25 2015 Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 16:42:25 +0000 Received: from localhost ([127.0.0.1]:42894 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW5gW-0008KF-Pt for submit@debbugs.gnu.org; Sun, 30 Aug 2015 12:42:25 -0400 Received: from mail-ig0-f177.google.com ([209.85.213.177]:34744) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW5gU-0008K6-DO for 21380@debbugs.gnu.org; Sun, 30 Aug 2015 12:42:22 -0400 Received: by igui7 with SMTP id i7so43207902igu.1 for <21380@debbugs.gnu.org>; Sun, 30 Aug 2015 09:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CIc/Hw7qwJ8g5kYLjzBwpR3UlR71GHVdOTbIIpdw+Do=; b=E3iwii73RPB3ig8GwFqlcbV0mQ402Z5PRjMoGzJSAuIwX07KRlUbR5RdcwcRWj2h3j pwD6DUyN0vFkbZDOWyZ5bnLdKCGKhZbaeTuFxe9VX+Xc+KKpRXsVivwIC7OrFrtYUA6+ gSYqbGQjyrb9rfcNY/D65wtGJ8w8CUVpqwrrqLzjimvSTaTB+6O7qB/jAOQVko9weH6J lwDcWvy/UptC/s3As6YmMhZXcA6UuJ7KQ+vcilm5fWkTJlxlS2cseaI80TKN0+93aeF6 +c5/GCkQikZiDXiBQX7u+r2ZrE8xhZsKzd+SSioNIG9lX2mcNDxd2ltA5epmJRBhTLv8 1rCw== MIME-Version: 1.0 X-Received: by 10.50.17.9 with SMTP id k9mr11426920igd.93.1440952941470; Sun, 30 Aug 2015 09:42:21 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 09:42:21 -0700 (PDT) In-Reply-To: <83k2sc20k6.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> Date: Sun, 30 Aug 2015 16:42:21 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook From: Pip Cet To: Eli Zaretskii Content-Type: multipart/alternative; boundary=089e01182a3436eb35051e8a00df X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e01182a3436eb35051e8a00df Content-Type: text/plain; charset=UTF-8 On Sun, Aug 30, 2015 at 4:39 PM, Eli Zaretskii wrote: > > Date: Sun, 30 Aug 2015 15:24:26 +0000 > > From: Pip Cet > > Cc: 21380@debbugs.gnu.org > > > > > Further investigation indicates that > > > window-configuration-change-hook was called in the middle of > concat: > > > > Did you understand how this fact is related to the segfault? > > > > > > I _think_ I do. > > > > 1. concat called with args[0] == Vtimer_list > > 2. concat stores result_len (=4) > > 3. concat calls make_list (4) > > 4. make_list interrupted by QUIT > > 5. see stack trace > > 6. window-configuration-change-hook modifies Vtimer_list, which now has > length > > 5 > > 7. control returns to concat > > 8. concat tries to write 5 elements into a 4-element list, which causes > the > > segfault because `tail' is unexpectedly NULL. > > > > Does that make sense to you? > > It does, but there's one additional factor that was supposed to > prevent such problems: the first thing timer_check does is copy > Vtimer_list to a local variable; then it works on that copy. So > whatever happens in the meantime to Vtimer_list should not have > affected concat, because concat is called on a copy. > I'm not sure I understand. This issue is happening while the temporary copy is being created, not afterwards, IIUC. --089e01182a3436eb35051e8a00df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Aug 30, 2015 at 4:39 PM, Eli Zaretskii <eliz@gnu.org= > wrote:
> Date: Sun, 30 Aug 2015 15:24:= 26 +0000
> From: Pip Cet <pipcet@gmail.com= >
> Cc: 21380@debbugs.gnu.org=
>
>=C2=A0 =C2=A0 =C2=A0> Further investigation indicates that
>=C2=A0 =C2=A0 =C2=A0> window-configuration-change-hook was called in= the middle of concat:
>
>=C2=A0 =C2=A0 =C2=A0Did you understand how this fact is related to the = segfault?
>
>
> I _think_ I do.
>
> 1. concat called with args[0] =3D=3D Vtimer_list
> 2. concat stores result_len (=3D4)
> 3. concat calls make_list (4)
> 4. make_list interrupted by QUIT
> 5. see stack trace
> 6. window-configuration-change-hook modifies Vtimer_list, which now ha= s length
> 5
> 7. control returns to concat
> 8. concat tries to write 5 elements into a 4-element list, which cause= s the
> segfault because `tail' is unexpectedly NULL.
>
> Does that make sense to you?

It does, but there's one additional factor that was supposed to<= br> prevent such problems: the first thing timer_check does is copy
Vtimer_list to a local variable; then it works on that copy.=C2=A0 So
whatever happens in the meantime to Vtimer_list should not have
affected concat, because concat is called on a copy.
<= br>
I'm not sure I understand. This issue is happening while = the temporary copy is being created, not afterwards, IIUC.
<= /div>
--089e01182a3436eb35051e8a00df-- From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 30 14:10:46 2015 Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 18:10:46 +0000 Received: from localhost ([127.0.0.1]:43002 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW742-000224-0k for submit@debbugs.gnu.org; Sun, 30 Aug 2015 14:10:46 -0400 Received: from mout.gmx.net ([212.227.15.18]:50084) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW73z-00021v-B9 for 21380@debbugs.gnu.org; Sun, 30 Aug 2015 14:10:44 -0400 Received: from [188.22.232.77] ([188.22.232.77]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0ML72n-1ZVpwk3Iqv-000Oth; Sun, 30 Aug 2015 20:10:39 +0200 Message-ID: <55E34714.7080608@gmx.at> Date: Sun, 30 Aug 2015 20:10:28 +0200 From: martin rudalics MIME-Version: 1.0 To: Pip Cet , Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook References: <83mvx8252m.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:OxUqQeaVpHW1MB4j75E5gXlJWNNTYlY9Gmz8UCWas13H95lqgiE eQZN0WRVwrqJqkvLOrkgSGNm89KVTVJ6TG2twMaPkomVEfKPJlmHYwKnGIBsa49L6KCKJtz W414vGm48WgLGT84/IOACwgjSwRoNTTevTGVNfTxR2ezzDRTcyQlJOWfdwsE9vArg3O1UBv hbhbxPv49j2PGE3+tTGCQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:48WAOO9ZmbQ=:q2qI2LvyrpeTFGXPYcppxD L/5XLXZ1MOXQFuA4avOK4HowYFLynUnyvbzjLKfU6vtZrsmY3/PzDcdUO0Asrze4K6HeqgKrm 7Ru1srRaQ0JO8nxw76IxNfNJtFUSvNHF99y8/h88HemfDNHAMbFcQkIK8W6tTpUGN6d9xKfeG TxmmLaqVMxGoODyykPTuvxfGfbffo33PELD7LkH26156hWORE1DAbhvweIy8C6MYurgLYkzqi X/A6n9rtG4WXHMDKNwlkliqWDPM+WwQp7bRMr5VTPTyu+zh5L1hnMG4bJwL4A3PeO+onAjjlS JG7fExL3Pl+NdjcWQ8iJSjHbCVtW1/biAagoSsj6isFk5rfqysbPzdSu9bPOZ9NezNibhyiO2 t88HBwxCqJVYSmaFL/LNQvyyJl3+LWuJoZ13gnOQUucIAZa4RvexF3X4PHA6k+0I/FHZTJJG/ x9TtLLkdLMA+U8h+GorohwUjQOqabZxSwJ9puQv/JDD3wqCBDshve9z8mQ8f7ONWVvjwPoltq HGjBGKHE6R+cNoAjFZ3o52/Raf/sA0SZ9xbxW3ZcL3+j1x+e3pjvfRc2pQYl+wO/f9PAJcYTv 2A31YC5ov7UOG/XAoXyCrBqgYqvWH6OxLhNGQemB9aYubjuC3BEaT8BpzspOJg++2pDLPwnFI 1a6JvwQWqVqq3Guhc0/wBBL/lBKsmfL09+9YMtV6MFlRH3boqSwaEyhs5CjXomF/nSm0wfOQN a/yll/F0YGpc2qRu/Vib2zXpYHsdiHUvOXT8+w== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > I think the problem is the call to do_pending_window_change in > xg_frame_resized in gtkutil.c: the commit message (commit 3477e27021db= ) > says: > > Author: Martin Rudalics > AuthorDate: Sun Jul 27 15:21:30 2014 +0200 > Commit: Martin Rudalics > CommitDate: Sun Jul 27 15:21:30 2014 +0200 > > Complete pixelwise frame/window resizing, add horizontal scrollba= r > support. > [...] > * gtkutil.c (xg_frame_resized): Don't call > do_pending_window_change. > > but the diff is: > > @@ -883,6 +884,8 @@ xg_frame_resized (struct frame *f, int pixelwidth,= int > pixelheight) > change_frame_size (f, width, height, 0, 1, 0, 1); > SET_FRAME_GARBAGED (f); > cancel_mouse_face (f); > + > + do_pending_window_change (0); > } > } Remarkable. I don't remember why I added them. And obviously I have no idea why I wrote the ChangeLog entry in reverse. Just as if I read diff output in the wrong direction. In my understanding the do_pending_window_change call is not needed and usually should be a noop. But I have no idea why this particular call of do_pending_window_change would run =E2=80=98window-configuration-chang= e-hook=E2=80=99 and subsequently cause the havoc you describe. The last change_frame_size should have just happened three lines before. > And my current understanding is this bug would not occur if that call = were > removed. The same issue applies to the change to x_set_window_size, bu= t I'm > not certain about removing either call. Maybe. But the cause of the SEGFAULT must be elsewhere. I have no idea how 4. make_list interrupted by QUIT could happen "while the temporary copy is being created" when timer_check has set Vinhibit_quit to t. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 30 14:20:44 2015 Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 18:20:45 +0000 Received: from localhost ([127.0.0.1]:43006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW7Dg-0002GZ-AF for submit@debbugs.gnu.org; Sun, 30 Aug 2015 14:20:44 -0400 Received: from mail-ig0-f178.google.com ([209.85.213.178]:34206) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW7De-0002GR-MQ for 21380@debbugs.gnu.org; Sun, 30 Aug 2015 14:20:43 -0400 Received: by igui7 with SMTP id i7so43924716igu.1 for <21380@debbugs.gnu.org>; Sun, 30 Aug 2015 11:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GzxB0cnIH2LBqxxOAo740sMT+ofgXi3UWkwQptQG3uc=; b=mIiThIeaN+4MQUuKp6Yi+3kyqqDyaACD0quOeTXLWGyuw479HiZMhEb5IiBd8RefM3 i4Cf6cIYUluNNNgdB+IUT+iQd737+rHS9hgg3x2GlJkyRhmSw4hNfM6AtyHG6fZ3aXxk T25zHysouRUWx6yYaHDQfiKdU1sYP1uEkMhiOQHbFd4WbR2JKgl93EwKvU1b56nbTwAc Gp82n/CdjQplwkvby24jgwsZsclgEE+WvJbFij0q7rBNMk4aK776g1nQL3sW849FnCa3 sEFJq2W4z60lTNBGYpl5NRUg4dvsfBRgvXsoifzzePorLogWXKFQNWNGGm2WNofGlwQj uUDQ== MIME-Version: 1.0 X-Received: by 10.50.97.33 with SMTP id dx1mr10509694igb.1.1440958842121; Sun, 30 Aug 2015 11:20:42 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 11:20:42 -0700 (PDT) In-Reply-To: <55E34714.7080608@gmx.at> References: <83mvx8252m.fsf@gnu.org> <55E34714.7080608@gmx.at> Date: Sun, 30 Aug 2015 18:20:42 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook From: Pip Cet To: martin rudalics Content-Type: multipart/alternative; boundary=047d7b10c889ebb72f051e8b5f58 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --047d7b10c889ebb72f051e8b5f58 Content-Type: text/plain; charset=UTF-8 On Sun, Aug 30, 2015 at 6:10 PM, martin rudalics wrote: > Remarkable. I don't remember why I added them. And obviously I have no > idea why I wrote the ChangeLog entry in reverse. Just as if I read diff > output in the wrong direction. > I thought it might have been ANTINEWS month and I missed it :-) > > And my current understanding is this bug would not occur if that call > were > > removed. The same issue applies to the change to x_set_window_size, but > I'm > > not certain about removing either call. > > Maybe. But the cause of the SEGFAULT must be elsewhere. I have no > idea how > > 4. make_list interrupted by QUIT > > could happen "while the temporary copy is being created" when > timer_check has set Vinhibit_quit to t. > inhibit_quit inhibits process_quit_flag(), but not process_pending_signals(), if I'm reading this correctly: #define QUIT \ do { \ if (!NILP (Vquit_flag) && NILP (Vinhibit_quit)) \ process_quit_flag (); \ else if (pending_signals) \ process_pending_signals (); \ } while (false) Maybe it should. Regards, Pip --047d7b10c889ebb72f051e8b5f58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Aug 30, 2015 at 6:10 PM, martin rudalics <rudalics@= gmx.at> wrote:
Remarkable.=C2= =A0 I don't remember why I added them.=C2=A0 And obviously I have no idea why I wrote the ChangeLog entry in reverse.=C2=A0 Just as if I read di= ff
output in the wrong direction.

I though= t it might have been ANTINEWS month and I missed it :-)
=C2= =A0
> And my current understanding is this bug would not occur if that call = were
> removed. The same issue applies to the change to x_set_window_size, bu= t I'm
> not certain about removing either call.

 Maybe.=C2=A0 But the cause of the SEGFAULT must be elsewhere.=C2=A0 I have = no
idea how

4. make_list interrupted by QUIT

 could happen "while the temporary copy is being created" when
timer_check has set Vinhibit_quit to t.

inhibit_quit inhibi= ts process_quit_flag(), but not process_pending_signals(), if I'm readi= ng this correctly:

#define QUIT=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 \
=C2=A0 do {=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0 \
=C2=A0=C2=A0=C2=A0 if (!NILP (Vquit_flag) && NILP (Vinh= ibit_quit))=C2=A0=C2=A0=C2=A0 \
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 process_q= uit_flag ();=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0 \
=C2=A0=C2=A0=C2=A0 else if (pending_signals)=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 \
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 process_pending_signals ();=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 \
=C2=A0 } while (false)

Maybe it should.

Regards,
Pip
--047d7b10c889ebb72f051e8b5f58-- From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 30 14:59:58 2015 Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 18:59:58 +0000 Received: from localhost ([127.0.0.1]:43038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW7pe-0003Bn-0x for submit@debbugs.gnu.org; Sun, 30 Aug 2015 14:59:58 -0400 Received: from mail-io0-f175.google.com ([209.85.223.175]:35264) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW7pc-0003Bf-0Z for 21380@debbugs.gnu.org; Sun, 30 Aug 2015 14:59:56 -0400 Received: by iog7 with SMTP id 7so14787450iog.2 for <21380@debbugs.gnu.org>; Sun, 30 Aug 2015 11:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=my2PkLwoJ6imghupre2s2HylUxbmmPBHh6aeap8I+Zo=; b=yGNl+8ud0D3HRYSWjafZyLNN79VgjiKAXOdLD1ool6vKmgPNmdx9wu60ONmCyXO2sf Pd7ilPJzXeEE4eDq7+FBujiLEwQL4gKBHoJRlvsacNId211etewnvaneAsoMFAxo77Yk 8S3c1j/O9RpreRLyuFY1ti9BcokyifGkmBlWqy2E4P25m89iHu7sT5e7NyamFMDC3kxs WuqADoKxqyzKToY2JQUtPAFQuk/b9wnOjNK+PNYJZSR5srPqytH07OFS0Q7iAHqt9Akw re0ZVbHRyZ0eUbtUV6YWAe0BTeiPeP7Zn7o5j7xcEfc3dlqUGV0LhuhjSD0Pt8DNvIXQ 2ePg== MIME-Version: 1.0 X-Received: by 10.107.47.97 with SMTP id j94mr21867283ioo.136.1440961195250; Sun, 30 Aug 2015 11:59:55 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 11:59:55 -0700 (PDT) In-Reply-To: <55E34714.7080608@gmx.at> References: <83mvx8252m.fsf@gnu.org> <55E34714.7080608@gmx.at> Date: Sun, 30 Aug 2015 18:59:55 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook From: Pip Cet To: martin rudalics Content-Type: multipart/alternative; boundary=001a1144ac342d99ec051e8becd1 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a1144ac342d99ec051e8becd1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Aug 30, 2015 at 6:10 PM, martin rudalics wrote: > In my understanding the do_pending_window_change call is not needed and > usually should be a noop. May I ask why? I don't understand this code very well. > But I have no idea why this particular call > of do_pending_window_change would run =E2=80=98window-configuration-chang= e-hook=E2=80=99 > and subsequently cause the havoc you describe. The last > change_frame_size should have just happened three lines before. > But that had delay =3D=3D true, so change_frame_size_1 never called adjust_frame_size, right? > > And my current understanding is this bug would not occur if that call > were > > removed. ...but possibly that wouldn't work because of other things being called from GTK event handlers. Just thinking out loud for the rest of the Email: I'm somewhat hesitant to mention this idea, but wouldn't it be best for GTK events to generate special input events (like we already do for asynchronous frame switches?), and let the command loop handle those? I've just hit what appears to be another bug caused by asynchronous frame destruction by GTK (I'm creating and destroying many Emacs frames in my test code). --001a1144ac342d99ec051e8becd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Aug 30, 2015 at 6:10 PM, martin rudalics <rudalics@gmx.at> wrote:
In my understanding the do_pending_window_change call is not needed and
usually should be a noop.

May I ask why? I= don't understand this code very well.
=C2=A0
But I have no idea why this particular call
of do_pending_window_change would run =E2=80=98window-configuration-change-= hook=E2=80=99
and subsequently cause the havoc you describe.=C2=A0 The last
change_frame_size should have just happened three lines before.

But that had delay =3D=3D true, so ch= ange_frame_size_1 never called adjust_frame_size, right?
=C2=A0
> And my current understanding is this bug would not occur if that call = were
> removed.

...but possibly that w= ouldn't work because of other things being called from GTK event handle= rs.

Just thinking out loud for the rest of the Email:
=
I'm somewhat hesitant to mention this idea, but wouldn't it b= e best for GTK events to generate special input events (like we already do = for asynchronous frame switches?), and let the command loop handle those? I= 've just hit what appears to be another bug caused by asynchronous fram= e destruction by GTK (I'm creating and destroying many Emacs frames in = my test code).
--001a1144ac342d99ec051e8becd1-- From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 30 15:44:35 2015 Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 19:44:35 +0000 Received: from localhost ([127.0.0.1]:43084 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW8Wp-0004HH-9r for submit@debbugs.gnu.org; Sun, 30 Aug 2015 15:44:35 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:45827) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW8Wm-0004H7-75 for 21380@debbugs.gnu.org; Sun, 30 Aug 2015 15:44:33 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NTW00900UG2QI00@a-mtaout20.012.net.il> for 21380@debbugs.gnu.org; Sun, 30 Aug 2015 22:44:30 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTW009LHUU6KY60@a-mtaout20.012.net.il>; Sun, 30 Aug 2015 22:44:30 +0300 (IDT) Date: Sun, 30 Aug 2015 22:44:38 +0300 From: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet Message-id: <83h9ng1ryx.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 30 Aug 2015 16:42:21 +0000 > From: Pip Cet > Cc: 21380@debbugs.gnu.org > > > Does that make sense to you? > > It does, but there's one additional factor that was supposed to > prevent such problems: the first thing timer_check does is copy > Vtimer_list to a local variable; then it works on that copy. So > whatever happens in the meantime to Vtimer_list should not have > affected concat, because concat is called on a copy. > > I'm not sure I understand. This issue is happening while the temporary copy is > being created, not afterwards, IIUC. Then all we have to do is block QUIT during that copy, no? From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 30 15:50:27 2015 Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 19:50:27 +0000 Received: from localhost ([127.0.0.1]:43088 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW8cV-0004Pl-4O for submit@debbugs.gnu.org; Sun, 30 Aug 2015 15:50:27 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:39568) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW8cR-0004Pb-TG for 21380@debbugs.gnu.org; Sun, 30 Aug 2015 15:50:25 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NTW00900V1TL400@a-mtaout21.012.net.il> for 21380@debbugs.gnu.org; Sun, 30 Aug 2015 22:50:22 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTW0091CV3XGLA0@a-mtaout21.012.net.il>; Sun, 30 Aug 2015 22:50:22 +0300 (IDT) Date: Sun, 30 Aug 2015 22:50:30 +0300 From: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet Message-id: <83fv301rp5.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <55E34714.7080608@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21380 Cc: rudalics@gmx.at, 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 30 Aug 2015 18:20:42 +0000 > From: Pip Cet > Cc: Eli Zaretskii , 21380@debbugs.gnu.org > > Maybe. But the cause of the SEGFAULT must be elsewhere. I have no > idea how > > 4. make_list interrupted by QUIT > > could happen "while the temporary copy is being created" when > timer_check has set Vinhibit_quit to t. > > > inhibit_quit inhibits process_quit_flag(), but not process_pending_signals(), > if I'm reading this correctly: > > #define QUIT \ > do { \ > if (!NILP (Vquit_flag) && NILP (Vinhibit_quit)) \ > process_quit_flag (); \ > else if (pending_signals) \ > process_pending_signals (); \ > } while (false) > > Maybe it should. Does block_input/unblock_input around the copying solve the problem? From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 30 16:56:37 2015 Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 20:56:37 +0000 Received: from localhost ([127.0.0.1]:43121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW9eW-00068i-ID for submit@debbugs.gnu.org; Sun, 30 Aug 2015 16:56:37 -0400 Received: from mail-io0-f180.google.com ([209.85.223.180]:33166) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW9eU-00068Z-J2 for 21380@debbugs.gnu.org; Sun, 30 Aug 2015 16:56:35 -0400 Received: by iods203 with SMTP id s203so139740119iod.0 for <21380@debbugs.gnu.org>; Sun, 30 Aug 2015 13:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qcOUrLzskIxIYKPHS0F3KgCziDG5uKGJ6OgyF7Dk/sQ=; b=CrpLInUmTtl1QyX/PknDVtdp4H7b2iLEwTfaaC+3HQd29n/imWCxpxcRSk/fyT06if 41esC9v+EGLYbGKlkDRflvlzRsDjnW4wjplD4aKmz5K3nyQ4LgTsorLTX7+OyrdpPWt0 z80l3P0/hYPkhk0363Od7Ws9KfLFC6TXqakjs8VYN/vTh6hPKMKDCteaSz3N+DD9ghwt rspHvFTSsrWEVKDxXT6f5lkezq6syxnYFzejPgI7PHXDjXneUVjoCuUQ0/dI8d7RadXM gQUm9oQeVF9TPoo+NpDtEpak8E2n0kDR/sISPTKE0x3tEbCMM2bO9g9BWbz0rVb5tgX2 VRng== MIME-Version: 1.0 X-Received: by 10.107.132.139 with SMTP id o11mr21144847ioi.3.1440968193677; Sun, 30 Aug 2015 13:56:33 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 13:56:33 -0700 (PDT) In-Reply-To: <83h9ng1ryx.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> Date: Sun, 30 Aug 2015 20:56:33 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook From: Pip Cet To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a113ed2f85121d9051e8d8d49 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a113ed2f85121d9051e8d8d49 Content-Type: text/plain; charset=UTF-8 On Sun, Aug 30, 2015 at 7:44 PM, Eli Zaretskii wrote: > > I'm not sure I understand. This issue is happening while the temporary > copy is > > being created, not afterwards, IIUC. > > Then all we have to do is block QUIT during that copy, no? Yes for this particular segfault. No* for similar segfaults that I think pose equally severe problems: if any other function calls concat/copy-sequence on data that is modified by window-configuration-change-hook, it should* still be possible to produce the segfault. So it wouldn't even be safe for window-configuration-change-hook to add a timer to the timer list, because the outer frame might be in the middle of creating a copy of the timer list for some Lisp code that hasn't blocked input. (As in my example below) I really don't think QUIT should run any Lisp hooks, to be honest. From the point of view of the Lisp user (and the not-totally-careful C user, as in this case), that might make them happen at any time, and all kinds of race conditions would occur instead. Maybe this is a matter for emacs-devel? If I'm wrong and QUIT should be able to run Lisp hooks, concat needs to be fixed not to rely on its argument's size being unchanged after the make_sequence call. *-I have been able to verify this segfault by interrupting the program at just the right time and resizing its X window then: - gdb --args emacs -Q - evaluate the following code: (run-with-timer 0 1 #'ignore) ;; so the timer list isn't empty (add-hook 'window-configuration-change-hook (lambda () (run-with-timer 0 nil #'ignore))) (while t (copy-sequence timer-list) (accept-process-output nil 0) ) - interrupt and set a breakpoint with "b Fmake_sequence if !input_blocked_p()". - wait for breakpoint to be hit, verify that concat's args[0] is equal to Vtimer_list. - resize the X window - continue in gdb - segfault As far as I can tell, that should be reproducible. Also as far as I can tell, it's merely a matter of luck that an X resize doesn't happen at the point where I interrupted the program to artificially trigger the segfault. However, I admit that it is a separate issue, less likely to occur in practice, and I'll open another bug for it if that's the way you prefer things. --001a113ed2f85121d9051e8d8d49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Aug 30, 2015 at 7:44 PM, Eli Zaretskii <eliz@gnu.org= > wrote:
> I'm n= ot sure I understand. This issue is happening while the temporary copy is > being created, not afterwards, IIUC.

Then all we have to do is block QUIT during that copy, no?

Yes for this particular segfa= ult.

No* for similar segfaults that I think pose equally severe prob= lems: if any other function calls concat/copy-sequence on data that is modi= fied by window-configuration-change-hook, it should* still be possible to p= roduce the segfault. So it wouldn't even be safe for window-configurati= on-change-hook to add a timer to the timer list, because the outer frame mi= ght be in the middle of creating a copy of the timer list for some Lisp cod= e that hasn't blocked input. (As in my example below)

I really don't think QUIT should run any Lisp ho= oks, to be honest. From the point of view of the Lisp user (and the not-tot= ally-careful C user, as in this case), that might make them happen at any t= ime, and all kinds of race conditions would occur instead. Maybe this is a = matter for emacs-devel?

If I'm = wrong and QUIT should be able to run Lisp hooks, concat needs to be fixed n= ot to rely on its argument's size being unchanged after the make_sequen= ce call.

*-I have been able to verify this segfault by interrupting the progr= am at just the right time and resizing its X window then:
=C2=A0- gdb --= args emacs -Q
=C2=A0- evaluate the following code:

(run-with-time= r 0 1 #'ignore) ;; so the timer list isn't empty
(add-hook '= window-configuration-change-hook (lambda () (run-with-timer 0 nil #'ign= ore)))

(while t
=C2=A0 (copy-sequence timer-list)
=C2=A0 (acce= pt-process-output nil 0)
=C2=A0 )

=C2=A0- interrupt and set a breakpoint with "b Fmake_sequence if !in= put_blocked_p()".
=C2=A0- wait for breakpoint to be hit, verify th= at concat's args[0] is equal to Vtimer_list.
=C2=A0- resize the X window
= =C2=A0- continue in gdb
=C2=A0- segfaul= t

As far as I can tell, that should= be reproducible. Also as far as I can tell, it's merely a matter of lu= ck that an X resize doesn't happen at the point where I interrupted the= program to artificially trigger the segfault. However, I admit that it is = a separate issue, less likely to occur in practice, and I'll open anoth= er bug for it if that's the way you prefer things.
--001a113ed2f85121d9051e8d8d49-- From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 30 17:13:05 2015 Received: (at 21380) by debbugs.gnu.org; 30 Aug 2015 21:13:05 +0000 Received: from localhost ([127.0.0.1]:43137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW9uT-0006g1-58 for submit@debbugs.gnu.org; Sun, 30 Aug 2015 17:13:05 -0400 Received: from mail-ig0-f178.google.com ([209.85.213.178]:32894) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW9uQ-0006fq-Vx for 21380@debbugs.gnu.org; Sun, 30 Aug 2015 17:13:03 -0400 Received: by igbuu8 with SMTP id uu8so36017759igb.0 for <21380@debbugs.gnu.org>; Sun, 30 Aug 2015 14:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z1/XSbnHIAMtP4jViqL6TlXvkYz5sfZFZVezLVilvns=; b=vNKqPdr/lMCeTA6n6vBG45rVqPDZ8dunkWF+XWgSlgriDVxRKo3fMEM67+LXUhoneX l/5PFbdcUzBwNA6X1pMUrn4DYal6SQMmOTa7ShqeSkpRo5Fs8L/MvjbBoeBo18mW5Q1f e8YrzwEnimseJ5yQ5ezAxD+bXa/0Gd819S42YwPT/v2jWrFBf6Ypngdzp/UwpIlVuY5s rAUIisbnwQgy488rNjBYC6bFCAxg1jur1G6jXSV/pYaQxlX19gnHU7SxKfKleg+O4URf yIqEbGf3LZxUX8VVUDNif/VN2bd19NW6kXdUKTz/xe4YIXfnfHFrjfnVmwu6Z9Pvmw0/ 3s5Q== MIME-Version: 1.0 X-Received: by 10.50.17.9 with SMTP id k9mr12046834igd.93.1440969182427; Sun, 30 Aug 2015 14:13:02 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Sun, 30 Aug 2015 14:13:02 -0700 (PDT) In-Reply-To: References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> Date: Sun, 30 Aug 2015 21:13:02 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook From: Pip Cet To: Eli Zaretskii Content-Type: multipart/alternative; boundary=089e01182a34403eec051e8dc8fc X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e01182a34403eec051e8dc8fc Content-Type: text/plain; charset=UTF-8 On Sun, Aug 30, 2015 at 8:56 PM, Pip Cet wrote: > - interrupt and set a breakpoint with "b Fmake_sequence if > !input_blocked_p()". > Fmake_list, sorry. I should also make it clear that I've tested this with block_input/unblock_input where you suggested it (thus the !input_blocked_p() in order not to catch that case). Please let me know if you can't reproduce it or want me to send a gdb log or anything else. Thanks again, Pip --089e01182a34403eec051e8dc8fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Aug 30, 2015 at 8:56 PM, Pip Cet <pipcet@gmail.com= > wrote:
- interrupt and set a breakpoint with "b Fmake_sequence if !input_b= locked_p()".

Fmake_list, so= rry. I should also make it clear that I've tested this with block_input= /unblock_input where you suggested it (thus the !input_blocked_p() in order= not to catch that case). Please let me know if you can't reproduce it = or want me to send a gdb log or anything else.

Thanks aga= in,
Pip
--089e01182a34403eec051e8dc8fc-- From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 31 05:20:09 2015 Received: (at 21380) by debbugs.gnu.org; 31 Aug 2015 09:20:09 +0000 Received: from localhost ([127.0.0.1]:43438 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWLG4-0000Kb-MX for submit@debbugs.gnu.org; Mon, 31 Aug 2015 05:20:08 -0400 Received: from mout.gmx.net ([212.227.17.21]:58575) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWLG3-0000KT-59 for 21380@debbugs.gnu.org; Mon, 31 Aug 2015 05:20:07 -0400 Received: from [93.82.13.140] ([93.82.13.140]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M6vSj-1YjJ2p0gbt-00woka; Mon, 31 Aug 2015 11:20:06 +0200 Message-ID: <55E41C44.90703@gmx.at> Date: Mon, 31 Aug 2015 11:20:04 +0200 From: martin rudalics MIME-Version: 1.0 To: Pip Cet Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook References: <83mvx8252m.fsf@gnu.org> <55E34714.7080608@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:PKClGxZi6pSUjZ9pxdfeUp3frlEJfDfZYwKPLFI5CnPIS6O4THM j8hI5i65rlOdvniY88/w5euWUCzpxFMnGzHBlf8ZKO/b8rXgy3A1wK8NWw2JbBm4nM/eZzd QkekrA6vM2oWtMl1BLttIxUT6RUmx1zon70MxK5hIxQGiHeZczdT+eX1muHmwCLTpVRO+lQ lpgsUcjrvOjsoQsN5TpYA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Pj33QVrNFXw=:XRaXyxLAm1PAH1uvUeZWhB DQZpHXTEU+BJtW1l/+K4k1CRzVeD9zJcTVbGQF9asl6zHB+mIaQqDl1QnB8vGjeHoNcjTwwqE x7ssu8CIi1NbmFPkjDlEwhDeDNK7HIARAlgsl4yt7EeqDs6xPwiJshbVi76ZAhxkWJWF6gDVy zTllGSRgriFLfeB/CHKpW8PNKQj5Eh9LTLmB6r0fCPeCbQB/hqxyiP5uGReydSLKc23DZWL2v lkDZC7qwnwFaliWi5Ykbxw+5oeK43gA/iSkWqXshp+UTt1gykikYWNX7WHOfPfe0+UeZN7EkK r+V6ZNjdaRENQUOZGscz7CH76iKKqqc6phfEsjwyPR1wyg8LGd1F97957vz9z7V8mwJrNta0h oaMTJ1PzVPLoGPiPVl1aGumEfbjNcViCprVcqy6F/ydVUbVHzQflpcRtJpWIAkWlKIkEwxspy dwCv6IOUkaTOP0MiNLggfWG9XpAEWEI22kfHmXKk+nFdEg5FSGQJ4Gfy/v76f2QANsfVMupqg URkdd5OLCnjSRXEf83RRHlbMLEtMFR6lbII7MBj4EnVKQ/Gqm25DACJc4olOKFOgFLPcW6ZLm s3kG9GIkHdBJ6hg+bbLAdmO+MGqvmKDhYrnQA+qXATkR1OQ66CHl7JhyeNX2NZbtLARlereVZ 2DWYLVLprqlpb8YBG4z99Klf3edXif/ZohK5TpKfzrq3kU92t1Gk4tao6+Si5QGixiFH2M1ie QpfxKbO08qbTsi34yexlqn1cDussxGTpvaHKxQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> But I have no idea why this particular call >> of do_pending_window_change would run =E2=80=98window-configuration-c= hange-hook=E2=80=99 >> and subsequently cause the havoc you describe. The last >> change_frame_size should have just happened three lines before. > > But that had delay =3D=3D true, so change_frame_size_1 never called > adjust_frame_size, right? Indeed. I removed the do_pending_window_change calls now. I don't recall why I thought that I needed them, maybe to get those border clearing calls in synch with the resizing of the root window. In any case, judging from my ChangeLog entries, I must have had some sort of premonition that this was a bad idea. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 31 10:32:26 2015 Received: (at 21380) by debbugs.gnu.org; 31 Aug 2015 14:32:27 +0000 Received: from localhost ([127.0.0.1]:43752 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWQ8I-0000uf-C8 for submit@debbugs.gnu.org; Mon, 31 Aug 2015 10:32:26 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:40048) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWQ8G-0000uW-0I for 21380@debbugs.gnu.org; Mon, 31 Aug 2015 10:32:25 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NTY00G00AY3RD00@a-mtaout22.012.net.il> for 21380@debbugs.gnu.org; Mon, 31 Aug 2015 17:31:37 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTY00GABB0OO820@a-mtaout22.012.net.il>; Mon, 31 Aug 2015 17:31:37 +0300 (IDT) Date: Mon, 31 Aug 2015 17:31:46 +0300 From: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet Message-id: <83a8t71qct.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 30 Aug 2015 20:56:33 +0000 > From: Pip Cet > Cc: 21380@debbugs.gnu.org > > Then all we have to do is block QUIT during that copy, no? > > Yes for this particular segfault. Can you show a patch that fixes the original segfault in your use case? I'm afraid I lost track, what with all the different scenarios and potential solutions being thrown at this. We should install the fix, assuming it's clean. > No* for similar segfaults that I think pose equally severe problems: if any other function calls concat/copy-sequence on data that is modified by window-configuration-change-hook, it should* still be possible to produce the segfault. Emacs gives you enough rope to hang yourself; there's nothing new here. We should strive to protect the Emacs internals so that they won't cause segfaults, but in user code any bets are off, and "don't do that" is a valid response to whoever does such things. > So it wouldn't even be safe for window-configuration-change-hook to add a timer to the timer list, because the outer frame might be in the middle of creating a copy of the timer list for some Lisp code that hasn't blocked input. (As in my example below) Futzing with timers from within some hooks is indeed fundamentally dangerous. But we should still try to minimize the probability of a crash, especially when it's Emacs itself who makes the offending copy, because people do dangerous things all the time, and expect them to work. In this case, blocking input should do, I think. > I really don't think QUIT should run any Lisp hooks, to be honest. I don't think this limitation could fly. It will disable a lot of useful use patterns, and the outcry will be loud and clear. > If I'm wrong and QUIT should be able to run Lisp hooks, concat needs to be fixed not to rely on its argument's size being unchanged after the make_sequence call. That can't do any harm, so let's do it, too. > *-I have been able to verify this segfault by interrupting the program at just the right time and resizing its X window then: > - gdb --args emacs -Q > - evaluate the following code: > > (run-with-timer 0 1 #'ignore) ;; so the timer list isn't empty > (add-hook 'window-configuration-change-hook (lambda () (run-with-timer 0 nil #'ignore))) > (while t > (copy-sequence timer-list) > (accept-process-output nil 0) > ) > > - interrupt and set a breakpoint with "b Fmake_sequence if !input_blocked_p()". > - wait for breakpoint to be hit, verify that concat's args[0] is equal to Vtimer_list. > - resize the X window > - continue in gdb > - segfault > > As far as I can tell, that should be reproducible. Also as far as I can tell, it's merely a matter of luck that an X resize doesn't happen at the point where I interrupted the program to artificially trigger the segfault. However, I admit that it is a separate issue, less likely to occur in practice, and I'll open another bug for it if that's the way you prefer things. But if input is blocked, as it would be in the case of copying timer-list inside timer_check, the X events will not be acted upon, and the problem will not happen, right? IOW, the above situation is a case of a user shooting herself in the foot by having that particular function in the hook and that particular code that copies timer-list (which is an internal variable unwise users should not touch). Am I right? From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 01 06:20:16 2015 Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 10:20:16 +0000 Received: from localhost ([127.0.0.1]:44740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWifn-0005m5-5h for submit@debbugs.gnu.org; Tue, 01 Sep 2015 06:20:16 -0400 Received: from mail-io0-f172.google.com ([209.85.223.172]:34196) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWifk-0005lx-8E for 21380@debbugs.gnu.org; Tue, 01 Sep 2015 06:20:13 -0400 Received: by ioeu67 with SMTP id u67so47704972ioe.1 for <21380@debbugs.gnu.org>; Tue, 01 Sep 2015 03:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ae8wfFBO0pfhuzv4f6+mJzu9qyEfMZnP2nsbuIq4p8c=; b=SwhvPfFerZIA/HxgED4y3aX2bC0ctPEE1MyGq5F/Esld7MEvAsBxQjFAFeK0SLXzTC vu+GkhzjogEmDf6roP8RFGhS/zVnigURh6BrF2HehPXrA4U82gLJxxEfn5HkkG5oMuZN ayKg0j9DgPAyWGw8sBzimPrABSM9YRT0FnaXo1s5p8lZLfi8brcF6tysw3oL2Vx8Bffv VrFaNo+knXn957ROFCe0A1XpD3I1maIa2Xg04HOEIss05eHRR8+CCEexO0kp9DB9ZiY1 SUpeQX+AFfISDGL96msVgXf13UTrDAe1nnU8yW/JnhYt2rDbLZAZ/DfGobceyi3U9gh0 uxzQ== MIME-Version: 1.0 X-Received: by 10.107.47.97 with SMTP id j94mr28723647ioo.136.1441102811578; Tue, 01 Sep 2015 03:20:11 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Tue, 1 Sep 2015 03:20:11 -0700 (PDT) In-Reply-To: <83a8t71qct.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> Date: Tue, 1 Sep 2015 10:20:11 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook From: Pip Cet To: Eli Zaretskii Content-Type: multipart/mixed; boundary=001a1144ac342b7664051eace58f X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a1144ac342b7664051eace58f Content-Type: multipart/alternative; boundary=001a1144ac342b765f051eace58d --001a1144ac342b765f051eace58d Content-Type: text/plain; charset=UTF-8 On Mon, Aug 31, 2015 at 2:31 PM, Eli Zaretskii wrote: > > Yes for this particular segfault. > > Can you show a patch that fixes the original segfault in your use > case? Attached. Note that either one of those changes should work. I'll test this patch some more using my original code and see whether it blows up. I'm afraid I lost track, what with all the different scenarios > and potential solutions being thrown at this. We should install the > fix, assuming it's clean. > I think we should fix three things: - concat shouldn't rely on its argument remaining unchanged in length - the timer list copy should happen with block_input/unblock_input wrapped around it - we shouldn't call do_pending_window_change from QUIT [already installed. Thanks, martin!] Any one of these is enough to prevent the original segfault. All but the second also prevent the bizarre-elisp-induced segfault I came up with later. And I'm perfectly happy for today with the number of hooks called from QUIT reduced by one, rather than insisting on reducing them to zero right away. > No* for similar segfaults that I think pose equally severe problems: if > any other function calls concat/copy-sequence on data that is modified by > window-configuration-change-hook, it should* still be possible to produce > the segfault. > > Emacs gives you enough rope to hang yourself; there's nothing new > here. We should strive to protect the Emacs internals so that they > won't cause segfaults, but in user code any bets are off, and "don't > do that" is a valid response to whoever does such things. > It's always good to know what the philosophy is behind the way the code works, so thank you for that, really. > So it wouldn't even be safe for window-configuration-change-hook to add a > timer to the timer list, because the outer frame might be in the middle of > creating a copy of the timer list for some Lisp code that hasn't blocked > input. (As in my example below) > > Futzing with timers from within some hooks is indeed fundamentally > dangerous. Well, doing anything from window-configuration-change-hook is dangerous. My idea was to schedule an immediate timer from it to get out of the danger zone to do the actual work, but that backfired... > But we should still try to minimize the probability of a > crash, especially when it's Emacs itself who makes the offending copy, > because people do dangerous things all the time, and expect them to > work. In this case, blocking input should do, I think. > I agree. > I really don't think QUIT should run any Lisp hooks, to be honest. > > I don't think this limitation could fly. It will disable a lot of > useful use patterns, and the outcry will be loud and clear. > Okay. > If I'm wrong and QUIT should be able to run Lisp hooks, concat needs to > be fixed not to rely on its argument's size being unchanged after the > make_sequence call. > > That can't do any harm, so let's do it, too. > Cool. > > As far as I can tell, that should be reproducible. Also as far as I can > tell, it's merely a matter of luck that an X resize doesn't happen at the > point where I interrupted the program to artificially trigger the segfault. > However, I admit that it is a separate issue, less likely to occur in > practice, and I'll open another bug for it if that's the way you prefer > things. > > But if input is blocked, as it would be in the case of copying > timer-list inside timer_check, the X events will not be acted upon, > and the problem will not happen, right? > Indeed, that relies on bizarre elisp code deliberately doing silly things... > IOW, the above situation is a case of a user shooting herself in the > foot by having that particular function in the hook and that > particular code that copies timer-list (which is an internal variable > unwise users should not touch). Am I right? > I think you are. I'm not sure whether the timer code in timer.el does anything to the timer list that might count as dangerous, but that's possibly the only legitimate Lisp user of timer-list. --001a1144ac342b765f051eace58d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 31, 2015 at 2:31 PM, Eli Zaretskii <eliz@gnu.org= > wrote:
> Yes for this particular segf= ault.

Can you show a patch that fixes the original segfault in your use case?

Attached. Note that either one of tho= se changes should work. I'll test this patch some more using my origina= l code and see whether it blows up.

I'm afraid I lost track, what with all the different scenarios and potential solutions being thrown at this.=C2=A0 We should install the fix, assuming it's clean.

I think w= e should fix three things:
=C2=A0- concat shouldn't rely = on its argument remaining unchanged in length
=C2=A0- the tim= er list copy should happen with block_input/unblock_input wrapped around it=
=C2=A0- we shouldn't call do_pending_window_change from = QUIT [already installed. Thanks, martin!]

Any one of thes= e is enough to prevent the original segfault. All but the second also preve= nt the bizarre-elisp-induced segfault I came up with later. And I'm per= fectly happy for today with the number of hooks called from QUIT reduced by= one, rather than insisting on reducing them to zero right away.

> No* for similar segfaults that I think pose equally severe problems: i= f any other function calls concat/copy-sequence on data that is modified by= window-configuration-change-hook, it should* still be possible to produce = the segfault.

Emacs gives you enough rope to hang yourself; there's nothing ne= w
here.=C2=A0 We should strive to protect the Emacs internals so that they won't cause segfaults, but in user code any bets are off, and "don= 't
do that" is a valid response to whoever does such things.

It's always good to know what the philosophy is= behind the way the code works, so thank you for that, really.

> So it wouldn't even be safe for window-configuration-change-hook t= o add a timer to the timer list, because the outer frame might be in the mi= ddle of creating a copy of the timer list for some Lisp code that hasn'= t blocked input. (As in my example below)

Futzing with timers from within some hooks is indeed fundamentally dangerous.

Well, doing anything from window= -configuration-change-hook is dangerous. My idea was to schedule an immedia= te timer from it to get out of the danger zone to do the actual work, but t= hat backfired...
=C2=A0
= But we should still try to minimize the probability of a
crash, especially when it's Emacs itself who makes the offending copy,<= br> because people do dangerous things all the time, and expect them to
work.=C2=A0 In this case, blocking input should do, I think.

I agree.

> I really don't think QUIT should run any Lisp hooks, to be honest.=

I don't think this limitation could fly.=C2=A0 It will disable a= lot of
useful use patterns, and the outcry will be loud and clear.

Okay.

> If I'm wrong and QUIT should be able to run Lisp hooks, concat nee= ds to be fixed not to rely on its argument's size being unchanged after= the make_sequence call.

That can't do any harm, so let's do it, too.

Cool.
=C2=A0
> As far as I can tell, that should be reproducible. Also as far as I ca= n tell, it's merely a matter of luck that an X resize doesn't happe= n at the point where I interrupted the program to artificially trigger the = segfault. However, I admit that it is a separate issue, less likely to occu= r in practice, and I'll open another bug for it if that's the way y= ou prefer things.

But if input is blocked, as it would be in the case of copying
timer-list inside timer_check, the X events will not be acted upon,
and the problem will not happen, right?

Indeed, that relies on bizarre elisp code deliberately do= ing silly things...
=C2=A0
IOW, the above situation is a case of a user shooting herself in the
foot by having that particular function in the hook and that
particular code that copies timer-list (which is an internal variable
unwise users should not touch).=C2=A0 Am I right?

I think you are. I&= #39;m not sure whether the timer code in timer.el does anything to the time= r list that might count as dangerous, but that's possibly the only legi= timate Lisp user of timer-list.
--001a1144ac342b765f051eace58d-- --001a1144ac342b7664051eace58f Content-Type: text/x-patch; charset=US-ASCII; name="0001-Fix-potential-race-conditions-bug-23380.patch" Content-Disposition: attachment; filename="0001-Fix-potential-race-conditions-bug-23380.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ie17enh80 RnJvbSA3ZTE4OGNhN2IwZTUxYmY3ZmZkYTQxM2NlYmM1M2RhOWViZmUwY2Q2IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXAgPHBpcGNldEBnbWFpbC5jb20+CkRhdGU6IFR1ZSwg MSBTZXAgMjAxNSAxMDoxMjozMSArMDAwMApTdWJqZWN0OiBbUEFUQ0hdIEZpeCBwb3RlbnRpYWwg cmFjZSBjb25kaXRpb25zIChidWcgIzIzMzgwKQoKICAgICAgICAqIGtleWJvYXJkLmMgKHRpbWVy X2NoZWNrKTogQ2FsbCBgYmxvY2tfaW5wdXQnIGFyb3VuZCB0aGUgY3JlYXRpb24KCW9mIHRoZSB0 ZW1wb3JhcnkgdGltZXIgbGlzdCBjb3B5LgoKCSogZm5zLmMgKGNvbmNhdCk6IERvbid0IGFzc3Vt ZSBhcmd1bWVudCBzaXplIHJlbWFpbnMgdW5jaGFuZ2VkCglhZnRlciBjYWxsIHRvIGBGbWFrZV9s aXN0Jy4KLS0tCiBzcmMvZm5zLmMgICAgICB8IDMgKysrCiBzcmMva2V5Ym9hcmQuYyB8IDIgKysK IDIgZmlsZXMgY2hhbmdlZCwgNSBpbnNlcnRpb25zKCspCgpkaWZmIC0tZ2l0IGEvc3JjL2Zucy5j IGIvc3JjL2Zucy5jCmluZGV4IDI2YTk4YWIuLjQzZmY1NTAgMTAwNjQ0Ci0tLSBhL3NyYy9mbnMu YworKysgYi9zcmMvZm5zLmMKQEAgLTc0NCw2ICs3NDQsOSBAQCBjb25jYXQgKHB0cmRpZmZfdCBu YXJncywgTGlzcF9PYmplY3QgKmFyZ3MsCiAJICAgIC8qIFN0b3JlIHRoaXMgZWxlbWVudCBpbnRv IHRoZSByZXN1bHQuICAqLwogCSAgICBpZiAodG9pbmRleCA8IDApCiAJICAgICAgeworICAgICAg ICAgICAgICAgIGlmIChFUSAodGFpbCwgUW5pbCkpCisgICAgICAgICAgICAgICAgICBicmVhazsK KwogCQlYU0VUQ0FSICh0YWlsLCBlbHQpOwogCQlwcmV2ID0gdGFpbDsKIAkJdGFpbCA9IFhDRFIg KHRhaWwpOwpkaWZmIC0tZ2l0IGEvc3JjL2tleWJvYXJkLmMgYi9zcmMva2V5Ym9hcmQuYwppbmRl eCBkYWIzMmIxLi40YjdkNjc1IDEwMDY0NAotLS0gYS9zcmMva2V5Ym9hcmQuYworKysgYi9zcmMv a2V5Ym9hcmQuYwpAQCAtNDU2MCw2ICs0NTYwLDcgQEAgdGltZXJfY2hlY2sgKHZvaWQpCiAKICAg TGlzcF9PYmplY3QgdGVtID0gVmluaGliaXRfcXVpdDsKICAgVmluaGliaXRfcXVpdCA9IFF0Owor ICBibG9ja19pbnB1dCAoKTsKIAogICAvKiBXZSB1c2UgY29waWVzIG9mIHRoZSB0aW1lcnMnIGxp c3RzIHRvIGFsbG93IGEgdGltZXIgdG8gYWRkIGl0c2VsZgogICAgICBhZ2Fpbiwgd2l0aG91dCBs b2NraW5nIHVwIEVtYWNzIGlmIHRoZSBuZXdseSBhZGRlZCB0aW1lciBpcwpAQCAtNDU3Myw2ICs0 NTc0LDcgQEAgdGltZXJfY2hlY2sgKHZvaWQpCiAgIGVsc2UKICAgICBpZGxlX3RpbWVycyA9IFFu aWw7CiAKKyAgdW5ibG9ja19pbnB1dCAoKTsKICAgVmluaGliaXRfcXVpdCA9IHRlbTsKIAogICBk bwotLSAKMi41LjAKCg== --001a1144ac342b7664051eace58f-- From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 01 11:03:47 2015 Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 15:03:48 +0000 Received: from localhost ([127.0.0.1]:45214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWn67-0005rP-Ou for submit@debbugs.gnu.org; Tue, 01 Sep 2015 11:03:47 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:41461) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWn61-0005rB-LV for 21380@debbugs.gnu.org; Tue, 01 Sep 2015 11:03:41 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NU000F006OIBH00@mtaout27.012.net.il> for 21380@debbugs.gnu.org; Tue, 01 Sep 2015 18:00:23 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NU000AP670NGP60@mtaout27.012.net.il>; Tue, 01 Sep 2015 18:00:23 +0300 (IDT) Date: Tue, 01 Sep 2015 18:03:47 +0300 From: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet Message-id: <83fv2ychbg.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 1 Sep 2015 10:20:11 +0000 > From: Pip Cet > Cc: 21380@debbugs.gnu.org > > Can you show a patch that fixes the original segfault in your use > case? > > Attached. Hmm... isn't that a kludge? Or am I missing something? I thought you intended to recalculate the length on each iteration? > I think we should fix three things: > - concat shouldn't rely on its argument remaining unchanged in length > - the timer list copy should happen with block_input/unblock_input wrapped > around it > - we shouldn't call do_pending_window_change from QUIT [already installed. > Thanks, martin!] > > Any one of these is enough to prevent the original segfault. All but the second > also prevent the bizarre-elisp-induced segfault I came up with later. I think we should make all of these changes. > I'm not sure whether the timer code in timer.el does anything to the > timer list that might count as dangerous, but that's possibly the > only legitimate Lisp user of timer-list. Indeed. And if it does something unsafe, we should fix that. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 01 11:14:16 2015 Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 15:14:16 +0000 Received: from localhost ([127.0.0.1]:45225 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWnGJ-00066G-8z for submit@debbugs.gnu.org; Tue, 01 Sep 2015 11:14:16 -0400 Received: from mail-io0-f170.google.com ([209.85.223.170]:35121) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWnGG-000663-Cs for 21380@debbugs.gnu.org; Tue, 01 Sep 2015 11:14:13 -0400 Received: by ioiz6 with SMTP id z6so4531011ioi.2 for <21380@debbugs.gnu.org>; Tue, 01 Sep 2015 08:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y8yohLojjDk7OJqePZTgBsjwQolYnFaUAJtC9GdlwU8=; b=eWcoYvO894P75tjzIYh9kkA3ETNdjDhQEeUB9i78AGKcVflUKqyDHFgSRA5uTrBYNh Cj0zQBWNa7KNzYbcKagrylX0jwYyrSXCR7zUfzjbi7VOHgAcw9NIk3dDRg5PuU/qjLoD TYl5fdolrLIvR4AW/ek91UKyyrlQGEcQ73XpL9Swp2VOdr/bPZ43f20/Z5/BJvV32wjq CneSWzeVil8HeMIeMOVSDbLOUR/mCd0C/qb3y21/hNwlsIn+YXkgjy+Nuzg19S0kokNQ 2pggilKVygtmQRAuM8p95qA+sfTgM5bF4EZ4oTpq/NdHSaKhftSVuN/Da0WdfqVGmQyY gwNg== MIME-Version: 1.0 X-Received: by 10.107.47.97 with SMTP id j94mr30020429ioo.136.1441120450292; Tue, 01 Sep 2015 08:14:10 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Tue, 1 Sep 2015 08:14:09 -0700 (PDT) In-Reply-To: References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> Date: Tue, 1 Sep 2015 15:14:09 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook From: Pip Cet To: Eli Zaretskii Content-Type: multipart/mixed; boundary=001a1144ac34852304051eb10037 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a1144ac34852304051eb10037 Content-Type: multipart/alternative; boundary=001a1144ac34852300051eb10035 --001a1144ac34852300051eb10035 Content-Type: text/plain; charset=UTF-8 No segfault*. (* - well, one segfault. But I attribute that to extraordinarily bizarre actions even by my standards: attempting to display an unprintable ASCII control character in the echo area. It seems we never make sure that non-standard faces are cached when redisplaying the echo area. Usually this is fine because propertized strings never end up in the echo area (I hope)...) Revised patch attached (use NILP, fix bug number in changelog entry). On Tue, Sep 1, 2015 at 10:20 AM, Pip Cet wrote: > On Mon, Aug 31, 2015 at 2:31 PM, Eli Zaretskii wrote: > >> > Yes for this particular segfault. >> >> Can you show a patch that fixes the original segfault in your use >> case? > > > Attached. Note that either one of those changes should work. I'll test > this patch some more using my original code and see whether it blows up. > > I'm afraid I lost track, what with all the different scenarios >> and potential solutions being thrown at this. We should install the >> fix, assuming it's clean. >> > > I think we should fix three things: > - concat shouldn't rely on its argument remaining unchanged in length > - the timer list copy should happen with block_input/unblock_input > wrapped around it > - we shouldn't call do_pending_window_change from QUIT [already > installed. Thanks, martin!] > > Any one of these is enough to prevent the original segfault. All but the > second also prevent the bizarre-elisp-induced segfault I came up with > later. And I'm perfectly happy for today with the number of hooks called > from QUIT reduced by one, rather than insisting on reducing them to zero > right away. > > > No* for similar segfaults that I think pose equally severe problems: if >> any other function calls concat/copy-sequence on data that is modified by >> window-configuration-change-hook, it should* still be possible to produce >> the segfault. >> >> Emacs gives you enough rope to hang yourself; there's nothing new >> here. We should strive to protect the Emacs internals so that they >> won't cause segfaults, but in user code any bets are off, and "don't >> do that" is a valid response to whoever does such things. >> > > It's always good to know what the philosophy is behind the way the code > works, so thank you for that, really. > > > So it wouldn't even be safe for window-configuration-change-hook to add >> a timer to the timer list, because the outer frame might be in the middle >> of creating a copy of the timer list for some Lisp code that hasn't blocked >> input. (As in my example below) >> >> Futzing with timers from within some hooks is indeed fundamentally >> dangerous. > > > Well, doing anything from window-configuration-change-hook is dangerous. > My idea was to schedule an immediate timer from it to get out of the danger > zone to do the actual work, but that backfired... > > >> But we should still try to minimize the probability of a >> crash, especially when it's Emacs itself who makes the offending copy, >> because people do dangerous things all the time, and expect them to >> work. In this case, blocking input should do, I think. >> > > I agree. > > > I really don't think QUIT should run any Lisp hooks, to be honest. >> >> I don't think this limitation could fly. It will disable a lot of >> useful use patterns, and the outcry will be loud and clear. >> > > Okay. > > > If I'm wrong and QUIT should be able to run Lisp hooks, concat needs to >> be fixed not to rely on its argument's size being unchanged after the >> make_sequence call. >> >> That can't do any harm, so let's do it, too. >> > > Cool. > > >> > As far as I can tell, that should be reproducible. Also as far as I can >> tell, it's merely a matter of luck that an X resize doesn't happen at the >> point where I interrupted the program to artificially trigger the segfault. >> However, I admit that it is a separate issue, less likely to occur in >> practice, and I'll open another bug for it if that's the way you prefer >> things. >> >> But if input is blocked, as it would be in the case of copying >> timer-list inside timer_check, the X events will not be acted upon, >> and the problem will not happen, right? >> > > Indeed, that relies on bizarre elisp code deliberately doing silly > things... > > >> IOW, the above situation is a case of a user shooting herself in the >> foot by having that particular function in the hook and that >> particular code that copies timer-list (which is an internal variable >> unwise users should not touch). Am I right? >> > > I think you are. I'm not sure whether the timer code in timer.el does > anything to the timer list that might count as dangerous, but that's > possibly the only legitimate Lisp user of timer-list. > --001a1144ac34852300051eb10035 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No segfault*.

(* - well, one segfault. But I a= ttribute that to extraordinarily bizarre actions even by my standards: atte= mpting to display an unprintable ASCII control character in the echo area. = It seems we never make sure that non-standard faces are cached when redispl= aying the echo area. Usually this is fine because propertized strings never= end up in the echo area (I hope)...)

Revised patch attac= hed (use NILP, fix bug number in changelog entry).

=

On Tue, Sep= 1, 2015 at 10:20 AM, Pip Cet <pipcet@gmail.com> wrote:
On Mon, Aug = 31, 2015 at 2:31 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Yes for this particular segfault.
Can you show a patch that fixes the original segfault in your use case?

Attached. Note that either one= of those changes should work. I'll test this patch some more using my = original code and see whether it blows up.

I'm afraid I lost track, what with all th= e different scenarios
and potential solutions being thrown at this.=C2=A0 We should install the fix, assuming it's clean.

I = think we should fix three things:
=C2=A0- concat shouldn'= t rely on its argument remaining unchanged in length
=C2=A0- = the timer list copy should happen with block_input/unblock_input wrapped ar= ound it
=C2=A0- we shouldn't call do_pending_window_chang= e from QUIT [already installed. Thanks, martin!]

Any one = of these is enough to prevent the original segfault. All but the second als= o prevent the bizarre-elisp-induced segfault I came up with later. And I= 9;m perfectly happy for today with the number of hooks called from QUIT red= uced by one, rather than insisting on reducing them to zero right away.
=
> No* for similar segfaults that I think pose equally severe problems: i= f any other function calls concat/copy-sequence on data that is modified by= window-configuration-change-hook, it should* still be possible to produce = the segfault.

Emacs gives you enough rope to hang yourself; there's nothing ne= w
here.=C2=A0 We should strive to protect the Emacs internals so that they won't cause segfaults, but in user code any bets are off, and "don= 't
do that" is a valid response to whoever does such things.

It's always good to know what the philos= ophy is behind the way the code works, so thank you for that, really.
> So it wouldn't even be safe for window-configuration-change-hook t= o add a timer to the timer list, because the outer frame might be in the mi= ddle of creating a copy of the timer list for some Lisp code that hasn'= t blocked input. (As in my example below)

Futzing with timers from within some hooks is indeed fundamentally dangerous.

Well, doing anything from= window-configuration-change-hook is dangerous. My idea was to schedule an = immediate timer from it to get out of the danger zone to do the actual work= , but that backfired...
=C2=A0
But we should still try to minimize the probability= of a
crash, especially when it's Emacs itself who makes the offending copy,<= br> because people do dangerous things all the time, and expect them to
work.=C2=A0 In this case, blocking input should do, I think.

I agree.

> I really don't think QUIT should run any Lisp hooks, to be honest.=

I don't think this limitation could fly.=C2=A0 It will disable a= lot of
useful use patterns, and the outcry will be loud and clear.

Okay.

> If I'm wrong and QUIT should be able to run Lisp hooks, concat nee= ds to be fixed not to rely on its argument's size being unchanged after= the make_sequence call.

That can't do any harm, so let's do it, too.

Cool.
=C2=A0
> As far as I can tell, that should be reproducible. Also as far as I ca= n tell, it's merely a matter of luck that an X resize doesn't happe= n at the point where I interrupted the program to artificially trigger the = segfault. However, I admit that it is a separate issue, less likely to occu= r in practice, and I'll open another bug for it if that's the way y= ou prefer things.

But if input is blocked, as it would be in the case of copying
timer-list inside timer_check, the X events will not be acted upon,
and the problem will not happen, right?

Indeed, that relies on bizarre elisp code delibera= tely doing silly things...
=C2=A0
IOW, the above situation is a case of a user shooting herself in the
foot by having that particular function in the hook and that
particular code that copies timer-list (which is an internal variable
unwise users should not touch).=C2=A0 Am I right?

I think you = are. I'm not sure whether the timer code in timer.el does anything to t= he timer list that might count as dangerous, but that's possibly the on= ly legitimate Lisp user of timer-list.

--001a1144ac34852300051eb10035-- --001a1144ac34852304051eb10037 Content-Type: text/x-patch; charset=US-ASCII; name="0001-Fix-potential-race-conditions-Bug-21380.patch" Content-Disposition: attachment; filename="0001-Fix-potential-race-conditions-Bug-21380.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ie1hwtdn0 RnJvbSA3ZGM4YzlkN2E0OTk3NzgxYzA0MDAxMzcxYWMzODRkYjI0YzM3ZTU5IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXAgPHBpcGNldEBnbWFpbC5jb20+CkRhdGU6IFR1ZSwg MSBTZXAgMjAxNSAxMDoxMjozMSArMDAwMApTdWJqZWN0OiBbUEFUQ0hdIEZpeCBwb3RlbnRpYWwg cmFjZSBjb25kaXRpb25zIChCdWcjMjEzODApCgogICAgICAgICoga2V5Ym9hcmQuYyAodGltZXJf Y2hlY2spOiBDYWxsIGBibG9ja19pbnB1dCcgYXJvdW5kIHRoZSBjcmVhdGlvbgoJb2YgdGhlIHRl bXBvcmFyeSB0aW1lciBsaXN0IGNvcHkuCgoJKiBmbnMuYyAoY29uY2F0KTogRG9uJ3QgYXNzdW1l IGFyZ3VtZW50IHNpemUgcmVtYWlucyB1bmNoYW5nZWQKCWFmdGVyIGNhbGwgdG8gYEZtYWtlX2xp c3QnLgotLS0KIHNyYy9mbnMuYyAgICAgIHwgMyArKysKIHNyYy9rZXlib2FyZC5jIHwgMiArKwog MiBmaWxlcyBjaGFuZ2VkLCA1IGluc2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9zcmMvZm5zLmMg Yi9zcmMvZm5zLmMKaW5kZXggMjZhOThhYi4uMTVkOWU2NCAxMDA2NDQKLS0tIGEvc3JjL2Zucy5j CisrKyBiL3NyYy9mbnMuYwpAQCAtNzQ0LDYgKzc0NCw5IEBAIGNvbmNhdCAocHRyZGlmZl90IG5h cmdzLCBMaXNwX09iamVjdCAqYXJncywKIAkgICAgLyogU3RvcmUgdGhpcyBlbGVtZW50IGludG8g dGhlIHJlc3VsdC4gICovCiAJICAgIGlmICh0b2luZGV4IDwgMCkKIAkgICAgICB7CisgICAgICAg ICAgICAgICAgaWYgKE5JTFAgKHRhaWwpKQorICAgICAgICAgICAgICAgICAgYnJlYWs7CisKIAkJ WFNFVENBUiAodGFpbCwgZWx0KTsKIAkJcHJldiA9IHRhaWw7CiAJCXRhaWwgPSBYQ0RSICh0YWls KTsKZGlmZiAtLWdpdCBhL3NyYy9rZXlib2FyZC5jIGIvc3JjL2tleWJvYXJkLmMKaW5kZXggZGFi MzJiMS4uNGI3ZDY3NSAxMDA2NDQKLS0tIGEvc3JjL2tleWJvYXJkLmMKKysrIGIvc3JjL2tleWJv YXJkLmMKQEAgLTQ1NjAsNiArNDU2MCw3IEBAIHRpbWVyX2NoZWNrICh2b2lkKQogCiAgIExpc3Bf T2JqZWN0IHRlbSA9IFZpbmhpYml0X3F1aXQ7CiAgIFZpbmhpYml0X3F1aXQgPSBRdDsKKyAgYmxv Y2tfaW5wdXQgKCk7CiAKICAgLyogV2UgdXNlIGNvcGllcyBvZiB0aGUgdGltZXJzJyBsaXN0cyB0 byBhbGxvdyBhIHRpbWVyIHRvIGFkZCBpdHNlbGYKICAgICAgYWdhaW4sIHdpdGhvdXQgbG9ja2lu ZyB1cCBFbWFjcyBpZiB0aGUgbmV3bHkgYWRkZWQgdGltZXIgaXMKQEAgLTQ1NzMsNiArNDU3NCw3 IEBAIHRpbWVyX2NoZWNrICh2b2lkKQogICBlbHNlCiAgICAgaWRsZV90aW1lcnMgPSBRbmlsOwog CisgIHVuYmxvY2tfaW5wdXQgKCk7CiAgIFZpbmhpYml0X3F1aXQgPSB0ZW07CiAKICAgZG8KLS0g CjIuNS4wCgo= --001a1144ac34852304051eb10037-- From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 01 11:23:01 2015 Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 15:23:01 +0000 Received: from localhost ([127.0.0.1]:45229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWnOn-0006IC-5r for submit@debbugs.gnu.org; Tue, 01 Sep 2015 11:23:01 -0400 Received: from mail-qk0-f179.google.com ([209.85.220.179]:35412) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWnOl-0006I3-ID for 21380@debbugs.gnu.org; Tue, 01 Sep 2015 11:23:00 -0400 Received: by qkcj187 with SMTP id j187so45013272qkc.2 for <21380@debbugs.gnu.org>; Tue, 01 Sep 2015 08:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t1zfl2Y4ibimDDScJ2QMynn2QQBRAkPUDQvPT3bbjg4=; b=LhCBAQre7zr33VHEN8YItex61QfzPZj0XutRdsaIQcyOqD6B/XHDDEdhSlvVEl90de NaViKzYTkuGYdb/U788QmvdWQp+UNdMKO3/up8JPTriZWNDpAsgqKdZ3cVAkYHWYb+9J pVp51uEqNqyPIgnqcNB00y2mVyZ0s5uPkzNNdNAcIt/dsf/ESC51kLQMcqIKdTjno2QV 5NjWh+RWW39Ax4XqHLTgP/AkF9i6B/qqlnB1aBKowHhExTeGQyOeUEUYVqzGBsEmupxc 2FIe5TaK4spEnErMxgDVp1RblRSbY8bEEq014eVnEw2zCL99H5ePVIt4yU/L48sxAqZ2 YTKw== MIME-Version: 1.0 X-Received: by 10.13.202.66 with SMTP id m63mr27883858ywd.127.1441120978861; Tue, 01 Sep 2015 08:22:58 -0700 (PDT) Received: by 10.37.74.200 with HTTP; Tue, 1 Sep 2015 08:22:58 -0700 (PDT) In-Reply-To: <83fv2ychbg.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> Date: Tue, 1 Sep 2015 15:22:58 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook From: Pip Cet To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a11481518060701051eb12022 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11481518060701051eb12022 Content-Type: text/plain; charset=UTF-8 On Tue, Sep 1, 2015 at 3:03 PM, Eli Zaretskii wrote: > > Date: Tue, 1 Sep 2015 10:20:11 +0000 > > From: Pip Cet > > Cc: 21380@debbugs.gnu.org > > > > Can you show a patch that fixes the original segfault in your use > > case? > > > > Attached. > > Hmm... isn't that a kludge? > It is. It replaces segfaults by incorrect results. Or am I missing something? I thought you > intended to recalculate the length on each iteration? > If you can think of a good way of doing that, I'd be grateful. I can't, because Flength calls QUIT, too, so there's no guarantee its results are still valid when it's done. All we could do, as far as I can see, is add an extra call to Flength() which will slow things down and sometimes but not always make the risky thing the user is attempting work. Other than that, a non-segfault with an incorrect result is all we can give the user, I fear. --001a11481518060701051eb12022 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 1, 2015 at 3:03 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>=C2=A0 =C2=A0 =C2=A0Can you show a patch that fixes = the original segfault in your use
>=C2=A0 =C2=A0 =C2=A0case?
>
> Attached.

Hmm... isn't that a kludge?

It is. It replaces segfaults by incorrect results.
Or am I missing something?=C2=A0 I = thought you
intended to recalculate the length on each iteration?
=
If you can think of a good way of doing that, I'd be gra= teful. I can't, because Flength calls QUIT, too, so there's no guar= antee its results are still valid when it's done.

All we could do, as far as I can see, is add an extra call to Fleng= th() which will slow things down and sometimes but not always make the risk= y thing the user is attempting work. Other than that, a non-segfault with a= n incorrect result is all we can give the user, I fear.
--001a11481518060701051eb12022-- From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 01 12:01:08 2015 Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 16:01:08 +0000 Received: from localhost ([127.0.0.1]:45252 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWnzc-0007CB-Bq for submit@debbugs.gnu.org; Tue, 01 Sep 2015 12:01:08 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:46915) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWnzW-0007Bb-Gr for 21380@debbugs.gnu.org; Tue, 01 Sep 2015 12:01:02 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NU000O009TYTX00@mtaout29.012.net.il> for 21380@debbugs.gnu.org; Tue, 01 Sep 2015 19:01:15 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NU000OBZ9U2IO00@mtaout29.012.net.il>; Tue, 01 Sep 2015 19:01:15 +0300 (IDT) Date: Tue, 01 Sep 2015 19:01:08 +0300 From: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet Message-id: <838u8qcenv.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 1 Sep 2015 15:22:58 +0000 > From: Pip Cet > Cc: 21380@debbugs.gnu.org > > Or am I missing something? I thought you > intended to recalculate the length on each iteration? > > If you can think of a good way of doing that, I'd be grateful. I can't, because > Flength calls QUIT, too, so there's no guarantee its results are still valid > when it's done. > > All we could do, as far as I can see, is add an extra call to Flength() which > will slow things down and sometimes but not always make the risky thing the > user is attempting work. Other than that, a non-segfault with an incorrect > result is all we can give the user, I fear. So maybe we should introduce a special copy_sequence_no_quit function that never calls QUIT, and then use it for copying the timer lists. Timer lists are never too long, so that shouldn't be a problem. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 01 12:03:08 2015 Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 16:03:08 +0000 Received: from localhost ([127.0.0.1]:45256 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWo1b-0007F5-Ke for submit@debbugs.gnu.org; Tue, 01 Sep 2015 12:03:08 -0400 Received: from mail-ig0-f173.google.com ([209.85.213.173]:34802) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWo1W-0007Ev-BF for 21380@debbugs.gnu.org; Tue, 01 Sep 2015 12:03:06 -0400 Received: by igcpb10 with SMTP id pb10so4627307igc.1 for <21380@debbugs.gnu.org>; Tue, 01 Sep 2015 09:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lpLfFMzsu6hwGgmB7RF8hsc/r26tELZGYw9T5yO4wvs=; b=cRv1IYwkn7olAIMaGcOc/U4WLKpkKrTM9trj8RktOhMRBzaPwUzfBxb8WDPL29E2te XV94P0aP71XPWd+J/181/TUZfC/3bnqFCU4Z4ykxcml9jZidjDCRKp6XYhN1tucVMtcK JZUCkt8CF9+nbE9uNm1PfUyNDficsPA1sjJANqxahxRS1ku7dZBI8mEcIpxrx09EWFo3 mzZEjR9DTnviNfx7owsqdMZwyKLixxM2qJnXG46eq1fN2jqrtsOtY0dngDT3N90aGOZR ZgdK23GqEPjeTxoQRo7OBohmuJG/ET0vL+nZ1MGVXrNe4AFYtulg6IrZyhNzAU7JHlAM S7yA== MIME-Version: 1.0 X-Received: by 10.50.97.33 with SMTP id dx1mr3065315igb.1.1441123379669; Tue, 01 Sep 2015 09:02:59 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Tue, 1 Sep 2015 09:02:59 -0700 (PDT) In-Reply-To: <838u8qcenv.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> <838u8qcenv.fsf@gnu.org> Date: Tue, 1 Sep 2015 16:02:59 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook From: Pip Cet To: Eli Zaretskii Content-Type: multipart/alternative; boundary=047d7b10c8891f73ab051eb1afa7 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --047d7b10c8891f73ab051eb1afa7 Content-Type: text/plain; charset=UTF-8 On Tue, Sep 1, 2015 at 4:01 PM, Eli Zaretskii wrote: > So maybe we should introduce a special copy_sequence_no_quit function > that never calls QUIT, and then use it for copying the timer lists. > How would that be different from calling block_input () and binding Vinhibit_quit around the call to copy_sequence? --047d7b10c8891f73ab051eb1afa7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 1, 2015 at 4:01 PM, Eli Zaretskii <eliz@gnu.org> wrote:
So maybe we should introduce a special copy_sequence_no_quit functio= n
that never calls QUIT, and then use it for copying the timer lists.

How would that be different from calling block= _input () and binding Vinhibit_quit around the call to copy_sequence?
--047d7b10c8891f73ab051eb1afa7-- From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 01 12:04:19 2015 Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 16:04:19 +0000 Received: from localhost ([127.0.0.1]:45260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWo2l-0007Go-HT for submit@debbugs.gnu.org; Tue, 01 Sep 2015 12:04:19 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:50514) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWo2i-0007Ge-GJ for 21380@debbugs.gnu.org; Tue, 01 Sep 2015 12:04:18 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NU000G009UBUZ00@a-mtaout21.012.net.il> for 21380@debbugs.gnu.org; Tue, 01 Sep 2015 19:04:15 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NU000G879Z2UD20@a-mtaout21.012.net.il>; Tue, 01 Sep 2015 19:04:15 +0300 (IDT) Date: Tue, 01 Sep 2015 19:04:26 +0300 From: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet Message-id: <837foaceid.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 1 Sep 2015 15:14:09 +0000 > From: Pip Cet > Cc: 21380@debbugs.gnu.org > > (* - well, one segfault. But I attribute that to extraordinarily bizarre > actions even by my standards: attempting to display an unprintable ASCII > control character in the echo area. Is this reproducible? If so, please submit a separate bug report with a recipe. > It seems we never make sure that > non-standard faces are cached when redisplaying the echo area. I don't see how this can happen, since the face cache is per-frame, not per-window or buffer. > Usually this is fine because propertized strings never end up in the > echo area (I hope)...) The echo area is a normal buffer, so any face can be used in it. See, for example, the message printed by info.el after "i SOMETHING RET". From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 01 12:23:30 2015 Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 16:23:30 +0000 Received: from localhost ([127.0.0.1]:45272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWoLK-0007hC-GG for submit@debbugs.gnu.org; Tue, 01 Sep 2015 12:23:30 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:57916) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWoLI-0007h3-88 for 21380@debbugs.gnu.org; Tue, 01 Sep 2015 12:23:29 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NU000300A93KU00@mtaout24.012.net.il> for 21380@debbugs.gnu.org; Tue, 01 Sep 2015 19:15:39 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NU000MF2AI3TY80@mtaout24.012.net.il>; Tue, 01 Sep 2015 19:15:39 +0300 (IDT) Date: Tue, 01 Sep 2015 19:23:38 +0300 From: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet Message-id: <831teicdmd.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> <838u8qcenv.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 1 Sep 2015 16:02:59 +0000 > From: Pip Cet > Cc: 21380@debbugs.gnu.org > > On Tue, Sep 1, 2015 at 4:01 PM, Eli Zaretskii wrote: > > So maybe we should introduce a special copy_sequence_no_quit function > that never calls QUIT, and then use it for copying the timer lists. > > How would that be different from calling block_input () and binding > Vinhibit_quit around the call to copy_sequence? That only prevents us from reading new events from the X socket, but what if some signal that is already pending invokes some Lisp? From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 01 12:56:08 2015 Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 16:56:08 +0000 Received: from localhost ([127.0.0.1]:45307 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWoqu-0008Sn-1L for submit@debbugs.gnu.org; Tue, 01 Sep 2015 12:56:08 -0400 Received: from mail-ig0-f175.google.com ([209.85.213.175]:33720) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWoqr-0008Sf-OU for 21380@debbugs.gnu.org; Tue, 01 Sep 2015 12:56:06 -0400 Received: by igbkq10 with SMTP id kq10so5843985igb.0 for <21380@debbugs.gnu.org>; Tue, 01 Sep 2015 09:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hfp/QfR5ivNJ3o6IYxtuHIzWTo8VuPuZaJ2R0+hExII=; b=dDzQp9g8PIA+L1153/veMSuNwqFuML0VhMsgVxbrj9qk81RnFeAPEtziN7U5MAy9z3 pkgekUH0cocnuMGQy+9AtXcWRBlmYBMiAr00d3DJTkCdwagYJ7/oLwrfxZnHXDVmNMPl 9ufJQJKZ6BkkhMUMYkyvUObdQ/aV4zUIzU0Qz0QPIag9GD/yDkQvVWBEWl2iULRaEviL 1/Q28BdtzJPxjvSdIZKcl/lpSgh8o2ACXqm9cMxI36cOWPPhoGy3xattcbKu9pOmfVzd DmRIXMpR6M0l+MWxbP2+CKP5at49Km5mNJ6uGc6dTK+6oyiDXfKjRZwgst3dlPhv4MPd AkgA== MIME-Version: 1.0 X-Received: by 10.50.112.227 with SMTP id it3mr3598288igb.93.1441126564865; Tue, 01 Sep 2015 09:56:04 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Tue, 1 Sep 2015 09:56:04 -0700 (PDT) In-Reply-To: <837foaceid.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <837foaceid.fsf@gnu.org> Date: Tue, 1 Sep 2015 16:56:04 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook From: Pip Cet To: Eli Zaretskii Content-Type: multipart/alternative; boundary=089e0102f83ef9abc7051eb26cee X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e0102f83ef9abc7051eb26cee Content-Type: text/plain; charset=UTF-8 On Tue, Sep 1, 2015 at 4:04 PM, Eli Zaretskii wrote: > > Date: Tue, 1 Sep 2015 15:14:09 +0000 > > From: Pip Cet > > Cc: 21380@debbugs.gnu.org > > > > (* - well, one segfault. But I attribute that to extraordinarily bizarre > > actions even by my standards: attempting to display an unprintable ASCII > > control character in the echo area. > > Is this reproducible? If so, please submit a separate bug report with > a recipe. > #21394. > > > Usually this is fine because propertized strings never end up in the > > echo area (I hope)...) > > The echo area is a normal buffer, so any face can be used in it. See, > for example, the message printed by info.el after "i SOMETHING RET". > Thanks for explaining! You're right, then, it's a bug. > That only prevents us from reading new events from the X socket, but > what if some signal that is already pending invokes some Lisp? I don't understand. How can we call "some signal that is already pending" (I'm not sure what that means. A unix signal? Or just something that sets pending_signals to a true value? Or an atimer?) when input_blocked_p () is true? The only thing gobble_input () does in that case is store_user_signal_events (), which doesn't call any Lisp. The only code path that I see that's potentially dangerous is that atimers appear to be executed even if input is blocked. --089e0102f83ef9abc7051eb26cee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 1, 2015 at 4:04 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Date: Tue, 1 Sep 2= 015 15:14:09 +0000
> From: Pip Cet <pipcet@gmail.com>
> Cc: 21380@debbugs.gnu.org=
>
> (* - well, one segfault. But I attribute that = to extraordinarily bizarre
> actions even by my standards: attempting to display an unprintable ASC= II
> control character in the echo area.

Is this reproducible?=C2=A0 If so, please submit a separate bug repo= rt with
a recipe.

#21394.
=C2=A0
> Usually this is fine because propertized strings never end up in the > echo area (I hope)...)

The echo area is a normal buffer, so any face can be used in it.=C2= =A0 See,
for example, the message printed by info.el after "i SOMETHING RET&quo= t;.

Thanks for explaini= ng! You're right, then, it's a bug.

> That only prevents us from reading new events from the X sock= et, but
> what if some signal that is already pending invokes some Li= sp?

I don't understand. How can= we call "some signal that is already pending" (I'm not sure = what that means. A unix signal? Or just something that sets pending_signals= to a true value? Or an atimer?) when input_blocked_p () is true? The only = thing gobble_input () does in that case is store_user_signal_events (), whi= ch doesn't call any Lisp.

The o= nly code path that I see that's potentially dangerous is that atimers a= ppear to be executed even if input is blocked.
--089e0102f83ef9abc7051eb26cee-- From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 01 13:19:17 2015 Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 17:19:17 +0000 Received: from localhost ([127.0.0.1]:45318 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWpDI-0000ZN-VH for submit@debbugs.gnu.org; Tue, 01 Sep 2015 13:19:17 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:50455) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWpDG-0000ZE-Qq for 21380@debbugs.gnu.org; Tue, 01 Sep 2015 13:19:15 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NU000J00DCX2T00@mtaout29.012.net.il> for 21380@debbugs.gnu.org; Tue, 01 Sep 2015 20:19:31 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NU000G9MDGI0W50@mtaout29.012.net.il>; Tue, 01 Sep 2015 20:19:31 +0300 (IDT) Date: Tue, 01 Sep 2015 20:19:25 +0300 From: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet Message-id: <83vbbuawgy.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <837foaceid.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 1 Sep 2015 16:56:04 +0000 > From: Pip Cet > Cc: 21380@debbugs.gnu.org > > > That only prevents us from reading new events from the X socket, but > > what if some signal that is already pending invokes some Lisp? > > I don't understand. How can we call "some signal that is already pending" (I'm > not sure what that means. A unix signal? Or just something that sets > pending_signals to a true value? Or an atimer?) I meant atimers, sorry for being unclear. See process_pending_signals. > The only code path that I see that's potentially dangerous is that atimers > appear to be executed even if input is blocked. Yes, that's exactly what bothered me. Not calling QUIT prevents that. Alternatively, we could turn off atimers (by calling turn_on_atimers) while Fcopy_sequence runs. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 01 16:48:23 2015 Received: (at 21380) by debbugs.gnu.org; 1 Sep 2015 20:48:23 +0000 Received: from localhost ([127.0.0.1]:45452 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWsTe-0006vp-Jj for submit@debbugs.gnu.org; Tue, 01 Sep 2015 16:48:22 -0400 Received: from mail-ig0-f181.google.com ([209.85.213.181]:38119) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWsTc-0006vh-M7 for 21380@debbugs.gnu.org; Tue, 01 Sep 2015 16:48:21 -0400 Received: by igbut12 with SMTP id ut12so10829050igb.1 for <21380@debbugs.gnu.org>; Tue, 01 Sep 2015 13:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+PS0IoLVGdfGQbl3ua74NXK3mrsBD/VwKbcdVZ9HA6A=; b=Tp/4LKLvsbPym4+abzDCrjl5MeFI9cFEIVLSv0W3UumgtAkHXXOHpZrYnqy6SPMv6B viyJUeaPvxv4nUVh1SZOZxU19VUGG8WrmAXHkLFWRSvKF1BkBSz1d8wzPZB1Oej2p16n ZbnrX+avByy3pk9R/WJE7gl0R7/0b5h6Auj/2SECddFrQ5xZ5drrC9dBhJOw0z2JR+Nv wbTnAKVdmD5iVPYBq7ehLtcJi+Nyz8T4cqS8wDCjqDDheOMJrKo+r+dcjjJjFfa55lOI pGhZEpj/dJ8upADwaWGWenITgn5k3cJxO1IC1sbIpg/ApTWK2+/ZT/S/x4VknYAshOTr NEKw== MIME-Version: 1.0 X-Received: by 10.50.137.100 with SMTP id qh4mr148979igb.1.1441140498965; Tue, 01 Sep 2015 13:48:18 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Tue, 1 Sep 2015 13:48:18 -0700 (PDT) In-Reply-To: <83vbbuawgy.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <837foaceid.fsf@gnu.org> <83vbbuawgy.fsf@gnu.org> Date: Tue, 1 Sep 2015 20:48:18 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook From: Pip Cet To: Eli Zaretskii Content-Type: multipart/mixed; boundary=001a11c31f74834d6b051eb5abd4 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11c31f74834d6b051eb5abd4 Content-Type: multipart/alternative; boundary=001a11c31f74834d66051eb5abd2 --001a11c31f74834d66051eb5abd2 Content-Type: text/plain; charset=UTF-8 On Tue, Sep 1, 2015 at 5:19 PM, Eli Zaretskii wrote: > > The only code path that I see that's potentially dangerous is that > atimers > > appear to be executed even if input is blocked. > > Yes, that's exactly what bothered me. Not calling QUIT prevents that. > > Alternatively, we could turn off atimers (by calling turn_on_atimers) > while Fcopy_sequence runs. > I think that would be a better solution. I've done a quick grep for the current atimers and at first glance they appear to be okay, but obviously that's no guarantee for the future. It might be worth thinking about block_input_and_atimers (). I think it's safe to assume that Lisp timers are only checked if atimers are enabled. If it isn't, I think the best way forward is to write block_input_and_atimers () and lock atimers with a counter just like input is. --001a11c31f74834d66051eb5abd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 1, 2015 at 5:19 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> The only code path that I see that's potentially dangerous is that= atimers
> appear to be executed even if input is blocked.

Yes, that's exactly what bothered me.=C2=A0 Not calling QUIT pre= vents that.

Alternatively, we could turn off atimers (by calling turn_on_atimers)
while Fcopy_sequence runs.

I think that would = be a better solution. I've done a quick grep for the current atimers an= d at first glance they appear to be okay, but obviously that's no guara= ntee for the future. It might be worth thinking about block_input_and_atime= rs ().

I think it's safe to ass= ume that Lisp timers are only checked if atimers are enabled. If it isn'= ;t, I think the best way forward is to write block_input_and_atimers () and= lock atimers with a counter just like input is.

--001a11c31f74834d66051eb5abd2-- --001a11c31f74834d6b051eb5abd4 Content-Type: text/x-patch; charset=US-ASCII; name="0001-Fix-potential-race-conditions-Bug-21380.patch" Content-Disposition: attachment; filename="0001-Fix-potential-race-conditions-Bug-21380.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ie1ttzd00 RnJvbSA2NzhiZGJhNTVlNGEwN2UzYmFlYmFkMjA0YzlmZTVjNTVjOTliM2QzIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXAgPHBpcGNldEBnbWFpbC5jb20+CkRhdGU6IFR1ZSwg MSBTZXAgMjAxNSAyMDo0Mjo0NCArMDAwMApTdWJqZWN0OiBbUEFUQ0hdIEZpeCBwb3RlbnRpYWwg cmFjZSBjb25kaXRpb25zIChCdWcjMjEzODApCgogICAgICAgICoga2V5Ym9hcmQuYyAodGltZXJf Y2hlY2spOiBDYWxsIGBibG9ja19pbnB1dCcgYW5kIHR1cm4gb2ZmCglhdGltZXJzIGFyb3VuZCB0 aGUgY3JlYXRpb24gb2YgdGhlIHRlbXBvcmFyeSB0aW1lciBsaXN0IGNvcHkuCgoJKiBmbnMuYyAo Y29uY2F0KTogRG9uJ3QgYXNzdW1lIGFyZ3VtZW50IHNpemUgcmVtYWlucyB1bmNoYW5nZWQKCWFm dGVyIGNhbGwgdG8gYEZtYWtlX2xpc3QnLiAgUmV0dXJuIGluY29ycmVjdCByZXN1bHRzIChidXQg ZG9uJ3QKCXNlZ2ZhdWx0KSBpbiB0aGF0IGNhc2UuCi0tLQogc3JjL2Zucy5jICAgICAgfCAzICsr Kwogc3JjL2tleWJvYXJkLmMgfCA0ICsrKysKIDIgZmlsZXMgY2hhbmdlZCwgNyBpbnNlcnRpb25z KCspCgpkaWZmIC0tZ2l0IGEvc3JjL2Zucy5jIGIvc3JjL2Zucy5jCmluZGV4IDI2YTk4YWIuLjE1 ZDllNjQgMTAwNjQ0Ci0tLSBhL3NyYy9mbnMuYworKysgYi9zcmMvZm5zLmMKQEAgLTc0NCw2ICs3 NDQsOSBAQCBjb25jYXQgKHB0cmRpZmZfdCBuYXJncywgTGlzcF9PYmplY3QgKmFyZ3MsCiAJICAg IC8qIFN0b3JlIHRoaXMgZWxlbWVudCBpbnRvIHRoZSByZXN1bHQuICAqLwogCSAgICBpZiAodG9p bmRleCA8IDApCiAJICAgICAgeworICAgICAgICAgICAgICAgIGlmIChOSUxQICh0YWlsKSkKKyAg ICAgICAgICAgICAgICAgIGJyZWFrOworCiAJCVhTRVRDQVIgKHRhaWwsIGVsdCk7CiAJCXByZXYg PSB0YWlsOwogCQl0YWlsID0gWENEUiAodGFpbCk7CmRpZmYgLS1naXQgYS9zcmMva2V5Ym9hcmQu YyBiL3NyYy9rZXlib2FyZC5jCmluZGV4IGRhYjMyYjEuLjRjZTgzMGQgMTAwNjQ0Ci0tLSBhL3Ny Yy9rZXlib2FyZC5jCisrKyBiL3NyYy9rZXlib2FyZC5jCkBAIC00NTYwLDYgKzQ1NjAsOCBAQCB0 aW1lcl9jaGVjayAodm9pZCkKIAogICBMaXNwX09iamVjdCB0ZW0gPSBWaW5oaWJpdF9xdWl0Owog ICBWaW5oaWJpdF9xdWl0ID0gUXQ7CisgIGJsb2NrX2lucHV0ICgpOworICB0dXJuX29uX2F0aW1l cnMgKGZhbHNlKTsKIAogICAvKiBXZSB1c2UgY29waWVzIG9mIHRoZSB0aW1lcnMnIGxpc3RzIHRv IGFsbG93IGEgdGltZXIgdG8gYWRkIGl0c2VsZgogICAgICBhZ2Fpbiwgd2l0aG91dCBsb2NraW5n IHVwIEVtYWNzIGlmIHRoZSBuZXdseSBhZGRlZCB0aW1lciBpcwpAQCAtNDU3Myw2ICs0NTc1LDgg QEAgdGltZXJfY2hlY2sgKHZvaWQpCiAgIGVsc2UKICAgICBpZGxlX3RpbWVycyA9IFFuaWw7CiAK KyAgdHVybl9vbl9hdGltZXJzICh0cnVlKTsKKyAgdW5ibG9ja19pbnB1dCAoKTsKICAgVmluaGli aXRfcXVpdCA9IHRlbTsKIAogICBkbwotLSAKMi41LjAKCg== --001a11c31f74834d6b051eb5abd4-- From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 02 03:02:39 2015 Received: (at 21380) by debbugs.gnu.org; 2 Sep 2015 07:02:39 +0000 Received: from localhost ([127.0.0.1]:45825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZX247-0007VF-Ix for submit@debbugs.gnu.org; Wed, 02 Sep 2015 03:02:39 -0400 Received: from mout.gmx.net ([212.227.17.21]:52661) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZX245-0007V7-H6 for 21380@debbugs.gnu.org; Wed, 02 Sep 2015 03:02:38 -0400 Received: from [93.82.9.77] ([93.82.9.77]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lj61K-1YyETa0PPS-00dFMK; Wed, 02 Sep 2015 09:02:36 +0200 Message-ID: <55E69F07.9060006@gmx.at> Date: Wed, 02 Sep 2015 09:02:31 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii , Pip Cet Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> <838u8qcenv.fsf@gnu.org> In-Reply-To: <838u8qcenv.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:XX5q8dMJbKs+JaSPdnhTueagrCVWA5i6dN2q/dOERhnY+lrbELc bIGzP7hqdlMA6MPUSxo82kWfp+72xUws3+bMQNIPEmYq1qaxd+iBPx6HDCW77bCo/BxWhYE 7uEPcgSwv/aYy61Gg8D9Rd5N3WOgK+qoPRnp6gwTelkEZFxeZ+NIKP6o4Ob5Ur+Ba8IMSbH Wm2CnEEjktqWoZRrlXeXQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:ImCE8HnZEcc=:hYPxZI01125wmmwgHnnOo4 hZXvnW4yp7hm7O93PEzAYYBCFnrfqhYU8sYrfDyNrzZqVIlPlnqXbjFY4JVm49RTP4JeOQAAc 2UFlwsm5JLTuCvSJEuvyfymu5wzbASeS+K5fqCGTTapl4FxcdaXpOWYfdMyaJEgeioRTua7Gx bqdkG8eWwEjFe2ZWgeFggC4kM8yUjd9MBfvpTMaCYTeY/LBCIVRpd6neLa1V1XpxQNepIlzb/ 2aSgsdX9GAlbB+qch3F6log2jD75ybuPh8yeEw2fdQGInM2SlYyHIRBrnFWT+kAcGm8tk1mc8 orlkeQpj7GHaFcevDHK/Qs8NMNE7vLWlbqSAgyhExQFQ0YJo4oBnwRKNXjlpa7OD2Jbyj6LGI AzzvuQSizqoITVOgip/jdGftJdoxDtSr82+3rNoZivfzybrRzKwlb6iGEC2PcuHWrheiVFIsA E6BZTs6zGsTqN8sEr+Jad6bxpVpvKkSojJ3v+WivSuAYCCN/6fkEESmcOuTXaySlQP+LOV1jg G27M8D1sjDWK2oGhqPim4iEg1ztwCvd2JLJcL5bfWNx8AGHI2b8AfEusbOuBjHpbib1PuCoJA RMAjsmE67R3PJkWho9mFmgSzlIyBjcG/qLwUCxln6fUJK/WoBXPmJ0vLF3E9AB8igJA96YHns R5I5+ktiOlERBpOqepk9jgm7I/GoBPEQk94ugoyY3vCVpVGYlBgPsj/OAVPnxo5bNqdmkwSGi T2m7R+wiXqtucGOGvKe2DMBM+zabkb9I25Nk5A== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > So maybe we should introduce a special copy_sequence_no_quit function > that never calls QUIT, and then use it for copying the timer lists. Yes. > Timer lists are never too long, so that shouldn't be a problem. Why do you think that copy_sequence_no_quit would be slower than Fcopy_sequence? The problem of copy_sequence_no_quit would be with circularity, not with length. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 02 10:33:01 2015 Received: (at 21380) by debbugs.gnu.org; 2 Sep 2015 14:33:01 +0000 Received: from localhost ([127.0.0.1]:46583 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZX95w-0002hz-Q6 for submit@debbugs.gnu.org; Wed, 02 Sep 2015 10:33:01 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:39490) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZX95u-0002hp-Hv for 21380@debbugs.gnu.org; Wed, 02 Sep 2015 10:32:59 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NU200M000A96B00@mtaout29.012.net.il> for 21380@debbugs.gnu.org; Wed, 02 Sep 2015 17:32:32 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NU200GC70E8OR80@mtaout29.012.net.il>; Wed, 02 Sep 2015 17:32:32 +0300 (IDT) Date: Wed, 02 Sep 2015 17:32:13 +0300 From: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook In-reply-to: <55E69F07.9060006@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83h9ncc2oi.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> <838u8qcenv.fsf@gnu.org> <55E69F07.9060006@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 02 Sep 2015 09:02:31 +0200 > From: martin rudalics > CC: 21380@debbugs.gnu.org > > > So maybe we should introduce a special copy_sequence_no_quit function > > that never calls QUIT, and then use it for copying the timer lists. > > Yes. I think we prefer the alternative that just blocks input and atimers instead. > > Timer lists are never too long, so that shouldn't be a problem. > > Why do you think that copy_sequence_no_quit would be slower than > Fcopy_sequence? The problem of copy_sequence_no_quit would be with > circularity, not with length. Sorry for being unclear. I meant that the call to QUIT in Fcopy_sequence is to allow the user to interrupt a too long copy, so I think it won't be missed with timer lists, which are normally short. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 02 11:08:08 2015 Received: (at 21380) by debbugs.gnu.org; 2 Sep 2015 15:08:08 +0000 Received: from localhost ([127.0.0.1]:46589 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZX9dw-0003Wu-6Z for submit@debbugs.gnu.org; Wed, 02 Sep 2015 11:08:08 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:43817) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZX9dq-0003WP-1P for 21380@debbugs.gnu.org; Wed, 02 Sep 2015 11:08:06 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NU200J00223KB00@mtaout26.012.net.il> for 21380@debbugs.gnu.org; Wed, 02 Sep 2015 18:10:11 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NU200BEY24YSA90@mtaout26.012.net.il>; Wed, 02 Sep 2015 18:10:11 +0300 (IDT) Date: Wed, 02 Sep 2015 18:08:00 +0300 From: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet Message-id: <83a8t4c10v.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <837foaceid.fsf@gnu.org> <83vbbuawgy.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 1 Sep 2015 20:48:18 +0000 > From: Pip Cet > Cc: 21380@debbugs.gnu.org > > Alternatively, we could turn off atimers (by calling turn_on_atimers) > while Fcopy_sequence runs. > > > I think that would be a better solution. I've done a quick grep for the current > atimers and at first glance they appear to be okay, but obviously that's no > guarantee for the future. It might be worth thinking about > block_input_and_atimers (). > > I think it's safe to assume that Lisp timers are only checked if atimers are > enabled. Those are two completely separate and independent features, so no, it's not safe to make that assumption. Not sure why you need to assume that, though. > If it isn't, I think the best way forward is to write > block_input_and_atimers () and lock atimers with a counter just like input is. Not sure I follow you. Are you saying that just calling block_input followed by turn_on_atimers is somehow not enough to prevent some Lisp from changing Vtimer_list under our feet? > --- a/src/fns.c > +++ b/src/fns.c > @@ -744,6 +744,9 @@ concat (ptrdiff_t nargs, Lisp_Object *args, > /* Store this element into the result. */ > if (toindex < 0) > { > + if (NILP (tail)) > + break; > + Is this part still needed? If so, can you explain in what situation it is needed? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 02 12:09:56 2015 Received: (at 21380) by debbugs.gnu.org; 2 Sep 2015 16:09:56 +0000 Received: from localhost ([127.0.0.1]:46639 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXAbj-00054w-QY for submit@debbugs.gnu.org; Wed, 02 Sep 2015 12:09:56 -0400 Received: from mail-io0-f173.google.com ([209.85.223.173]:35474) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXAbh-00054n-Oa for 21380@debbugs.gnu.org; Wed, 02 Sep 2015 12:09:54 -0400 Received: by ioiz6 with SMTP id z6so25751088ioi.2 for <21380@debbugs.gnu.org>; Wed, 02 Sep 2015 09:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h10uoZxl6T8Jt3RUQjeBVMNDkonBtVa5xYlCSXbTvmI=; b=jWhiQX++mc2gJgxUqU3DOCSL/A+o0d/GMleptrovnmwcPCAASErgaRqCcuteKfbypA gYqBFdoo/oY++6UBHqvdf6KERwhPapWdme+fuB01U/QUbzmyy89UeKXcbILWCifkd10s sXdsVMnjx6fnUxGWVxqkxA8r2AaJh5IAf2eZ5XxpVnBvb885sKm/ggZIWCMoldYTakx4 Ynzx3A0oQTAzKpCME5mSNDXjVDfXeh3MA6CgZqylwomtXhD/GGsQf9yvwBcQ4JXT/j9j a52XYU4kZjzhRYeWwqeIuUXUQhHldWikXj0fm7iJuF5oLGqUavD7ASPIUcFPz6m2TjgF HcmQ== MIME-Version: 1.0 X-Received: by 10.107.163.19 with SMTP id m19mr41758552ioe.65.1441210193182; Wed, 02 Sep 2015 09:09:53 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Wed, 2 Sep 2015 09:09:53 -0700 (PDT) In-Reply-To: <83a8t4c10v.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <837foaceid.fsf@gnu.org> <83vbbuawgy.fsf@gnu.org> <83a8t4c10v.fsf@gnu.org> Date: Wed, 2 Sep 2015 16:09:53 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook From: Pip Cet To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a114035589c8631051ec5e5ef X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a114035589c8631051ec5e5ef Content-Type: text/plain; charset=UTF-8 On Wed, Sep 2, 2015 at 3:08 PM, Eli Zaretskii wrote: > > Date: Tue, 1 Sep 2015 20:48:18 +0000 > > From: Pip Cet > > Cc: 21380@debbugs.gnu.org > > > > Alternatively, we could turn off atimers (by calling turn_on_atimers) > > while Fcopy_sequence runs. > > > > > > I think that would be a better solution. I've done a quick grep for the > current > > atimers and at first glance they appear to be okay, but obviously that's > no > > guarantee for the future. It might be worth thinking about > > block_input_and_atimers (). > > > > I think it's safe to assume that Lisp timers are only checked if atimers > are > > enabled. > > Those are two completely separate and independent features, so no, > it's not safe to make that assumption. Not sure why you need to > assume that, though. > So we can call turn_on_atimers (true) without potentially enabling atimers in a critical section. My assumption was that the reason we have both Lisp timers and atimers is that atimers run strictly more often than Lisp timers. > > If it isn't, I think the best way forward is to write > > block_input_and_atimers () and lock atimers with a counter just like > input is. > > Not sure I follow you. Are you saying that just calling block_input > followed by turn_on_atimers is somehow not enough to prevent some Lisp > from changing Vtimer_list under our feet? > I'm not saying that, no, but if another function disables atimers, then runs Lisp timers, then does something critical that needs atimers to be disabled, it might break. > --- a/src/fns.c > > +++ b/src/fns.c > > @@ -744,6 +744,9 @@ concat (ptrdiff_t nargs, Lisp_Object *args, > > /* Store this element into the result. */ > > if (toindex < 0) > > { > > + if (NILP (tail)) > > + break; > > + > > Is this part still needed? As far as I know, the other two fixes are sufficient. It's needed in case someone calls copy_sequence on a list that's messed with by code run from a hook from QUIT, and merely succeeds in avoiding a segfault and producing incorrect results instead, so I'm not at all sure it should go in. --001a114035589c8631051ec5e5ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 2, 2015 at 3:08 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Date: Tue, 1 Sep 2015 20:48:18 +0000<= br> > From: Pip Cet <pipcet@gmail.com>
> Cc: 21380@d= ebbugs.gnu.org
>
>=C2=A0 =C2=A0 =C2=A0Alternatively, we could turn off atime= rs (by calling turn_on_atimers)
>=C2=A0 =C2=A0 =C2=A0while Fcopy_sequence runs.
>
>
> I think that would be a better solution. I've done a quick grep fo= r the current
> atimers and at first glance they appear to be okay, but obviously that= 's no
> guarantee for the future. It might be worth thinking about
> block_input_and_atimers ().
>
> I think it's safe to assume that Lisp timers are only checked if a= timers are
> enabled.

Those are two completely separate and independent features, so no, it's not safe to make that assumption.=C2=A0 Not sure why you need to assume that, though.

So we can call tur= n_on_atimers (true) without potentially enabling atimers in a critical sect= ion.

My assumption was that the reason we have both Lisp = timers and atimers is that atimers run strictly more often than Lisp timers= .
=C2=A0
> If it isn't, I think the best way forward is to write
> block_input_and_atimers () and lock atimers with a counter just like i= nput is.

Not sure I follow you.=C2=A0 Are you saying that just calling block_= input
followed by turn_on_atimers is somehow not enough to prevent some Lisp
from changing Vtimer_list under our feet?

I'm not saying that, no, but if another function disables atimers, t= hen runs Lisp timers, then does something critical that needs atimers to be= disabled, it might break.

> --- a/src/fns.c
> +++ b/src/fns.c
> @@ -744,6 +744,9 @@ concat (ptrdiff_t nargs, Lisp_Object *args,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* Store this element into the= result.=C2=A0 */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (toindex < 0)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (NILP (tai= l))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;=
> +

Is this part still needed?

As far as I know= , the other two fixes are sufficient. It's needed in case someone calls= copy_sequence on a list that's messed with by code run from a hook fro= m QUIT, and merely succeeds in avoiding a segfault and producing incorrect = results instead, so I'm not at all sure it should go in.
--001a114035589c8631051ec5e5ef-- From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 02 15:15:27 2015 Received: (at 21380) by debbugs.gnu.org; 2 Sep 2015 19:15:27 +0000 Received: from localhost ([127.0.0.1]:46765 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXDVH-0003Js-BN for submit@debbugs.gnu.org; Wed, 02 Sep 2015 15:15:27 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:55412) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXDVB-0003Jf-V7 for 21380@debbugs.gnu.org; Wed, 02 Sep 2015 15:15:26 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NU200F00DEGN400@a-mtaout20.012.net.il> for 21380@debbugs.gnu.org; Wed, 02 Sep 2015 22:13:48 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NU200F8LDF0MF10@a-mtaout20.012.net.il>; Wed, 02 Sep 2015 22:13:48 +0300 (IDT) Date: Wed, 02 Sep 2015 22:13:48 +0300 From: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook In-reply-to: X-012-Sender: halo1@inter.net.il To: Pip Cet Message-id: <83y4goab2r.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <837foaceid.fsf@gnu.org> <83vbbuawgy.fsf@gnu.org> <83a8t4c10v.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 2 Sep 2015 16:09:53 +0000 > From: Pip Cet > Cc: 21380@debbugs.gnu.org > > > I think it's safe to assume that Lisp timers are only checked if atimers > are > > enabled. > > Those are two completely separate and independent features, so no, > it's not safe to make that assumption. Not sure why you need to > assume that, though. > > So we can call turn_on_atimers (true) without potentially enabling atimers in a > critical section. My confusion just grew a notch: one of these "atimers" is actually Lisp timers, right? If not, I'm afraid I don't see what you mean. > My assumption was that the reason we have both Lisp timers and atimers is that > atimers run strictly more often than Lisp timers. They can be more accurate, but I see no reason why they should run more often. > > If it isn't, I think the best way forward is to write > > block_input_and_atimers () and lock atimers with a counter just like > input is. > > Not sure I follow you. Are you saying that just calling block_input > followed by turn_on_atimers is somehow not enough to prevent some Lisp > from changing Vtimer_list under our feet? > > > I'm not saying that, no, but if another function disables atimers, then runs > Lisp timers, then does something critical that needs atimers to be disabled, it > might break. We didn't need to disable atimers until now, except when manipulating the atimers themselves. The function we are discussing, which copies Lisp timers, is the first one in need of this. So I don't yet see the need for a counter, but I don't object to one, either. > > --- a/src/fns.c > > +++ b/src/fns.c > > @@ -744,6 +744,9 @@ concat (ptrdiff_t nargs, Lisp_Object *args, > > /* Store this element into the result. */ > > if (toindex < 0) > > { > > + if (NILP (tail)) > > + break; > > + > > Is this part still needed? > > As far as I know, the other two fixes are sufficient. It's needed in case > someone calls copy_sequence on a list that's messed with by code run from a > hook from QUIT, and merely succeeds in avoiding a segfault and producing > incorrect results instead, so I'm not at all sure it should go in. Right. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 02 18:08:04 2015 Received: (at 21380) by debbugs.gnu.org; 2 Sep 2015 22:08:04 +0000 Received: from localhost ([127.0.0.1]:47023 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXGCK-0000Ye-4q for submit@debbugs.gnu.org; Wed, 02 Sep 2015 18:08:04 -0400 Received: from mail-io0-f181.google.com ([209.85.223.181]:34654) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXGCH-0000YD-Ci for 21380@debbugs.gnu.org; Wed, 02 Sep 2015 18:08:02 -0400 Received: by iofb144 with SMTP id b144so37431351iof.1 for <21380@debbugs.gnu.org>; Wed, 02 Sep 2015 15:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fVnfSM+WAEfw7nqeO2wI6haIHWmmzYmC+mkWZRmYmYw=; b=Ysdvh7NkOwDcJFn24EeTK2mbEV/mGmJDH+2tHfGpZmR938y+muSycWybWZ9ver3G1+ tCvG71bfnxDhFFMK3BU7b3RVAIOFoTPS7mXyX6c2SzoNhAECb7qo3eDqsAQ7hIGyQDt4 +0NSdROtDxPwlTaXkw+GRX9KhMaFK98OeEK5gi5ASLzagq+eEjO2prM9HK6AX/LbXSA1 Y8DYogUYSFVC7rGhfGqwvdveLkImKopOLN1duQvF/0LBWDlRwkruS758vl/aoBV/I1Dl /9dryzfypBYowFU43lezZmS9lrXeopXihxk2/R/rR2nkYv/YXTKvxxF/SmuUvo5Uvdd8 daRQ== MIME-Version: 1.0 X-Received: by 10.107.47.97 with SMTP id j94mr38022672ioo.136.1441231680660; Wed, 02 Sep 2015 15:08:00 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Wed, 2 Sep 2015 15:08:00 -0700 (PDT) In-Reply-To: <83y4goab2r.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <837foaceid.fsf@gnu.org> <83vbbuawgy.fsf@gnu.org> <83a8t4c10v.fsf@gnu.org> <83y4goab2r.fsf@gnu.org> Date: Wed, 2 Sep 2015 22:08:00 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook From: Pip Cet To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a1144ac345d6b6a051ecae684 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a1144ac345d6b6a051ecae684 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 2, 2015 at 7:13 PM, Eli Zaretskii wrote: > > Date: Wed, 2 Sep 2015 16:09:53 +0000 > > From: Pip Cet > > Cc: 21380@debbugs.gnu.org > > > > > I think it's safe to assume that Lisp timers are only checked if > atimers > > are > > > enabled. > > > > Those are two completely separate and independent features, so no, > > it's not safe to make that assumption. Not sure why you need to > > assume that, though. > > > > So we can call turn_on_atimers (true) without potentially enabling > atimers in a > > critical section. > > My confusion just grew a notch: one of these "atimers" is actually > Lisp timers, right? No, I don't think so. If not, I'm afraid I don't see what you mean. > See below, those were two attempts of mine to describe the same thing. > My assumption was that the reason we have both Lisp timers and atimers is > that > > atimers run strictly more often than Lisp timers. > > They can be more accurate, but I see no reason why they should run > more often. > Sorry for being unclear. I should have said something like "have strictly more opportunities to run than Lisp timers". > > > If it isn't, I think the best way forward is to write > > > block_input_and_atimers () and lock atimers with a counter just > like > > input is. > > > > Not sure I follow you. Are you saying that just calling block_input > > followed by turn_on_atimers is somehow not enough to prevent some > Lisp > > from changing Vtimer_list under our feet? > > > > > > I'm not saying that, no, but if another function disables atimers, then > runs > > Lisp timers, then does something critical that needs atimers to be > disabled, it > > might break. > > We didn't need to disable atimers until now, except when manipulating > the atimers themselves. > > The function we are discussing, which copies > Lisp timers, is the first one in need of this. So I don't yet see the > need for a counter, but I don't object to one, either. > That's how I feel about disabling atimers at all. I think it's only for future atimer code that does something dangerous. Maybe I'm missing something obvious, but there isn't currently any call path from the atimers to Lisp code. --001a1144ac345d6b6a051ecae684 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 2, 2015 at 7:13 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Date: Wed, 2 Sep 2015 16:09:53 +0000<= br> > From: Pip Cet <pipcet@gmail.com>
> Cc: 21380@d= ebbugs.gnu.org
>
>=C2=A0 =C2=A0 =C2=A0> I think it's safe to assume t= hat Lisp timers are only checked if atimers
>=C2=A0 =C2=A0 =C2=A0are
>=C2=A0 =C2=A0 =C2=A0> enabled.
>
>=C2=A0 =C2=A0 =C2=A0Those are two completely separate and independent f= eatures, so no,
>=C2=A0 =C2=A0 =C2=A0it's not safe to make that assumption. Not sure= why you need to
>=C2=A0 =C2=A0 =C2=A0assume that, though.
>
> So we can call turn_on_atimers (true) without potentially enabling ati= mers in a
> critical section.

My confusion just grew a notch: one of these "atimers" is = actually
Lisp timers, right?

No, I don't think s= o.

If not, I'm afraid I don= 't see what you mean.

See below, th= ose were two attempts of mine to describe the same thing.
> My assumption was that the reason we have both Lisp timers and atimers= is that
> atimers run strictly more often than Lisp timers.

They can be more accurate, but I see no reason why they should run more often.

Sorry for bein= g unclear. I should have said something like "have strictly more oppor= tunities to run than Lisp timers".
=C2=A0
>=C2=A0 =C2=A0 =C2=A0> If it isn't, I think the best way forward = is to write
>=C2=A0 =C2=A0 =C2=A0> block_input_and_atimers () and lock atimers wi= th a counter just like
>=C2=A0 =C2=A0 =C2=A0input is.
>
>=C2=A0 =C2=A0 =C2=A0Not sure I follow you. Are you saying that just cal= ling block_input
>=C2=A0 =C2=A0 =C2=A0followed by turn_on_atimers is somehow not enough t= o prevent some Lisp
>=C2=A0 =C2=A0 =C2=A0from changing Vtimer_list under our feet?
>
>
> I'm not saying that, no, but if another function disables atimers,= then runs
> Lisp timers, then does something critical that needs atimers to be dis= abled, it
> might break.

We didn't need to disable atimers until now, except when manipul= ating
the atimers themselves.
=C2=A0
The function we are discussing, which copies
Lisp timers, is the first one in need of this.=C2=A0 So I don't yet see= the
need for a counter, but I don't object to one, either.
=

That's how I feel about disabling atimers at all. I= think it's only for future atimer code that does something dangerous. = Maybe I'm missing something obvious, but there isn't currently any = call path from the atimers to Lisp code.
--001a1144ac345d6b6a051ecae684-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 03 11:36:51 2015 Received: (at 21380) by debbugs.gnu.org; 3 Sep 2015 15:36:51 +0000 Received: from localhost ([127.0.0.1]:47783 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXWZG-0004an-GO for submit@debbugs.gnu.org; Thu, 03 Sep 2015 11:36:50 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:51292) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXWZC-0004ac-PX for 21380@debbugs.gnu.org; Thu, 03 Sep 2015 11:36:49 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t83FaiZ6025788; Thu, 3 Sep 2015 11:36:44 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 7191966110; Thu, 3 Sep 2015 11:36:44 -0400 (EDT) From: Stefan Monnier To: martin rudalics Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook Message-ID: References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> <838u8qcenv.fsf@gnu.org> <55E69F07.9060006@gmx.at> Date: Thu, 03 Sep 2015 11:36:44 -0400 In-Reply-To: <55E69F07.9060006@gmx.at> (martin rudalics's message of "Wed, 02 Sep 2015 09:02:31 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5418=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5418> : inlines <3750> : streams <1499219> : uri <2031698> X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org, Eli Zaretskii , Pip Cet X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) >> So maybe we should introduce a special copy_sequence_no_quit function >> that never calls QUIT, and then use it for copying the timer lists. That'd be OK, yes. This said, maybe an even better solution would be to avoid the copy altogether. AFAICT these lists are only ever side-effected by timer.el's timer--activate, which has a special `reuse-cell' argument just to be able to do that. I'm not completely sure why we do it this way, but my naive understanding is the following: - For historical reasons of limited resources, timer.el tries hard to avoid allocating cons cells. - Then many years later we found a problem with this cell-reuse and circumvented it by copying the whole list all the time. - So we end up working hard to avoid allocating a couple cells on one side, only to end up allocating many more on the other. Maybe we should go back to bugs #12447 and #12326 and see if just removing the "reuse-cell" code (and the Fcopy_sequence(s)) fixes the problem as well. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 05 03:38:53 2015 Received: (at 21380) by debbugs.gnu.org; 5 Sep 2015 07:38:53 +0000 Received: from localhost ([127.0.0.1]:49339 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZY83o-0004QQ-H1 for submit@debbugs.gnu.org; Sat, 05 Sep 2015 03:38:52 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:38401) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZY83k-0004QF-PC for 21380@debbugs.gnu.org; Sat, 05 Sep 2015 03:38:50 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NU700M000E3YZ00@mtaout29.012.net.il> for 21380@debbugs.gnu.org; Sat, 05 Sep 2015 10:39:04 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NU700HW8193HA70@mtaout29.012.net.il>; Sat, 05 Sep 2015 10:39:04 +0300 (IDT) Date: Sat, 05 Sep 2015 10:38:53 +0300 From: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83a8t18gdu.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> <838u8qcenv.fsf@gnu.org> <55E69F07.9060006@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21380 Cc: rudalics@gmx.at, pipcet@gmail.com, 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: Eli Zaretskii , Pip Cet , > 21380@debbugs.gnu.org > Date: Thu, 03 Sep 2015 11:36:44 -0400 > > >> So maybe we should introduce a special copy_sequence_no_quit function > >> that never calls QUIT, and then use it for copying the timer lists. > > That'd be OK, yes. I believe the currently preferred solution is to block input and atimers while copying the timer lists to local copies. Are you okay with that? > This said, maybe an even better solution would be to avoid the copy > altogether. > > AFAICT these lists are only ever side-effected by timer.el's > timer--activate, which has a special `reuse-cell' argument just to be > able to do that. > > I'm not completely sure why we do it this way, but my naive > understanding is the following: > - For historical reasons of limited resources, timer.el tries hard to > avoid allocating cons cells. > - Then many years later we found a problem with this cell-reuse and > circumvented it by copying the whole list all the time. > - So we end up working hard to avoid allocating a couple cells on one > side, only to end up allocating many more on the other. > > Maybe we should go back to bugs #12447 and #12326 and see if just > removing the "reuse-cell" code (and the Fcopy_sequence(s)) fixes the > problem as well. I'm not sure I understand this plan. Are you saying that consing a new list in timer--activate, instead of reusing an existing cell, will avoid the need to wok on a copy of the timer's list when invoking the timer callbacks? If so, I'm probably missing something here, because timer--activate will update the timer list variable anyway, and we have the same problem, whereby the list changes under our feet, back again. IOW, if some Lisp run by a timer callback ends up doing (directly or indirectly) something like (setq timer-list (cons my-new-timer timer-list)) doesn't it mean the value of Vtimer_list in C seen by timer_check changes as well that very moment? Not to mention the fact that with timers firing every several tens of ms, something we've seen while discussing these bugs, allocating a couple of cells each time might cause a lot of consing per second, which in turn causes GC, which slows down everything. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 05 11:18:57 2015 Received: (at 21380) by debbugs.gnu.org; 5 Sep 2015 15:18:57 +0000 Received: from localhost ([127.0.0.1]:50054 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYFF2-0001zO-RD for submit@debbugs.gnu.org; Sat, 05 Sep 2015 11:18:57 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:16907) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYFF1-0001zH-6N for 21380@debbugs.gnu.org; Sat, 05 Sep 2015 11:18:55 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CbDQA731xV/xGkpUVcgxCEAsYTgk0EAgKBPDwRAQEBAQEBAYEKQQWDXQEBAwFWIwULCzQHCxQYDSSINwjPIwEBAQEBAQQBAQEBHos6hQUHhC0FnxeGaYcthhKBRSNhgVqBWSKCeAEBAQ X-IPAS-Result: A0CbDQA731xV/xGkpUVcgxCEAsYTgk0EAgKBPDwRAQEBAQEBAYEKQQWDXQEBAwFWIwULCzQHCxQYDSSINwjPIwEBAQEBAQQBAQEBHos6hQUHhC0FnxeGaYcthhKBRSNhgVqBWSKCeAEBAQ X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="162565601" Received: from 69-165-164-17.dsl.teksavvy.com (HELO ceviche.home) ([69.165.164.17]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Sep 2015 11:18:55 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 5EC9166482; Sat, 5 Sep 2015 11:18:54 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook Message-ID: References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> <838u8qcenv.fsf@gnu.org> <55E69F07.9060006@gmx.at> <83a8t18gdu.fsf@gnu.org> Date: Sat, 05 Sep 2015 11:18:54 -0400 In-Reply-To: <83a8t18gdu.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 05 Sep 2015 10:38:53 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21380 Cc: rudalics@gmx.at, pipcet@gmail.com, 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > I'm not sure I understand this plan. Are you saying that consing a > new list in timer--activate, instead of reusing an existing cell, will > avoid the need to wok on a copy of the timer's list when invoking the > timer callbacks? That's the idea, yes. > If so, I'm probably missing something here, because > timer--activate will update the timer list variable anyway, This is OK: by this time, we've already read this timer list variable so changing it won't affect us. > doesn't it mean the value of Vtimer_list in C seen by timer_check > changes as well that very moment? This setq would happen after we've read the variable, so it won't affect timer_check. > Not to mention the fact that with timers firing every several tens of > ms, something we've seen while discussing these bugs, allocating a > couple of cells each time might cause a lot of consing per second, > which in turn causes GC, which slows down everything. How could it be worse to allocate cells when we activate a timer than copying the whole list every time we check the timers? Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 05 11:28:23 2015 Received: (at 21380) by debbugs.gnu.org; 5 Sep 2015 15:28:23 +0000 Received: from localhost ([127.0.0.1]:50058 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYFOB-0002Cr-2Z for submit@debbugs.gnu.org; Sat, 05 Sep 2015 11:28:23 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:36746) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYFO8-0002Ch-79 for 21380@debbugs.gnu.org; Sat, 05 Sep 2015 11:28:21 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NU700E00MSIX400@mtaout26.012.net.il> for 21380@debbugs.gnu.org; Sat, 05 Sep 2015 18:30:33 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NU700B6SN1ITK40@mtaout26.012.net.il>; Sat, 05 Sep 2015 18:30:33 +0300 (IDT) Date: Sat, 05 Sep 2015 18:27:30 +0300 From: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <834mj89999.fsf@gnu.org> References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> <838u8qcenv.fsf@gnu.org> <55E69F07.9060006@gmx.at> <83a8t18gdu.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21380 Cc: rudalics@gmx.at, pipcet@gmail.com, 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: rudalics@gmx.at, pipcet@gmail.com, 21380@debbugs.gnu.org > Date: Sat, 05 Sep 2015 11:18:54 -0400 > > > I'm not sure I understand this plan. Are you saying that consing a > > new list in timer--activate, instead of reusing an existing cell, will > > avoid the need to wok on a copy of the timer's list when invoking the > > timer callbacks? > > That's the idea, yes. > > > If so, I'm probably missing something here, because > > timer--activate will update the timer list variable anyway, > > This is OK: by this time, we've already read this timer list variable so > changing it won't affect us. What do you mean by "have read the variable"? We are "reading" it one member at a time, as timer_check goes about its business. > > Not to mention the fact that with timers firing every several tens of > > ms, something we've seen while discussing these bugs, allocating a > > couple of cells each time might cause a lot of consing per second, > > which in turn causes GC, which slows down everything. > > How could it be worse to allocate cells when we activate a timer than > copying the whole list every time we check the timers? Twice worse, I'd say (assuming "a couple" really means 2). But this is not the important issue right now. Right now, I don't understand how your proposal will solve this and related bugs. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 05 12:59:10 2015 Received: (at 21380) by debbugs.gnu.org; 5 Sep 2015 16:59:10 +0000 Received: from localhost ([127.0.0.1]:50078 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYGo1-0004MZ-Ga for submit@debbugs.gnu.org; Sat, 05 Sep 2015 12:59:10 -0400 Received: from mail-io0-f195.google.com ([209.85.223.195]:35961) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYGnz-0004MR-Fk for 21380@debbugs.gnu.org; Sat, 05 Sep 2015 12:59:08 -0400 Received: by ioiz6 with SMTP id z6so5517172ioi.3 for <21380@debbugs.gnu.org>; Sat, 05 Sep 2015 09:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=anP860I9fd2xJjC6KKNABBfjQtPVTU21H/3FVI5qGWg=; b=SjnTy6r7XQmmHYORDRaUPb4AbfjkoE2BYUeNI7SqiPjFt3FmyeWvQQWCx9g6qojB+w FS2W7GQwI6CAbRgIQ8zXVOMtUfDwB5G2FDeGrCw7Dm0lp3007pHAhSmnfrNv95bg5UxX v8oa2Av5g4Y51VHFuuMDls5ThRYSXGnDXyPk1un07SENvaT/Uglh04HhJNiEKxq2h94a UvvKqpFj6Ldf32s6glQ3HjKUQjLYf5RGwJ1bltzbIi6UIHvXwfpsUKG4q3ew+wd/QhR6 nJPZKQei/qJkdZQ2Q6+/NeahFu/vgNQhW+Y5dsatrn+nUhLYENkzM1+SC1pJtaPSTrtR 2NAw== MIME-Version: 1.0 X-Received: by 10.107.162.205 with SMTP id l196mr17322364ioe.3.1441472346502; Sat, 05 Sep 2015 09:59:06 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Sat, 5 Sep 2015 09:59:06 -0700 (PDT) In-Reply-To: References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> <838u8qcenv.fsf@gnu.org> <55E69F07.9060006@gmx.at> Date: Sat, 5 Sep 2015 16:59:06 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook From: Pip Cet To: Stefan Monnier Content-Type: multipart/alternative; boundary=001a11402ad22abe53051f02efcf X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: martin rudalics , Eli Zaretskii , 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11402ad22abe53051f02efcf Content-Type: text/plain; charset=UTF-8 I think that's a good idea, but there's one corner case that, I think, we should think about: a timer deleting the next timer from the list. If we keep the code in timer.el that says: (defun cancel-timer (timer) "Remove TIMER from the list of active timers." (timer--check timer) (setq timer-list (delq timer timer-list)) (setq timer-idle-list (delq timer timer-idle-list)) nil) then that delq might, in some circumstances, modify the list we're working on. I'm not sure whether it's okay, performance-wise, to replace delq by remq here. Is cancelling one timer from another timer's code something that should ever have well-defined effects (I strongly suspect the answer is "Don't do that")? I confess I do not know whether delq is guaranteed only to modify the list in ways that "make sense" (the current implementation does, but it also doesn't appear to QUIT at all, so maybe it should be modified anyway...). On Thu, Sep 3, 2015 at 3:36 PM, Stefan Monnier wrote: > AFAICT these lists are only ever side-effected by timer.el's > timer--activate, which has a special `reuse-cell' argument just to be > able to do that. > I think delq also side-effects them. And, of course, "(setq timer-list nil)", which is what I tend to do when I've added a silly timer that does something bizarre and makes Emacs unusable :-) Maybe we should go back to bugs #12447 and #12326 and see if just > removing the "reuse-cell" code (and the Fcopy_sequence(s)) fixes the > problem as well. > I haven't tested this, but I think it would. I still think the underlying problem here is not having a well-defined rule for when QUIT is allowed to call Lisp code. (Eli correctly objected to my initial idea that the rule should be "never", but I still think it should be "much less often than we currently do". I've performed some very boring and somewhat tedious semi-automated call chain analysis to get a better idea of what the current state of things is, and so far the results appear consistent with my idea that QUIT shouldn't call hooks, but should be able to call isolated functions implemented in Lisp, such as those used for relative font sizing). --001a11402ad22abe53051f02efcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think that's a good idea, but there's one c= orner case that, I think, we should think about: a timer deleting the next = timer from the list. If we keep the code in timer.el that says:

(def= un cancel-timer (timer)
=C2=A0 "Remove TIMER from the list of activ= e timers."
=C2=A0 (timer--check timer)
=C2=A0 (setq timer-list (= delq timer timer-list))
=C2=A0 (setq timer-idle-list (delq timer timer-i= dle-list))
=C2=A0 nil)

then that delq might, in some circum= stances, modify the list we're working on. I'm not sure whether it&= #39;s okay, performance-wise, to replace delq by remq here. Is cancelling o= ne timer from another timer's code something that should ever have well= -defined effects (I strongly suspect the answer is "Don't do that&= quot;)? I confess I do not know whether delq is guaranteed only to modify t= he list in ways that "make sense" (the current implementation doe= s, but it also doesn't appear to QUIT at all, so maybe it should be mod= ified anyway...).

On Thu, Sep 3, 2015 at 3:36 PM, Stefan M= onnier <monnier@iro.umontreal.ca> wrote:
AFAICT these lists are only ever side-effected by timer= .el's
timer--activate, which has a special `reuse-cell' argument just to be able to do that.

I think delq also side= -effects them. And, of course, "(setq timer-list nil)", which is = what I tend to do when I've added a silly timer that does something biz= arre and makes Emacs unusable :-)

Maybe we should go back to bugs #12447 and #12326 and see if just
removing the "reuse-cell" code (and the Fcopy_sequence(s)) fixes = the
problem as well.

I haven't tested t= his, but I think it would. I still think the underlying problem here is not= having a well-defined rule for when QUIT is allowed to call Lisp code. (El= i correctly objected to my initial idea that the rule should be "never= ", but I still think it should be "much less often than we curren= tly do". I've performed some very boring and somewhat tedious semi= -automated call chain analysis to get a better idea of what the current sta= te of things is, and so far the results appear consistent with my idea that= QUIT shouldn't call hooks, but should be able to call isolated functio= ns implemented in Lisp, such as those used for relative font sizing).
--001a11402ad22abe53051f02efcf-- From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 06 18:11:54 2015 Received: (at 21380) by debbugs.gnu.org; 6 Sep 2015 22:11:55 +0000 Received: from localhost ([127.0.0.1]:50973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYiAE-0000wP-9o for submit@debbugs.gnu.org; Sun, 06 Sep 2015 18:11:54 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:16854) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYiAC-0000wH-DQ for 21380@debbugs.gnu.org; Sun, 06 Sep 2015 18:11:53 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CbDQA731xV/xGkpUVcgxCEAsYTgk0EAgKBPDwRAQEBAQEBAYEKQQWDXQEBAwFWIwULCzQHCxQYDSSINwjPIwEBAQEBBQEBAQEeizqFBQeELQEEnxeGaYsrghSBRSNhgVqBWSKCeAEBAQ X-IPAS-Result: A0CbDQA731xV/xGkpUVcgxCEAsYTgk0EAgKBPDwRAQEBAQEBAYEKQQWDXQEBAwFWIwULCzQHCxQYDSSINwjPIwEBAQEBBQEBAQEeizqFBQeELQEEnxeGaYsrghSBRSNhgVqBWSKCeAEBAQ X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="162692775" Received: from 69-165-164-17.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([69.165.164.17]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Sep 2015 18:11:52 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 5B71FAE042; Sun, 6 Sep 2015 18:11:51 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook Message-ID: References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> <838u8qcenv.fsf@gnu.org> <55E69F07.9060006@gmx.at> <83a8t18gdu.fsf@gnu.org> <834mj89999.fsf@gnu.org> Date: Sun, 06 Sep 2015 18:11:51 -0400 In-Reply-To: <834mj89999.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 05 Sep 2015 18:27:30 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21380 Cc: rudalics@gmx.at, pipcet@gmail.com, 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > What do you mean by "have read the variable"? We are "reading" it one > member at a time, as timer_check goes about its business. The Vtimer_list variable is read once and for all at the beginning of timer_check. After that, this variable is unused until we finish processing all the timers in the list. This processing uses the list that was contained in this variable, but it doesn't use the variable itself. So modifying the list during the loop can be problematic (hence the use of copy-sequence to avoid interference), whereas modifying the variable isn't. >> How could it be worse to allocate cells when we activate a timer than >> copying the whole list every time we check the timers? > Twice worse, I'd say (assuming "a couple" really means 2). What kind of scenario are you imagining. My reasoning I have in mind is this: - Every time Emacs is idle, it runs check_timers. - We don't run timers every time Emacs is idle (because it becomes un-idle before it gets a chance to run those timers). - Most commands don't activate timers (but they end by running check_timers). - Only some timers end up calling activate-timer. So, I get the impression that check_timers should be run (much?) more often than activate-timer. > But this is not the important issue right now. Right now, I don't > understand how your proposal will solve this and related bugs. Neither do I. But if replacing Fcopy_sequence by a new copy_sequence_without_QUIT fixes the bug, then I don't see why replacing it with a nop wouldn't fix it just as well. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 06 18:22:31 2015 Received: (at 21380) by debbugs.gnu.org; 6 Sep 2015 22:22:31 +0000 Received: from localhost ([127.0.0.1]:50978 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYiKU-0001CZ-O3 for submit@debbugs.gnu.org; Sun, 06 Sep 2015 18:22:31 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:14998) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYiKS-0001CQ-C5 for 21380@debbugs.gnu.org; Sun, 06 Sep 2015 18:22:28 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CYDQA731xV/xGkpUVcgxCEAsEVhH6CTQQCAoE8OxIBAQEBAQEBgQpBBYNdAQEDAVYjBQsLNAcLFBgNJIg3CM8jAQEBAQEFAQEBAR6LOoQtWAeELQEEi0STU5IUghSBRSNhgVqBWSKBNYFDAQEB X-IPAS-Result: A0CYDQA731xV/xGkpUVcgxCEAsEVhH6CTQQCAoE8OxIBAQEBAQEBgQpBBYNdAQEDAVYjBQsLNAcLFBgNJIg3CM8jAQEBAQEFAQEBAR6LOoQtWAeELQEEi0STU5IUghSBRSNhgVqBWSKBNYFDAQEB X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="162693289" Received: from 69-165-164-17.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([69.165.164.17]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Sep 2015 18:22:28 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 8A2DAAE042; Sun, 6 Sep 2015 18:22:27 -0400 (EDT) From: Stefan Monnier To: Pip Cet Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook Message-ID: References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> <838u8qcenv.fsf@gnu.org> <55E69F07.9060006@gmx.at> Date: Sun, 06 Sep 2015 18:22:27 -0400 In-Reply-To: (Pip Cet's message of "Sat, 5 Sep 2015 16:59:06 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21380 Cc: martin rudalics , Eli Zaretskii , 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > I haven't tested this, but I think it would. I still think the underlying > problem here is not having a well-defined rule for when QUIT is allowed to > call Lisp code. Indeed. Tho see below. > (Eli correctly objected to my initial idea that the rule should be > "never", Hmm... "never" does sound enticing, tho clearly debug-on-quit challenges the idea. > but I still think it should be "much less often than we currently do". OTOH, as soon as it's not "never", then it tends to means "be prepared: this can run arbitrary Elisp code". So maybe the issue is not just "when" but also "what": we could limit the kind of Elisp code that's run by QUIT. This is a lot more difficult, tho. > that QUIT shouldn't call hooks, but should be able to call isolated > functions implemented in Lisp, such as those used for relative font sizing). And then someone wants to add an advice on those functions (e.g. debug-on-entry, trace-function, you name it), and suddenly your carefully coded function ends up doing all kinds of other things. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 08 11:55:13 2015 Received: (at 21380) by debbugs.gnu.org; 8 Sep 2015 15:55:13 +0000 Received: from localhost ([127.0.0.1]:52823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZLEm-0002w8-F1 for submit@debbugs.gnu.org; Tue, 08 Sep 2015 11:55:13 -0400 Received: from mail-io0-f169.google.com ([209.85.223.169]:36817) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZLEj-0002vt-G0 for 21380@debbugs.gnu.org; Tue, 08 Sep 2015 11:55:10 -0400 Received: by ioii196 with SMTP id i196so123289815ioi.3 for <21380@debbugs.gnu.org>; Tue, 08 Sep 2015 08:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2ZnJ/LlMdgrRJnbXqxJdbSVCKR1qcig0Cn82NJZs1Zs=; b=ciomQGBLze+439H1gqBN5rOtJF1vxwJo1c86NQz/UNKgWy2wEb/OTD+3hsxScyDACF H2co7sqZ7gw3KVbXFw9lCiB6UZTVb+mC1k/qldFJDyELAWURfj5XOQb8YqXqRkv4MaFX obbgZFPaoNlxT3gRoyL0YOiTbvqKnH4FbIFNMFC6ZAJ66juHEOoWRHhWYIvclggXxsSH uC0I2EX5xPdM86Prd9ZxCOOPct2bchXUDK6EyU26F7bteklYHFYDczrgsefgWE+YY5s8 IEorfm3Stah5Y8qkvChiy0k5nwaQgRRN+KidyhlQ8o38cXIRZcCkSZ8mzKuJ91dVFd+P m4OA== MIME-Version: 1.0 X-Received: by 10.107.163.19 with SMTP id m19mr45095740ioe.65.1441727708729; Tue, 08 Sep 2015 08:55:08 -0700 (PDT) Received: by 10.79.78.66 with HTTP; Tue, 8 Sep 2015 08:55:08 -0700 (PDT) In-Reply-To: References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> <838u8qcenv.fsf@gnu.org> <55E69F07.9060006@gmx.at> Date: Tue, 8 Sep 2015 15:55:08 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook From: Pip Cet To: Stefan Monnier Content-Type: multipart/alternative; boundary=001a11403558f1194a051f3e630e X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21380 Cc: martin rudalics , Eli Zaretskii , 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11403558f1194a051f3e630e Content-Type: text/plain; charset=UTF-8 On Sun, Sep 6, 2015 at 10:22 PM, Stefan Monnier wrote: > > (Eli correctly objected to my initial idea that the rule should be > > "never", > > Hmm... "never" does sound enticing, tho clearly debug-on-quit > challenges the idea. > I think I've narrowed down the situations in which we actually run elisp from QUIT: 1. delete_frame (it has a Qnoelisp argument, but runs elisp anyway) 2. decoding C strings from X events 3. some of the new window resizing code (resize_frame_windows, frame_windows_min_size, sanitize_window_sizes) 4. mouse highlighting 5. x_kill_gs_process runs a lot of stuff, probably including elisp 6. the GTK toolbar/menubar callbacks still appear to be running window-configuration-change-hook, unless I'm missing something 3, 5, 6, and probably 1 can be fixed by running those handlers from the command loop. (2) could be fixed by keeping the untranslated string around until we actually need it decoded, but that's more difficult (in particular, we need to recognize the quit character even when other input events are not handled). (4) would probably involve adding a noelisp argument to some of the face handling code and delaying mouseover updates in those (rare, hopefully) cases in which the face isn't actually loaded yet. (The easy way to solve (4) would be not to do mouseover faces until we get back to the command loop, but I fear that would be unacceptable for most users). (This list is valid for my build configuration only, I've not even started to look at the windows/OS X code). > but I still think it should be "much less often than we currently do". > > OTOH, as soon as it's not "never", then it tends to means "be prepared: > this can run arbitrary Elisp code". > > So maybe the issue is not just "when" but also "what": we could limit > the kind of Elisp code that's run by QUIT. This is a lot more > difficult, tho. > Well, we could limit some of the cases to side-effect-free functions that don't use global variables, but I think that's too limiting. We can go the other way, however, and declare such pure functions safe, in addition to some others we'd have to check by hand. > > > that QUIT shouldn't call hooks, but should be able to call isolated > > functions implemented in Lisp, such as those used for relative font > sizing). > > And then someone wants to add an advice on those functions > (e.g. debug-on-entry, trace-function, you name it), and suddenly your > carefully coded function ends up doing all kinds of other things. > I think debug-on-entry and trace-function are important enough that we should make them work, even if our policy for arbitrary advice is "don't do that". The only problem is data shared between ordinary Lisp and QUIT-run Lisp, and even then there are many safe cases (for example, anything that doesn't return is safe, and so is updating a list by consing together a new copy first). nreverse and delq seem safe. nconc and anything using equal, not so much. (I'm not sure why assoc_no_quit is called that, since it calls Fequal which QUITs). --001a11403558f1194a051f3e630e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Sep 6, 2015 at 10:22 PM, Stefan Monnier <monnier@iro.umontrea= l.ca> wrote:
> (El= i correctly objected to my initial idea that the rule should be
> "never",

Hmm... "never" does sound enticing, tho clearly debug-on-q= uit
challenges the idea.

I think I've narrow= ed down the situations in which we actually run elisp from QUIT:
1. delete_frame (it has a Qnoelisp argument, but runs elisp an= yway)
2. decoding C strings from X events
3. so= me of the new window resizing code (resize_frame_windows, frame_windows_min= _size, sanitize_window_sizes)
4. mouse highlighting
=
5. x_kill_gs_process runs a lot of stuff, probably including elisp
=
6. the GTK toolbar/menubar callbacks still appear to be running = window-configuration-change-hook, unless I'm missing something

<= /div>
3, 5, 6, and probably 1 can be fixed by running those handlers fr= om the command loop. (2) could be fixed by keeping the untranslated string = around until we actually need it decoded, but that's more difficult (in= particular, we need to recognize the quit character even when other input = events are not handled). (4) would probably involve adding a noelisp argume= nt to some of the face handling code and delaying mouseover updates in thos= e (rare, hopefully) cases in which the face isn't actually loaded yet. = (The easy way to solve (4) would be not to do mouseover faces until we get = back to the command loop, but I fear that would be unacceptable for most us= ers).

(This list is valid for my build configu= ration only, I've not even started to look at the windows/OS X code).
> but I still think it should be "much less often than we currently= do".

OTOH, as soon as it's not "never", then it tends to me= ans "be prepared:
this can run arbitrary Elisp code".

So maybe the issue is not just "when" but also "what": = we could limit
the kind of Elisp code that's run by QUIT.=C2=A0 This is a lot more
difficult, tho.

Well, = we could limit some of the cases to side-effect-free functions that don'= ;t use global variables, but I think that's too limiting. We can go the= other way, however, and declare such pure functions safe, in addition to s= ome others we'd have to check by hand.
=C2=A0
> that QUIT shouldn't call hooks, but should be able to call isolate= d
> functions implemented in Lisp, such as those used for relative font si= zing).

And then someone wants to add an advice on those functions
(e.g. debug-on-entry, trace-function, you name it), and suddenly your
carefully coded function ends up doing all kinds of other things.

I think debug-on-entry and trace-function are im= portant enough that we should make them work, even if our policy for arbitr= ary advice is "don't do that".

The only pro= blem is data shared between ordinary Lisp and QUIT-run Lisp, and even then = there are many safe cases (for example, anything that doesn't return is= safe, and so is updating a list by consing together a new copy first). nre= verse and delq seem safe. nconc and anything using equal, not so much. (I&#= 39;m not sure why assoc_no_quit is called that, since it calls Fequal which= QUITs).
--001a11403558f1194a051f3e630e-- From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 07 13:07:32 2020 Received: (at 21380) by debbugs.gnu.org; 7 Sep 2020 17:07:32 +0000 Received: from localhost ([127.0.0.1]:50650 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFKc8-0006AT-73 for submit@debbugs.gnu.org; Mon, 07 Sep 2020 13:07:32 -0400 Received: from quimby.gnus.org ([95.216.78.240]:59642) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFKc6-0006AG-4t for 21380@debbugs.gnu.org; Mon, 07 Sep 2020 13:07:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=TOY41p4VNock1l2eHD9L1NWRakCvTU0t8ghCENV8lPo=; b=DFsR6LK9Aw9PnDRIe17ouHiENR JaJ4hPE289a322WXIZkOIcqW190AIEuueH5KKDmDgkiJS66743h1M/w5J6WGiczKRNUbrdTrYja8E OuVnOayFQtjHanc58B5tID9L9xXDLKyS8X7NNy/2ufe007wiRFdjqp9CIdWabGqoMEEo=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kFKbv-0001Zv-Nk; Mon, 07 Sep 2020 19:07:22 +0200 From: Lars Ingebrigtsen To: Pip Cet Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <837foaceid.fsf@gnu.org> <83vbbuawgy.fsf@gnu.org> X-Now-Playing: Coil's _A Prison of Measured Time_: "Wir Clk Wir (A Deeply Disturbed Passing Mix)" Date: Mon, 07 Sep 2020 19:07:18 +0200 In-Reply-To: (Pip Cet's message of "Tue, 1 Sep 2015 20:48:18 +0000") Message-ID: <875z8p5xdl.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Pip Cet writes: > * keyboard.c (timer_check): Call `block_input' and turn off > atimers around the creation of the temporary timer list copy. > > * fns.c (concat): Don't assume argument size remains unchanged > after [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > * keyboard.c (timer_check): Call `block_input' and turn off > atimers around the creation of the temporary timer list copy. > > * fns.c (concat): Don't assume argument size remains unchanged > after call to `Fmake_list'. Return incorrect results (but don't > segfault) in that case. Skimming this thread, it seemed like the first part fixes a segfault (and the second part was probably not needed), but not even the first part was applied? (I just had a peek at timer_check to check.) The discussion instead turned to the idea of avoiding the timers = Fcopy_sequence (Vtimer_list); completely, and just working directly off of Vtimer_list. Which seems like a good idea, but there may be unknown unknowns in that scenario? In any case, the timer_check change seems safe, and fixes a (somewhat obscure) segfault, so does anybody object to putting that in? (We can also add a FIXME to the code here mentioning the possibility of not copying the list.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 07 13:47:52 2020 Received: (at 21380) by debbugs.gnu.org; 7 Sep 2020 17:47:52 +0000 Received: from localhost ([127.0.0.1]:50752 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFLFA-0000wX-EL for submit@debbugs.gnu.org; Mon, 07 Sep 2020 13:47:52 -0400 Received: from mail-oo1-f49.google.com ([209.85.161.49]:41473) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFLF8-0000wC-8h for 21380@debbugs.gnu.org; Mon, 07 Sep 2020 13:47:50 -0400 Received: by mail-oo1-f49.google.com with SMTP id t3so3414019ook.8 for <21380@debbugs.gnu.org>; Mon, 07 Sep 2020 10:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kM7xkZNn1r0FX0tWxFYyPcas6o+X/c+urRHine+8bKE=; b=t6wMLQwD0U06p5dTdRd0OtP+jJrNm6rU0601YvMq3KPnp59PNy1ay0T6XI9pVbbr6N Mv7tsDQVFECv31nJY4KwfPRcjEGZlEkXHGji7nUtPIMa93ODRz6GhyIddw9u86KLArFT xV3AsXf3xb6LE2+rm9ftXb/WLc+iccM21kzrekXfk1wu1RfB+vmYIRwb8JSpm1yWTkO1 AEuB5Ho7PInTWIXQmWKuEdBJsa6eoj3E8JUo46j+liF98zfn9aWxZPRpPe/iYGNjkhpw gZZAktiJXz/AgezNoK07BYYNcLuw1VCVFU4zhjyGFcTl6Dhu7G7sZyzjWgCAUjahM2se Gj/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kM7xkZNn1r0FX0tWxFYyPcas6o+X/c+urRHine+8bKE=; b=hkuKdQWwYmXJxefzCRZRyBXCLvHVYHGNCi40vPmUXxac0DWYI7afFfCvzG1eUNJq2P RYFqo4kOy4yKSsOWXRkTlPKGVkAMFiK0SZGwI/LTrF65qtIj6997Q7SI46asC/Tyn1ks axvE/DB3hsFTM4VeVA5jcn3ASMyTR8W6E6XOy3LuJqRvOy0AJTt7kzCoHxFgTgkG9MH1 Kz/lpTwif36/MhOk8KrQB+VX1x1ME9pBgtkm5FaSeObtlhujAzaoD1X2no8c7Rbgh28+ u56RFKqkivn4cDxylOedjWqbrtooFjWwBwJpmTRQPk956uCPdruOoP0AS4U+oLetk3Xf cEVg== X-Gm-Message-State: AOAM531gvcyU7E/WHzb+zViiWpqobfHPqYNC8T8Swc8ciYM/9eg3Ah+0 iP3G1f74fuLtp08LXXyS1XY3Lj6PBWQe3Ias6T0= X-Google-Smtp-Source: ABdhPJxfdyyJ6A1fG3Hu5XAwO+uiSa1GRdqkFUMtIFncKchrlCn9Ku8mL9kYb6aO4YOk5g+wijSUg/tZcL+S70nvJGc= X-Received: by 2002:a4a:a648:: with SMTP id j8mr15751533oom.44.1599500864512; Mon, 07 Sep 2020 10:47:44 -0700 (PDT) MIME-Version: 1.0 References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <837foaceid.fsf@gnu.org> <83vbbuawgy.fsf@gnu.org> <875z8p5xdl.fsf@gnus.org> In-Reply-To: <875z8p5xdl.fsf@gnus.org> From: Pip Cet Date: Mon, 7 Sep 2020 17:47:07 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook To: Lars Ingebrigtsen Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello Lars, and congratulations on your new role, On Mon, Sep 7, 2020 at 5:07 PM Lars Ingebrigtsen wrote: > Pip Cet writes: > In any case, the timer_check change seems safe, and fixes a (somewhat > obscure) segfault, so does anybody object to putting that in? (We can > also add a FIXME to the code here mentioning the possibility of not > copying the list.) Sounds good. I must confess I've forgotten the details by now, but if there are no objections I'll prepare a patch. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 07 15:09:43 2020 Received: (at 21380) by debbugs.gnu.org; 7 Sep 2020 19:09:43 +0000 Received: from localhost ([127.0.0.1]:50884 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFMWM-0005AH-MT for submit@debbugs.gnu.org; Mon, 07 Sep 2020 15:09:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41110) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFMWL-0005A4-98 for 21380@debbugs.gnu.org; Mon, 07 Sep 2020 15:09:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47887) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kFMWF-0001er-JA; Mon, 07 Sep 2020 15:09:35 -0400 Received: from [176.228.60.248] (port=1725 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kFMWF-00060u-0k; Mon, 07 Sep 2020 15:09:35 -0400 Date: Mon, 07 Sep 2020 22:09:31 +0300 Message-Id: <83v9gpmmj8.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <875z8p5xdl.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 07 Sep 2020 19:07:18 +0200) Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <837foaceid.fsf@gnu.org> <83vbbuawgy.fsf@gnu.org> <875z8p5xdl.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org, monnier@iro.umontreal.ca, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: Eli Zaretskii , 21380@debbugs.gnu.org, Stefan Monnier > > Date: Mon, 07 Sep 2020 19:07:18 +0200 > > In any case, the timer_check change seems safe, and fixes a (somewhat > obscure) segfault, so does anybody object to putting that in? Which part? There was more than one patch in the discussion. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 08 05:57:24 2020 Received: (at 21380) by debbugs.gnu.org; 8 Sep 2020 09:57:24 +0000 Received: from localhost ([127.0.0.1]:51994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFaNP-0006S6-Ss for submit@debbugs.gnu.org; Tue, 08 Sep 2020 05:57:24 -0400 Received: from quimby.gnus.org ([95.216.78.240]:39510) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFaNO-0006Ru-50 for 21380@debbugs.gnu.org; Tue, 08 Sep 2020 05:57:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=KsWTy8zBV0u+lnBA8Gx9QG240I2kQ09jTZSrEtimPU8=; b=FjE56FZ2WIy4GqbDKpGjl5ykPt kxNu+Hu6ZR1pO4thBCb20nhUC9X2FlNF9fdol9OpnBWxU30g/zJ09sOgTdrXqIw9FeBFupbuup6Ql /TtMuLWZNNLWSIKMSr4ETz+pZQvyfrATJKTYgfx0hCktcH8wCXlyLlSSMxS5STB+TPQ8=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kFaNE-0001p4-7I; Tue, 08 Sep 2020 11:57:14 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <837foaceid.fsf@gnu.org> <83vbbuawgy.fsf@gnu.org> <875z8p5xdl.fsf@gnus.org> <83v9gpmmj8.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEVGMiKdXCfUbSXw jCX///96lmztAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+QJCAkzM83PhgMAAAGcSURBVDjLlVPbYcMw CAR1AZAXMGiCSPvv1gNk10n7U+Ujsg/ujoeJ/n+0u4/4WT49kK5qqnoYv2dwNzVWOc72QeUeGQA6 eAQ/Lz7HGdP78DkJetLceWe4UXMJWiLrADNHoSFdTxUWqLAHIAUIL+Pp3oUV/6G4M7ob4jqStCWQ ZeBNn6bICICGa2W4IcRc8pEZgbt664pmZEyew/dVIQIzikvYJUgiqwAXgQdwaWpK9TIAEAUfC7MM 2wDubCRFzCRRr1YGfMkGEJZTiHSU4E6XKU7bDeK8zmjpjcB/1kk0Xmj6A2AbZwtgjrVYlaMMhMKJ Sw35mK+Yovagz4idPab16cCsRadVz006lrXXoYr92cXvs9arTchF+cJaRV8AWqwUb6Mr0YwCFpzw hPzJKdwujQWn1lFLeJJclrS7sApXr6RamVcA68X3CBkLm3f5CqAGWvF3yN68X99HDPXtxQ2o6s+S 0K2m17kmRfQBVKQ+NGpzNvLDGd9Hrn6wPW3EqlusSuoI0W+Np7cirZG/T+kG/wD4SfbZlT9F/nm+ AeMuM+/QxNEbAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIwLTA5LTA4VDA5OjUxOjUxKzAwOjAwVlus JAAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMC0wOS0wOFQwOTo1MTo1MSswMDowMCcGFJgAAAAASUVO RK5CYII= X-Now-Playing: Rustin Man's _Drift Code_: "All Summer" Date: Tue, 08 Sep 2020 11:57:11 +0200 In-Reply-To: <83v9gpmmj8.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 07 Sep 2020 22:09:31 +0300") Message-ID: <87y2lk616w.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> In any case, the timer_check change seems safe, and fixes a (somewhat >> obscure) segfault, so does anybody object to putting that in? > > Which part? There was more than one patch in the discussio [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org, monnier@iro.umontreal.ca, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> In any case, the timer_check change seems safe, and fixes a (somewhat >> obscure) segfault, so does anybody object to putting that in? > > Which part? There was more than one patch in the discussion. This bit, but sounds like Pip is preparing a new patch: diff --git a/src/keyboard.c b/src/keyboard.c index dab32b1..4ce830d 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -4560,6 +4560,8 @@ timer_check (void) Lisp_Object tem = Vinhibit_quit; Vinhibit_quit = Qt; + block_input (); + turn_on_atimers (false); /* We use copies of the timers' lists to allow a timer to add itself again, without locking up Emacs if the newly added timer is @@ -4573,6 +4575,8 @@ timer_check (void) else idle_timers = Qnil; + turn_on_atimers (true); + unblock_input (); Vinhibit_quit = tem; do -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 08:15:13 2022 Received: (at 21380) by debbugs.gnu.org; 29 Apr 2022 12:15:13 +0000 Received: from localhost ([127.0.0.1]:51088 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkPWi-0003c9-V2 for submit@debbugs.gnu.org; Fri, 29 Apr 2022 08:15:13 -0400 Received: from quimby.gnus.org ([95.216.78.240]:37132) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkPWg-0003Sk-1A for 21380@debbugs.gnu.org; Fri, 29 Apr 2022 08:15:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=3KGYblMXAyIq+Jt/CXHY7p31jIYE2f73YtayFdB1G/I=; b=WlguRIfjdrQW9R1TMPru3+hU3S yyTloN2rSATSJcDiMoFkJlwymyRRn713R858YoNBUyiNlCyW93xy64TaGTQ0sJBqlMBshQphBfP6K 97k0J0PR8XidDPrTvGBt/Y/ejaf0ahUvW1OkFqECluCwxH2LlEZpA7KqsjEL3E1LTrQw=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkPWV-0007mA-4C; Fri, 29 Apr 2022 14:15:01 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <837foaceid.fsf@gnu.org> <83vbbuawgy.fsf@gnu.org> <875z8p5xdl.fsf@gnus.org> <83v9gpmmj8.fsf@gnu.org> <87y2lk616w.fsf@gnus.org> X-Now-Playing: Colleen's _A Flame My Love, A Frequency_: "Separating" Date: Fri, 29 Apr 2022 14:14:58 +0200 In-Reply-To: <87y2lk616w.fsf@gnus.org> (Lars Ingebrigtsen's message of "Tue, 08 Sep 2020 11:57:11 +0200") Message-ID: <87ee1gf5ml.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Lars Ingebrigtsen writes: >> Which part? There was more than one patch in the discussion. > > This bit, but sounds like Pip is preparing a new patch: I went ahead and applied it to Emacs 29, and that should (if I understand this thread correctly) fix the reported issue, so I'm closing this bug report. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 21380 Cc: 21380@debbugs.gnu.org, monnier@iro.umontreal.ca, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Lars Ingebrigtsen writes: >> Which part? There was more than one patch in the discussion. > > This bit, but sounds like Pip is preparing a new patch: I went ahead and applied it to Emacs 29, and that should (if I understand this thread correctly) fix the reported issue, so I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 08:15:17 2022 Received: (at control) by debbugs.gnu.org; 29 Apr 2022 12:15:17 +0000 Received: from localhost ([127.0.0.1]:51091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkPWm-0003fW-Ac for submit@debbugs.gnu.org; Fri, 29 Apr 2022 08:15:16 -0400 Received: from quimby.gnus.org ([95.216.78.240]:37146) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkPWj-0003Wi-Fm for control@debbugs.gnu.org; Fri, 29 Apr 2022 08:15:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=gcqPXAM4iYbHCE+vwTLWIcB4wwH+QSPhkXzdbFoLCL0=; b=aY8rLFH3739Ap62fPOMgod3m8d aCOxddgKpL5ZouftEdlgLndyCtAyK9We3GdKGZeB4va2PApLHumllQnxdmNxpZWfcj13rSK1nIIOi gzoWWChrrkVDkOcC3Xei5pDbC1yDTVPRxT6UiOm3ei6i7O1tpmicTeWR244NNZsEoLUE=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkPWb-0007mP-Q8 for control@debbugs.gnu.org; Fri, 29 Apr 2022 14:15:07 +0200 Date: Fri, 29 Apr 2022 14:15:05 +0200 Message-Id: <87czh0f5me.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #21380 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 21380 29.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 21380 29.1 quit From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 08:52:20 2022 Received: (at 21380) by debbugs.gnu.org; 29 Apr 2022 12:52:21 +0000 Received: from localhost ([127.0.0.1]:51168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkQ6e-0000L3-LZ for submit@debbugs.gnu.org; Fri, 29 Apr 2022 08:52:20 -0400 Received: from sonic315-20.consmr.mail.ne1.yahoo.com ([66.163.190.146]:45423) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkQ6c-0000Kp-RB for 21380@debbugs.gnu.org; Fri, 29 Apr 2022 08:52:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651236733; bh=OeiBxf/xTC/FwcXpa2HRcTaG9eaB3l0WW+CRbdlLsVw=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=F7k6JPbTlgp9WQUSK2lcaTVjCULTMiz4JN2z8BGOsgfy7wXqGpB7ZRNp1Qixy+eZ3LayP6S6v7vZLzSrYdoiAamv3yS1Fyw02e7j5yeGhWsZp0AvTR+WbN5CZXqEMk6rXxkkLvb2Lcdyqrd8XiYirordxfIkgtNstTXsEEQ1RKD7BFXVK7Fznib9pewkRS1Qarh4BWFwSWqQZymaD19mFh54nXcqBI1PdK7wJhZkaZeHKRSZdrBCsik4mMLT3LNYmuiK4ZoWldNBlVyXyggBqIeqicm3YMJcR+ozj3I0im2V41eLhOVIJUXPSxB3528atE28IP2Yqlq+v46qTSG2uw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651236733; bh=IFfau7JdbxKuZSVY0+dvw+q/iyWRVMAA4qS1QKugmI9=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=uHVHiRXKorezUqxcELfFaPXWc8XordCclYq0z97BRzA/tmVEstizHxf2s7lwZCjflP/biPXCY/7FpTFcBbCzrHb2lrO3YZl0hNIHjmfV1pmWyBE4Ks7iHRvVKLFcbO7i81YsESOrV6/86yix27pNn0I2E8cjRIVu2kj2KqxV+qVz2Jf9nk8HYh8q2vbBZ9R0V0sbUBzRl0NDxeUJwiiXpCxrWaM8OhXCKoNmhFI4bBQJeXB2g+AFIKKyIeMTJKB/cIYlArtS4yZqBEkT9pWecFjeqEEd37q/gCf7ckuqgQSTaWnhD/krcwLv2UyCood0tFvbp76GlxHx86LAnIg5hA== X-YMail-OSG: OiCttq0VM1kmBFRMMytz64ywpxgvAlAUU3st_XcAdvoexqeL9EVhW76ABFJpx2n 87.ROMV6vxrB.bO.Lbq_iHcMmyuKwLa9V5W16mSXj2_4avHpuY9k8oNc8GHMgEjyT5l0HlSXg6sW gQwxzbUmvJdcLBB_5DphFi7KHwMMywCzuNkleYojFa3MZQqntlkNDYZSqQl.z400FzCER0W4ECOT gXynbCTiu1wxZb4W9a3j.RXQk1JxnUkGozmn_CMDf3URyhBJN3CgfluXfaYM9jBZKOw5iXxGeEHw cHeBrASSMzDHfOPlsT1YJE611Ao1F3p_x.mvYIgtHrQ2kCdowH2yTtd5vhrIMtq_ay762Nlu1q16 y95Xl28VzIemDhH81XNN0Cade4JUeQpCL7azejQ6QYmY9B1n59m_7HkQKRgJ4.7XnDhM9djm5tGB uTmcIs7k4P3BKn0b1wOfLA60k65KVLERj49AdVi_Jo4jCyuQ3.VrW2JGJ7SQ3qbQEh8YI2tUlCJO ZMNkoK0I4RKQid1SUVTD5YtL015jhH00.2ETLyLnnegSSPialhEFsDd7iICGev7w34wFL1DPhUYE gJl39cmP_HRTi145ojVLz8VQ19tZPVRc7Bw_I3BcE88b_bTxahDoUoTyVOyBBPuOjTVxTnbb3ztA fkZKTFTz99p_iWxMfhzEe.1vw1DwInVL05GADAeFMGdsYkqInxjrBUiPvHd1Ak8r93hf6KxI10g4 4YB4DyjOPpCp4ra.FNa9jv7XXBv5EMEIkibLz_IhcUZGb3rJEnL0qhVWezFCau9whH4n6Ijg4FE3 5gkr1PWAwnRe02wGshLQzo80h43Ql9fhgwJi605NPB03SNwxG43IT3wSjs96I17n3xiYzVD.mpba L1E73AAf4nM5DkkOR2Ubykjd9LRMGNUahCVR6n04Rc7M6sfyUB9uJd0iTA_5qOVjD15QLRiATtTX 29DQCfhbwQH6fcCDQuRlsr5Mj3FsREJOYhdJQAQcWKNAbi1EIOZ2hqpJOGLFRN84tFPFURVOMqtr DPwaD23ZyaAof4tcy4761qjlGBKOZxxeno4BLr50YLyyuW0A.J273YbAuWtpYruv9493Sf3dP_Tr NZNwH.T5yoCSrnhcAlSvCWaYBO0quRZsJPEK0rYO64czCIVtEMcjLR20D5UQnBFqfZPp34agRSs8 TrhT2qfw02v5F5Pvp2LqoP07CGMANxL_SNyMBmGUEikFmNd.VNqUm1hRiHvcVKFh4qY7fK3rIDQn IqY2z1TSGDOVBEHNI9NZotjvQ88NfYR9VzBroh1GUuXma2K.NxNQ5vXerxbUKok5YoCfAEoHTodI 70aYR0tt4MQQkQfSvFY8uqeezW9e9oS3b95EMHCFS.O.ykEGxXMSD5VTMXBBkZJQlY_FXLDoJYWy 7wPhtB83prP3oMw9mtt9VsJu5M1QP2_wbSPKcG4zzZ__0TY6mifNqItQPrjPgFhFOg9LJc5TNiwR fzcwitu7rREnTLZIX3aKodRaWv6JVbtek9S9Wo6nLVXCB0Hdw0XZRFCZzBY0ZWJCK7IQcMTGp10x DH_b2xXJNn_Lgd02Xu0FderiuCscw3ymulDW_fHzJ.PnCTMiuBwnIM9klSGIHS5Dn3viYxgSGYJL XOX1QervwTBOW49mccsz5YLh5X6ssM.CF7CDmAcISdHr82ljFh4jFKUKIQ_sMld88kEkng4pdsHj xWWwYdRW.FqZLKgdg_DVHaC9Y4CFMwfr2v1uMnQ7NOAOav0QM4CtPcAHwPrsnm3f5TVRppLSu4R3 USefq_ay1fu5rYIUYlsN2CNnVAAT.btWE2aD4ADbQRc1_0KgEAJgLdq5yFl0irZY8nuc0wt1.Gys Ojz728SKNFPGdQKRav3HwTyZO5xPkCxOgZOQ9Mnq1D2mW9qnqOYEZAvB_lIKKd9YsYNB.BrCswro bDj3fX490kL5AaBw1vnMkqHasUG3hilWBqhoT0TrbUTst08.0gUdGGPqViiUHbhDEh4qFurAkLMK xXnxbvTOx6bGvzyWAuS5t1hKLxnZXOroE5U4wkb36odAjUYmTVsDRfCODw1brU7tWfX34stlslVp 7uZFWo6nxqSwOdvnS4gcLDVY0qs_3HsQb.S8Vh0P2lHY1WJyaa3CVZUjI0MgNQ_7qqpqL2GgjbpK 61H8R2Rz.2YxEKAu9DYZX0.wmDswjVOjYszUpJ_x4ab.SwINTNAnUcJnCD9PiM9d0iME01ErdBC6 VYAQ4ilXiwNmoDi3mUpyh_afcfNcSrmg2B_z8qM_Yb4xqtHC79uacU0MmI3GoDj0- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Fri, 29 Apr 2022 12:52:13 +0000 Received: by hermes--canary-production-sg3-795d7b4d54-5fwrz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 68d51add16e4dc15842a870e29a00a07; Fri, 29 Apr 2022 12:52:07 +0000 (UTC) From: Po Lu To: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> <838u8qcenv.fsf@gnu.org> <55E69F07.9060006@gmx.at> <83a8t18gdu.fsf@gnu.org> Date: Fri, 29 Apr 2022 20:52:02 +0800 In-Reply-To: <83a8t18gdu.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 05 Sep 2015 10:38:53 +0300") Message-ID: <87mtg4vyq5.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.20118 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 436 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 21380 Cc: rudalics@gmx.at, Stefan Monnier , pipcet@gmail.com, 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > I believe the currently preferred solution is to block input and > atimers while copying the timer lists to local copies. Are you okay > with that? Please forgive my ignorance, but why do atimers have to be blocked in situations where Lisp code isn't supposed to run? I don't think we ever run Lisp inside an atimer, and AFAICT atimers are active in most of the code where Lisp shouldn't run. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 09:40:38 2022 Received: (at 21380) by debbugs.gnu.org; 29 Apr 2022 13:40:38 +0000 Received: from localhost ([127.0.0.1]:51300 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkQrN-0003pu-Qa for submit@debbugs.gnu.org; Fri, 29 Apr 2022 09:40:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55424) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkQrN-0003ph-3R for 21380@debbugs.gnu.org; Fri, 29 Apr 2022 09:40:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48816) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkQrH-0006xw-AD; Fri, 29 Apr 2022 09:40:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=muaL1pjljIQ1RGKX5XFvjppe3JfJQXiN3JAPPPeJotc=; b=akzk8ZE/+dLr ZJUhQ340xzJEqbi0Xj3cO/Db0mmJkTi49q4rxvJGjWCRW0jcMKx1cV+Zfd07Rv1PTmVol/PYTbcEY XRjGAhTFoOJ0ZcXOv7YGmjVJk1TqcmnPhApCoYKb2KOnT4ABzg20Kro2phNzNUWGcDmbvDfcblwlG /6RX3CMDRUuq96nhXu3kQUBJcMbhDzEPFGR66dcbrzGT3IlMWbP62n317yECRqRu4wPSaXoi3GMIs OPSqvohuzAoUDzJmyk3zG0aM2lKj5MvG0zH2RapVhlxzcKedf2AMNIlTXEfpybUqOCiJEi1mXztlM Xbly15BOl3MHNM1/8+V6fg==; Received: from [87.69.77.57] (port=4257 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkQrF-0006RS-Rm; Fri, 29 Apr 2022 09:40:31 -0400 Date: Fri, 29 Apr 2022 16:40:26 +0300 Message-Id: <83pml09fed.fsf@gnu.org> From: Eli Zaretskii To: Po Lu In-Reply-To: <87mtg4vyq5.fsf@yahoo.com> (message from Po Lu on Fri, 29 Apr 2022 20:52:02 +0800) Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> <838u8qcenv.fsf@gnu.org> <55E69F07.9060006@gmx.at> <83a8t18gdu.fsf@gnu.org> <87mtg4vyq5.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 21380 Cc: rudalics@gmx.at, monnier@IRO.UMontreal.CA, pipcet@gmail.com, 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Po Lu > Cc: Stefan Monnier , rudalics@gmx.at, > pipcet@gmail.com, 21380@debbugs.gnu.org > Date: Fri, 29 Apr 2022 20:52:02 +0800 > > Eli Zaretskii writes: > > > I believe the currently preferred solution is to block input and > > atimers while copying the timer lists to local copies. Are you okay > > with that? > > Please forgive my ignorance, but why do atimers have to be blocked in > situations where Lisp code isn't supposed to run? I don't think we ever > run Lisp inside an atimer, and AFAICT atimers are active in most of the > code where Lisp shouldn't run. First, I see no guarantee that atimers cannot run Lisp, ever. And second, even if they don't run Lisp, they could run code which directly or indirectly modifies Vtimer_list, and we cannot allow that in this case. IOW, the problem is not that Lisp isn't supposed to run in this situation, the problem is that we examine and modify Vtimer_list, so we cannot allow any code that could potentially modify that behind our backs while we are at that. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 09:44:58 2022 Received: (at 21380) by debbugs.gnu.org; 29 Apr 2022 13:44:58 +0000 Received: from localhost ([127.0.0.1]:51305 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkQva-0003wK-D4 for submit@debbugs.gnu.org; Fri, 29 Apr 2022 09:44:58 -0400 Received: from sonic302-21.consmr.mail.ne1.yahoo.com ([66.163.186.147]:46248) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkQvY-0003w7-L2 for 21380@debbugs.gnu.org; Fri, 29 Apr 2022 09:44:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651239891; bh=pvL47o643JbyGMsGxV4gZVZzayGCT++5d2/nlV11hKc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=BqV5KbzmXrSYZwkgHEPEzIZ3UYlHLbABM9E8quqHbYhQ5vF2lj8VJ362HXGAhtP7KOXpKdXESVAnhErSbDRfQQvJ6XJ0R8dnRxpmrTvJZwn/AKimQGhySmvsgU7OY3LiGczGYr00pTcqRv82Uf+pBFlvydnALIrIrm2MvOfu22YrstoAfU/7oisNviFnGsNbYnSNkNo/Oo8weFmY4xCZemaueeIIuBR+eqHv8v13nZ9ivzGBjoWyQeqFnE96UVzDLMSmauNVQshcfmDIDbrtg4tNsy8Ul96mHeekKtxEq7f4gaE6QC6J5CK07qPO643REpEJYZemJS5mkOlnaBQsRA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651239891; bh=WE5HAfqfvxgQ/I5iK5R7BYuDOboMY/ZSoow/AHutCTy=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=NZJaJIX9QP40ObEGqwtNOsWkX8rXCaJqUNy+T3rIB3Tz7mH40VjInwJPo9lFVYcVFx4jZM3IVBiS5NMH7n8/e0jY4b+RisluU1c8Bw7Y/C+338KvrIZfMduRXw8nrl6qsnZ2P0UNfF68EN30wuZUlfoikGWb5By5zwHvbUSdM2PNUMtRa+h98pzRy2kdTCGcNCnCzfTajRJjMvdN0KCaZhusGmsFmVxc7PSrHd4aWg5KIZAAPk/XzWqAlUZ8h4eJc1uMt/zpSMK+slqUkqhDbS+kG63mldYAdcAjrIodyQTeSFbWjZRabEJ54CGgzp+UcugBgSGpZjfbQ+kNqYDkeQ== X-YMail-OSG: 5ukTYvgVM1lW4GaSNzVIyTot2JTLWlx9oftwUkSuakZ43DlkCLgHtUylNOvC68a C1kdyLFiT.tUXC5g4u6CxJ2_AlYMc_IEpL3cM7uSrnab2PRZSQKvRNapG2eCO8RkQfD0XowyFBQ0 Mt.ZGZKEfG4GhKJi91O6CpLzhYC7fL2.gMJm0pQtlkNAzNEwP0cVc_tK3LqB1z3_lWFAABuzLi4S W2WtNBmWfLXsn9y_cEFpVwAkK0BPkIxMSNcbXwdclmTinP0kjRDfKl4dEuIcaUj_jagZ_e61I7KI ReD7TUpOFd0ryuwRDYTiqU2fXdSv0VtAfMiCwiXAmwZxttrLrwDYJkTVS.wSrkfznFGDW_zVB94T I.iS_UERRGyw3OSsa0ZXygeV7leheFbiBvxTggjil5fhzOBE0UKKNjwTp5XkBFqJKWs3BBlQSkXR 34VAg.K8grOEgUJoPj7DY9WPXxFCbyFt1fT39KVyA7ZEFisdGcV1bxAntkw3Tkvsg9yLFLNrX2JQ OCfGwolBgISrqLNHfipDs7bOxmXUln3YpUiQTaNGnOZvmKlANT2mJ68ow3syjMFkFAbpiKXdgtKW _y8xex0xFgSjmtiov.5lbvfcIGZgtp8.qjWXTkq2SBP3ZJjjod8o7moQORc5f7uYlE9axPPwdT3C hkOmndcm8lnNyOP7CKgCfnt3VLRhL6WeZ4eST3RfI3QYD90F2shxHEY4A2XgAIg4B8edbJYk3ZRX 3OJCXrJBYAt9m3pAJI.1ws2E0e.bwMUmDEMb42tRaxLPKl11rEtO7LgBJ0XHtbOib16WiOyt8NXA N9gP0oos9Z02g5MESQZgHbLvgLeW3tjYp8Dx9lCsLjVGTuc_GtaBqEIgLd0V6lZzSBeiVLtDYrdU sblQKlthJZXz9ZXYnkxlQrrxIL9qFF4j9TDE.dhkYBwt6ARNld84Tt4FXHqMqmAU9TTZseY_qwkg HvAfHlIpIsHHc9egZJ0CwQs3EpUikSCfKkxh1_RIqjXVQccpjiM9TI2vHQxjEnOKDdVC3A4YWf1Q cexVRQs3R8gU2NTnjtrjypJU.LXQK5zX1d2QQyTPu1Bd1J8BjcImWwuVfDFdm21ZVS8fjCxQohQ. yqIbzZgUa5Lu.AYEZfqWYId1FNeamV7OxQSeFl_VN.SYQ3MSWqh7Hr9iheftdK_1CYZarOTuYA1h mhwKpdSz3kBIS6owZan_X9vKpsGdaczoJzqsjqZt74ngdFCUN4NUkW2w770d0zmu.kv1QBa8z.2X 8iCL1e1z3BgM3aQwnp8H8feov7xmBlYdV.AMFt_stL7BL.8OMsTbAJ0zMGXlxh.DzTJwJidhi33K rv4n2JK2mie3hl.bqwlAE_rPyVuIpvJwhKDE187ojgYKbQMEIJzJufZ8ra8iMx_1bBOu6ijnvMvY jeY1uWo2rCHmB6lailGg7pPGk9KQyRp2jFRXmKhHXh28MteL1.RALctmb_fPHYVLq1TQpbs0Y1F3 p27cfkadQmoHeRApIWngYnPxr2OB7rAbAlQkl_oR.6jqXfEzmy6RR3lHyRaN0PNvivomPNcQS9C7 xEXXnELY.ducTax5Y92wNkoepSuMubPWKRt1YEY84kLRGAmj2ukmJgYRwbiRDjIQdwKJKrUCNhpn vcLJV3BQz18B0z_oaW.YSv6a1.gAu2KBOypPz3yOG0bSmhlV.IfG99GbGh30NYsW3uYqSykWomcp ayE14ykQnhyEmdREZoO3HjxHMd4MMjwKt7JfpSFED0K1Cj.PhCxRZRy1PMtwoTeEmRuF1NvGvFPD KFAvR0I1lq_2Yfg_fXeld84ZOvKWtymzYGEvY58lMkmqrw.8xabstp6zw6JFk5FdTjN7qkmk0gvO EJEf17UroZ2yJHIup9Dnux2is1wPf.0ImFaHhZotmt0y0pemuN.YfX2cAJDVr5lx90rtZVAoFeTT BBJcFpidf8ycksa4vbDENGMWuaR5z5JiA_CLG9p.VtsfeshZwzLUFlUCFxwRP6wZC7N3z4jn21Rn h8cPDOOY5l2YleRHFaXBna1GazY6G0nI8bREAaw.gpz78uI565OC6vSXpqfJDpwRdvU_i3xZX4_q ct_h4NR44NUgeXyA7ygmcikvkSiyvzkfmt_my6Y9gBqo5AVltZummKo7hDfBm02xr3UZUZccWNSM Y0_oUNdarq3XnMoBbGrIgDXOjSNvh8JHAF9HkVyFtlqvhXaZ.cZ1YMIY4j50FGoJcI5afuelRmBH LOBNvAIWFPlCDVTYmSTRiAF6iK5_FNmeNPe7mjv79WRdJgaYMoiO3ENQJP3VMA8JZHA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Fri, 29 Apr 2022 13:44:51 +0000 Received: by hermes--canary-production-sg3-795d7b4d54-5fwrz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ec3ca33a728b09660a99fe7156f3a982; Fri, 29 Apr 2022 13:44:48 +0000 (UTC) From: Po Lu To: Eli Zaretskii Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> <838u8qcenv.fsf@gnu.org> <55E69F07.9060006@gmx.at> <83a8t18gdu.fsf@gnu.org> <87mtg4vyq5.fsf@yahoo.com> <83pml09fed.fsf@gnu.org> Date: Fri, 29 Apr 2022 21:44:43 +0800 In-Reply-To: <83pml09fed.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 29 Apr 2022 16:40:26 +0300") Message-ID: <87zgk4uhpw.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.20118 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 664 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 21380 Cc: rudalics@gmx.at, monnier@IRO.UMontreal.CA, pipcet@gmail.com, 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > First, I see no guarantee that atimers cannot run Lisp, ever. And > second, even if they don't run Lisp, they could run code which > directly or indirectly modifies Vtimer_list, and we cannot allow that > in this case. > > IOW, the problem is not that Lisp isn't supposed to run in this > situation, the problem is that we examine and modify Vtimer_list, so > we cannot allow any code that could potentially modify that behind our > backs while we are at that. Hmm, okay, thanks for explaining. I guess some code called by the input polling atimer eventually ends up modifying `timer-list' when input polling is enabled. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 11:03:28 2022 Received: (at 21380) by debbugs.gnu.org; 29 Apr 2022 15:03:28 +0000 Received: from localhost ([127.0.0.1]:55101 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkS9X-0002z6-QF for submit@debbugs.gnu.org; Fri, 29 Apr 2022 11:03:27 -0400 Received: from mail-pl1-f180.google.com ([209.85.214.180]:34770) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkS9W-0002ys-SK for 21380@debbugs.gnu.org; Fri, 29 Apr 2022 11:03:27 -0400 Received: by mail-pl1-f180.google.com with SMTP id n8so7390187plh.1 for <21380@debbugs.gnu.org>; Fri, 29 Apr 2022 08:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gjgDYV1HQuLmSLYuD2FT5WmAdlKw3ghOPH1PaYqXZps=; b=ZDv8alphIYTxazZy7TrGhfWfhpgwmMqARU9w4E+Cz8CTgU94qdNF3p0Z3nVeEmKvKY H3uo/uJ7w4lIT8QpOSXeErWQrc7waC9DjO+qkjf5PDhq6Up5Hfz9iCaeXYQh37U2+NQQ dPl0YmqA+CYKobO2STuVn1bl6MltZY0z8K9ixO5yXNjeJM9+wxWb0nmRHMsbrKCrxeVo bLBoR+obelGB9HJfK8vanEckFG35/WLlngc9V0qbBTCoxuqi0phUXxRktkTvDyfg3yo0 OSYKiTtPRhNpEcoFnvQyEOwFqYKymPchUV8nkinG4aLRVLeu7tI85dzW9fTrs5ONshzT hmNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gjgDYV1HQuLmSLYuD2FT5WmAdlKw3ghOPH1PaYqXZps=; b=jO6wpmge0AQ/93s1kKtheliB/p6ZnGX2ZkVq2IdZq/SXBSMv7ZpcPpU3c4BhMRo250 JVNE4Z0HTGH9y8XLjA/asJo+ExdOufAq9xOUd2Ld1/fkt3Oznz8BvCUCqm4DHX1ZAGFw RxmCMxdUXRMOuBzkVHKmjBbwyU3e1LywuQEig1pwWGM/1Cb0q3UlFx6DejDmAbXOVtGh 8A/Ouwpd+L92ZsFYQSfMLm8eCtMzmJ3xaGBVoUWD8Il/IkfJXn6DqdOmm2ixsTVDgAxl K+VsUkEu6Elhsl0iVDsKtVEOeLlRGmq8w9OtRXVk8kqIj+noz1vgqMr0Ad54BrNh+GVW jacA== X-Gm-Message-State: AOAM530sNvqMK/V4EaoOO362zmOeDdJOVRI90o61EMlVHvpYNAcoQaUs SdhH9o0NxibMux1OkmSqbGwGM1FB0OY+BPTbb84= X-Google-Smtp-Source: ABdhPJwdrv+8Gv5+SlCoK0YZU1fz8h8WwV/kQwhIUsOGA3Quw/q/lEinzvUWHmXDVJNnUKy064fjYcPjeOMDErs0Eqo= X-Received: by 2002:a17:902:bf04:b0:149:c5a5:5323 with SMTP id bi4-20020a170902bf0400b00149c5a55323mr39526311plb.97.1651244600729; Fri, 29 Apr 2022 08:03:20 -0700 (PDT) MIME-Version: 1.0 References: <83mvx8252m.fsf@gnu.org> <83k2sc20k6.fsf@gnu.org> <83h9ng1ryx.fsf@gnu.org> <83a8t71qct.fsf@gnu.org> <83fv2ychbg.fsf@gnu.org> <838u8qcenv.fsf@gnu.org> <55E69F07.9060006@gmx.at> <83a8t18gdu.fsf@gnu.org> <87mtg4vyq5.fsf@yahoo.com> <83pml09fed.fsf@gnu.org> <87zgk4uhpw.fsf@yahoo.com> In-Reply-To: <87zgk4uhpw.fsf@yahoo.com> From: Pip Cet Date: Fri, 29 Apr 2022 15:02:43 +0000 Message-ID: Subject: Re: bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook To: Po Lu Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 21380 Cc: rudalics@gmx.at, Eli Zaretskii , Stefan Monnier , 21380@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Apr 29, 2022 at 1:44 PM Po Lu wrote: > Eli Zaretskii writes: > > IOW, the problem is not that Lisp isn't supposed to run in this > > situation, the problem is that we examine and modify Vtimer_list, so > > we cannot allow any code that could potentially modify that behind our > > backs while we are at that. > > Hmm, okay, thanks for explaining. I guess some code called by the input > polling atimer eventually ends up modifying `timer-list' when input > polling is enabled. Thanks for looking into this! I'm not sure I thought about the way unblock_input will sometimes read asynchronous input, which might make unlikely segfaults like this one more likely if we're not careful. But I must confess I no longer remember the details here clearly. Pip From unknown Sun Jun 22 11:38:40 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 28 May 2022 11:24:09 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator