From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Andreas Politz Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 Jul 2019 20:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 36609@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.156287828929571 (code B ref -1); Thu, 11 Jul 2019 20:52:02 +0000 Received: (at submit) by debbugs.gnu.org; 11 Jul 2019 20:51:29 +0000 Received: from localhost ([127.0.0.1]:38869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlg2J-0007gl-CP for submit@debbugs.gnu.org; Thu, 11 Jul 2019 16:51:28 -0400 Received: from lists.gnu.org ([209.51.188.17]:59292) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlg2G-0007gU-UW for submit@debbugs.gnu.org; Thu, 11 Jul 2019 16:51:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40206) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hlg2E-00053k-Am for bug-gnu-emacs@gnu.org; Thu, 11 Jul 2019 16:51:24 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_MED, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hlg2A-00065P-Ak for bug-gnu-emacs@gnu.org; Thu, 11 Jul 2019 16:51:21 -0400 Received: from gateway-a.fh-trier.de ([143.93.54.181]:54341) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hlg29-0005yw-CE for bug-gnu-emacs@gnu.org; Thu, 11 Jul 2019 16:51:18 -0400 X-Virus-Scanned: by Amavisd-new + Sophos + ClamAV [Rechenzentrum Hochschule Trier (RZ/HT)] Received: from localhost (x4db620d5.dyn.telefonica.de [77.182.32.213]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: politza) by gateway-a.fh-trier.de (Postfix) with ESMTPSA id 66AD81871025 for ; Thu, 11 Jul 2019 22:51:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=hochschule-trier.de; s=default; t=1562878271; bh=qnSNCUGUemvWSuEgtb8ZRHp0aC4=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=WhZyrWX+pA5/+f8avRJmMYOeB8cHhcHVAjXk18QrzXRbj8ypbLEUZjITUr0ZVXlSN NGe4RssFYiry81j46DmN11GLQSTjZQh3tWLWSfxJkHBOxtbnhWleQm3FSE5xoKblt+ zgiPxlJeVkxXzKMuKTDHbs33HMdbpKbCprg5FIH8= From: Andreas Politz Date: Thu, 11 Jul 2019 22:51:10 +0200 Message-ID: <87muhks3b5.fsf@hochschule-trier.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 143.93.54.181 X-Spam-Score: -1.3 (-) 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: -2.3 (--) --=-=-= Content-Type: text/plain I think there is a race-condition in the implementation of threads. I tried to find a minimal test-case, without success. Thus, I've attached a lengthy source-file. Loading that file should trigger this bug and may freeze your session. Indications: 1. The main-thread has the name of one of created threads (XEmacs in this case), instead of "emacs". 2. Emacs stops processing all keyboard/mouse input while looping in wait_reading_process_output. Sending commands via emacsclient still works. GDB output: (gdb) info threads Id Target Id Frame * 1 Thread 0x7ffff17f5d40 (LWP 26264) "XEmacs" 0x000055555576eac0 in XPNTR (a=XIL(0x7ffff1312533)) at alloc.c:535 2 Thread 0x7ffff0ac4700 (LWP 26265) "gmain" 0x00007ffff50d1667 in poll () from /usr/lib/libc.so.6 3 Thread 0x7fffebd1a700 (LWP 26266) "gdbus" 0x00007ffff50d1667 in poll () from /usr/lib/libc.so.6 4 Thread 0x7fffeb519700 (LWP 26267) "dconf worker" 0x00007ffff50d1667 in poll () from /usr/lib/libc.so.6 (gdb) bt full #0 0x00007ffff50d3f76 in pselect () at /usr/lib/libc.so.6 #1 0x0000555555832e48 in really_call_select (arg=0x7fffffffd150) at thread.c:586 sa = 0x7fffffffd150 self = 0x555555c154e0 oldset = { __val = {0, 93825011232085, 140737488343064, 31632, 31632, 51840, 140737488343136, 93824994672716, 4294967298, 140737488343184, 93824999850720, 0, 0, 140737488343136, 93824993869565, 4041340661} } #2 0x0000555555774449 in flush_stack_call_func (func=0x555555832d81 , arg=0x7fffffffd150) at alloc.c:4969 end = 0x7fffffffd100 self = 0x555555c154e0 sentry = { o = { __max_align_ll = 140737488343296, __max_align_ld = } } #3 0x0000555555832f40 in thread_select (func=0x7ffff50d3eb0 , max_fds=6, rfds=0x7fffffffd260, wfds=0x7fffffffd2e0, efds=0x0, timeout=0x7fffffffd8b0, sigmask=0x0) at thread.c:616 sa = { func = 0x7ffff50d3eb0 , max_fds = 6, rfds = 0x7fffffffd260, wfds = 0x7fffffffd2e0, efds = 0x0, timeout = 0x7fffffffd8b0, sigmask = 0x0, result = 210347336 } #4 0x000055555585fea3 in xg_select (fds_lim=6, rfds=0x7fffffffd920, wfds=0x7fffffffd9a0, efds=0x0, timeout=0x7fffffffd8b0, sigmask=0x0) at xgselect.c:117 all_rfds = { fds_bits = {32, 0 } } all_wfds = { fds_bits = {0 } } tmo = { tv_sec = 7, tv_nsec = 140737488343264 } tmop = 0x7fffffffd8b0 context = 0x555555dae320 have_wfds = true gfds_buf = {{ fd = 0, events = 0, revents = 0 }, { fd = 32, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 7, events = 0, revents = 0 }, { fd = 8, events = 0, revents = 0 }, { fd = 15, events = 0, revents = 0 }, { fd = -11072, events = 32767, revents = 0 }, { fd = 1460278864, events = 21845, revents = 0 }, { fd = 64, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 2, events = 48, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 91, events = 124, revents = 0 }, { fd = -397131776, events = 35414, revents = 11125 }, { fd = 1460278864, events = 21845, revents = 0 }, { fd = 1, events = 0, revents = 0 }, { fd = 2, events = 0, revents = 0 }, { fd = -11072, events = 32767, revents = 0 }, { fd = 1439161536, events = 21845, revents = 0 }, { fd = -11024, events = 32767, revents = 0 }, { fd = -11088, events = 32767, revents = 0 }, { fd = -182671191, events = 32767, revents = 0 }, { fd = 1, events = 0, revents = 0 }, { fd = -182670875, events = 32767, revents = 0 }, { fd = 194871296, events = 59160, revents = 48198 }, { fd = -1175563804, events = 19, revents = 0 }, { fd = 24, events = 0, revents = 0 }, { fd = 1460278864, events = 21845, revents = 0 }, { fd = 2, events = 0, revents = 0 }, { fd = 1439882448, events = 21845, revents = 0 }, { fd = 2, events = 0, revents = 0 }, { fd = 2, events = 0, revents = 0 }, { fd = 1, events = 2, revents = 0 }, { fd = 1460278864, events = 21845, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = -397131776, events = 35414, revents = 11125 }, { fd = 24, events = 0, revents = 0 }, { fd = 1439161536, events = 21845, revents = 0 }, { fd = 2, events = 0, revents = 0 }, { fd = 1, events = 0, revents = 0 }, { fd = 1439161536, events = 21845, revents = 0 }, { fd = -182606722, events = 32767, revents = 0 }, { fd = -10960, events = 32767, revents = 0 }, { fd = 1433487750, events = 21845, revents = 0 }, { fd = -10976, events = 32767, revents = 0 }, { fd = 1439161536, events = 21845, revents = 0 }, { fd = -30, events = 0, revents = 0 }, { fd = 1, events = 0, revents = 0 }, { fd = 1, events = 64, revents = 0 }, { fd = 1562877925, events = 0, revents = 0 }, { fd = 31, events = 0, revents = 0 }, { fd = 1562877925, events = 0, revents = 0 }, { fd = -10960, events = 32767, revents = 0 }, { fd = 1434542700, events = 21845, revents = 0 }, { fd = -10912, events = 32767, revents = 0 }, { fd = 1439161536, events = 21845, revents = 0 }, { fd = 1562877925, events = 0, revents = 0 }, { fd = -397131776, events = 35414, revents = 11125 }, { fd = -10848, events = 32767, revents = 0 }, { fd = 1434543288, events = 21845, revents = 0 }, { fd = 1460274293, events = 21845, revents = 0 }, { fd = 1385447426, events = 931, revents = 0 }, { fd = 95390, events = 0, revents = 0 }, { fd = 1433865373, events = 7256, revents = 10134 }, { fd = 1562877925, events = 0, revents = 0 }, { fd = 1439161536, events = 21845, revents = 0 }, { fd = 664149, events = 0, revents = 0 }, { fd = 80000, events = 0, revents = 0 }, { fd = 1562877925, events = 0, revents = 0 }, { fd = 664149080, events = 0, revents = 0 }, { fd = 1562877925, events = 0, revents = 0 }, { fd = 664149080, events = 0, revents = 0 }, { fd = -10752, events = 32767, revents = 0 }, { fd = 1434543494, events = 21845, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = -10544, events = 32767, revents = 0 }, { fd = 499622378, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 499622378, events = 0, revents = 0 }, { fd = -10688, events = 32767, revents = 0 }, { fd = 1434939197, events = 21845, revents = 0 }, { fd = 1562877925, events = 0, revents = 0 }, { fd = 164526702, events = 0, revents = 0 }, { fd = 1562877925, events = 0, revents = 0 }, { fd = 664149080, events = 0, revents = 0 }, { fd = -10544, events = 32767, revents = 0 }, { fd = 499622378, events = 41450, revents = 7623 }, { fd = 0, events = 0, revents = 0 }, { fd = 1562877925, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = -1, events = 65535, revents = 65535 }, { fd = -10432, events = 32767, revents = 0 }, { fd = 1433359581, events = 21845, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 1443725184, events = 85, revents = 0 }, { fd = 1450650965, events = 21845, revents = 0 }, { fd = 1450650965, events = 21845, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 16384, events = 0, revents = 0 }, { fd = 5, events = 0, revents = 0 }, { fd = -10496, events = 32767, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = -1, events = 65535, revents = 65535 }, { fd = 1562877925, events = 0, revents = 0 }, { fd = 164526702, events = 0, revents = 0 }, { fd = 719, events = 0, revents = 0 }, { fd = 893997157, events = 0, revents = 0 }, { fd = 1439269600, events = 21845, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = -10496, events = 32767, revents = 0 }, { fd = 1433288445, events = 21845, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 164532384, events = 0, revents = 0 }, { fd = 1562977925, events = 0, revents = 0 }, { fd = 1562977925, events = 0, revents = 0 }, { fd = 164532384, events = 0, revents = 0 }, { fd = -10368, events = 32767, revents = 0 }, { fd = 1434938909, events = 21845, revents = 0 }, { fd = 100000, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 1562877925, events = 0, revents = 0 }, { fd = 164532384, events = 0, revents = 0 }, { fd = -1, events = 65535, revents = 65535 }, { fd = 0, events = 0, revents = 0 }} gfds = 0x7fffffffd360 gfds_size = 128 n_gfds = -1 retval = 0 our_fds = 0 max_fds = 5 context_acquired = false i = 0 nfds = 135 tmo_in_millisec = 1030 must_free = 0 need_to_dispatch = false #5 0x0000555555802a78 in wait_reading_process_output (time_limit=0, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at process.c:5423 process_skipped = false channel = 6 nfds = 1 Available = { fds_bits = {32, 0 } } Writeok = { fds_bits = {0 } } check_write = true check_delay = 0 no_avail = false xerrno = 11 proc = XIL(0x7fffffffd9a0) timeout = { tv_sec = 0, tv_nsec = 499622378 } end_time = { tv_sec = 93824993869565, tv_nsec = 0 } timer_delay = { tv_sec = 0, tv_nsec = 499622378 } got_output_end_time = { tv_sec = 1562977205, tv_nsec = 270561059 } wait = FOREVER got_some_output = -1 prev_wait_proc_nbytes_read = 0 retry_for_async = false count = 4 now = { tv_sec = 0, tv_nsec = -1 } #6 0x00005555556f4718 in kbd_buffer_get_event (kbp=0x7fffffffdc70, used_mouse_menu=0x7fffffffe235, end_time=0x0) at keyboard.c:3836 do_display = true obj = make_fixnum(1073741816) #7 0x00005555556f06c5 in read_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffe040, used_mouse_menu=0x7fffffffe235) at keyboard.c:2138 c = XIL(0) save_jump = {{ __jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = { __val = {0 } } }} kb = 0x7fffffffdcd0 count = 3 #8 0x00005555556f099b in read_decoded_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffe040, prev_event=XIL(0), used_mouse_menu=0x7fffffffe235) at keyboard.c:2202 nextevt = XIL(0) frame = 0x1dcd30d9 terminal = 0x9 events = {XIL(0), XIL(0x1dcd30d9), XIL(0xca80), XIL(0x2b758a56e8544000), XIL(0), XIL(0x555556772ff5), XIL(0x7fffffffde50), XIL(0x5555556f57d8), XIL(0x555555c982e0), XIL(0), XIL(0), XIL(0x7fffffffde50), XIL(0x5555556e3efd), XIL(0x1dcd30d9), XIL(0x7fffffffde90), XIL(0x5555556f3b29)} n = 0 #9 0x00005555556f2236 in read_char (commandflag=1, map=XIL(0x5555567756e3), prev_event=XIL(0), used_mouse_menu=0x7fffffffe235, end_time=0x0) at keyboard.c:2810 c = XIL(0) jmpcount = 3 local_getcjmp = {{ __jmpbuf = {0, -245616553674816983, 93825011232757, 51840, 0, 0, -245616553305718231, -6214351577293929943}, __mask_was_saved = 0, __saved_mask = { __val = {0, 0, 140737488347312, 93824993869565, 0, 140737488347424, 93824994673374, 93825011242707, 3, 0, 0, 140737488347424, 93824994446493, 93824999850720, 0, 0} } }} save_jump = {{ __jmpbuf = {93824993869565, 0, 140737488347584, 93824994020698, 0, 51840, -1, 0}, __mask_was_saved = 1450661587, __saved_mask = { __val = {93825011242723, 140737488347520, 93824993870282, 93825011242707, 93825011242723, 140737488347584, 93824994446493, 93824999885184, 34464, 34464, 140737488347584, 93824993869565, 40105367251, 93825004306304, 140737488347624, 93824999850720} } }} tem = XIL(0x2aaa9b29c970) save = XIL(0) previous_echo_area_message = XIL(0) also_record = XIL(0) reread = false recorded = false polling_stopped_here = true orig_kboard = 0x555555dfa570 #10 0x00005555556ff6c8 in read_key_sequence (keybuf=0x7fffffffe440, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9124 interrupted_kboard = 0x555555dfa570 interrupted_frame = 0x5555560d7f80 key = XIL(0x5555557a7eff) used_mouse_menu = false echo_local_start = 0 last_real_key_start = 0 keys_local_start = 0 new_binding = XIL(0x7fffffffe310) count = 3 t = 0 echo_start = 0 keys_start = 0 current_binding = XIL(0x5555567756e3) first_unbound = 31 mock_input = 0 used_mouse_menu_history = {false } fkey = { parent = XIL(0x555555d6ce03), map = XIL(0x555555d6ce03), start = 0, end = 0 } keytran = { parent = XIL(0x7ffff14a7dbb), map = XIL(0x7ffff14a7dbb), start = 0, end = 0 } indec = { parent = XIL(0x555555d6cdf3), map = XIL(0x555555d6cdf3), start = 0, end = 0 } shift_translated = false delayed_switch_frame = XIL(0) original_uppercase = XIL(0) original_uppercase_position = -1 dummyflag = false starting_buffer = 0x7ffff0e1f6f0 fake_prefixed_keys = XIL(0) first_event = XIL(0) second_event = XIL(0) #11 0x00005555556ee5fb in command_loop_1 () at keyboard.c:1348 cmd = XIL(0) keybuf = {XIL(0x7fffffffe490), XIL(0x5555557a804c), make_fixnum(11545945833472), XIL(0x7fffffffe4c0), XIL(0x555555c982e0), XIL(0), XIL(0), XIL(0x7fffffffe490), XIL(0x5555556e3efd), XIL(0xf0e1f6f5), XIL(0x7fffffffe500), make_fixnum(23456248668343), XIL(0x555555d18953), XIL(0x3), XIL(0x555555c982e0), XIL(0), XIL(0), XIL(0x7fffffffe4e0), XIL(0x5555556e3efd), XIL(0xf0e1f6f5), XIL(0x7fffffffe520), XIL(0x5555557a2e69), XIL(0x1556e3efd), XIL(0x5760), XIL(0x7fffffffe540), XIL(0x555555d53470), XIL(0), XIL(0), XIL(0x7fffffffe550), make_fixnum(23456248662876)} i = 32767 prev_modiff = 0 prev_buffer = 0x0 already_adjusted = false #12 0x00005555557a2a64 in internal_condition_case (bfun=0x5555556ee1b3 , handlers=XIL(0x5760), hfun=0x5555556ed968 ) at eval.c:1351 val = XIL(0x5555556e3efd) c = 0x555555d53470 #13 0x00005555556ede9b in command_loop_2 (ignore=XIL(0)) at keyboard.c:1091 val = XIL(0) #14 0x00005555557a22d5 in internal_catch (tag=XIL(0xd110), func=0x5555556ede6e , arg=XIL(0)) at eval.c:1112 val = XIL(0x45b00000000) c = 0x555555d53340 #15 0x00005555556ede39 in command_loop () at keyboard.c:1070 #16 0x00005555556ed537 in recursive_edit_1 () at keyboard.c:714 count = 1 val = make_fixnum(23456248667937) #17 0x00005555556ed6bb in Frecursive_edit () at keyboard.c:786 count = 0 buffer = XIL(0) #18 0x00005555556eb49d in main (argc=4, argv=0x7fffffffe8b8) at emacs.c:2086 stack_bottom_variable = 0x20 do_initial_setlocale = true no_loadup = false junk = 0x0 dname_arg = 0x0 ch_to_dir = 0x0 original_pwd = 0x0 dump_mode = 0x0 skip_args = 0 temacs = 0x0 attempt_load_pdump = true rlim = { rlim_cur = 10022912, rlim_max = 18446744073709551615 } sockfd = -1 --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=thread-bug-2.el Content-Description: thread-bug-2.el ;; -*- lexical-binding: t -*- (require 'threads) (require 'eieio) (require 'cl-lib) (require 'ring) (defun debug (fmt &rest args) (princ (apply #'format fmt args) #'external-debugging-output) (terpri #'external-debugging-output)) (define-error 'thread-utils-thread-interrupted "Thread was interrupted" 'error) (defun thread-utils-main-thread-p (&optional object) (let ((object (or object (current-thread)))) (and (threadp object) (eq object (car (all-threads)))))) (defun thread-utils-quitable-apply (fn &rest args) (let* ((this-thread (current-thread)) (quit-thread (make-thread (lambda nil (condition-case nil (cl-loop (sleep-for 3)) (quit (thread-signal this-thread 'quit nil)) (thread-utils-thread-interrupted nil)))))) (unwind-protect (apply fn args) (thread-signal quit-thread 'thread-utils-thread-interrupted nil)))) (defun thread-utils-condition-quitable-wait (condition) (cl-check-type condition condition-variable) (thread-utils-quitable-apply #'condition-wait condition)) (defun thread-utils-condition-wait (condition) (if (thread-utils-main-thread-p) (thread-utils-condition-quitable-wait condition) (condition-wait condition))) (defconst channel-default-capacity 16) (defclass channel-terminal nil ((mutex :initarg :mutex :type mutex) (condition :initarg :condition :type condition-variable) (msg-queue :initarg :msg-queue :type ring) (closed-p :initform nil) (other-terminal :type (or null channel-terminal)))) (defclass channel-source (channel-terminal) nil) (defclass channel-sink (channel-terminal) nil) (define-error 'channel-closed "Trying to send/recv from a closed channel") (defun make-channel (&optional capacity) (unless capacity (setq capacity channel-default-capacity)) (cl-check-type capacity (integer 1 *)) (let* ((mutex (make-mutex "channel")) (condition (make-condition-variable mutex "channel")) (msg-queue (make-ring capacity)) (source (channel-source :mutex mutex :condition condition :msg-queue msg-queue)) (sink (channel-sink :mutex mutex :condition condition :msg-queue msg-queue))) (oset source other-terminal sink) (oset sink other-terminal source) (cons source sink))) (cl-defgeneric channel-send ((source channel-source) message) (with-mutex (oref source mutex) (with-slots (condition msg-queue) source (while (and (not (channel-closed-p source)) (= (ring-size msg-queue) (ring-length msg-queue))) (thread-utils-condition-wait condition)) (when (channel-closed-p source) (signal 'channel-closed (list source))) (let ((inhibit-quit t)) (ring-insert msg-queue message) (when (= 1 (ring-length msg-queue)) (condition-notify condition t))) nil))) (cl-defgeneric channel-recv ((sink channel-terminal)) (with-mutex (oref sink mutex) (with-slots (condition msg-queue) sink (while (and (not (channel-closed-p sink)) (ring-empty-p msg-queue)) (thread-utils-condition-wait condition)) (when (channel-closed-p sink) (signal 'channel-closed (list sink))) (let ((inhibit-quit t)) (prog1 (ring-remove msg-queue) (when (= 1 (- (ring-size msg-queue) (ring-length msg-queue))) (condition-notify condition t))))))) (cl-defgeneric channel-peek ((sink channel-terminal)) (with-mutex (oref sink mutex) (with-slots (condition msg-queue) sink (while (and (not (channel-closed-p sink)) (ring-empty-p msg-queue)) (thread-utils-condition-wait condition)) (when (channel-closed-p sink) (signal 'channel-closed (list sink))) (ring-ref msg-queue -1)))) (cl-defgeneric channel-close ((terminal channel-terminal)) (with-mutex (oref terminal mutex) (with-slots (closed-p condition) terminal (setq closed-p t) (condition-notify condition t)) nil)) (cl-defmethod channel-closed-p ((source channel-source)) (with-mutex (oref source mutex) (with-slots (closed-p other-terminal) source (or closed-p (oref other-terminal closed-p))))) (cl-defmethod channel-closed-p ((sink channel-sink)) (with-mutex (oref sink mutex) (with-slots (closed-p other-terminal msg-queue) sink (or closed-p (and (oref other-terminal closed-p) (ring-empty-p msg-queue)))))) (defclass future nil ((channel :initform (make-channel 1)))) (defun make-future () (make-instance 'future)) (cl-defgeneric future-set ((future future) value) (with-slots (channel) future (let ((inhibit-quit t)) (condition-case nil (progn (debug "Sending future") (channel-send (car channel) value) (debug "Future send")) (channel-closed (signal 'error (list future)))) (debug "Closing future") (channel-close (car channel)) (debug "Future closed")))) (cl-defgeneric future-get ((future future)) (with-slots (channel) future (debug "Getting future") (channel-peek (cdr channel)) (debug "Future got"))) (defclass future-deferred (future) ((producer :initarg :producer :type function) (value-produced-p :initform nil) (mutex :initform (make-mutex "future-deferred")))) (defun make-deferred-future (producer) (make-instance 'future-deferred :producer producer)) (cl-defmethod future-get :before ((future future-deferred)) (with-slots (mutex value-produced-p producer) future (with-mutex mutex (unless value-produced-p (unwind-protect (make-thread (lambda nil (debug "Setting Future") (future-set future (funcall producer)) (debug "Future set")) "XEmacs") (setq value-produced-p t)))))) (let ((future (make-deferred-future (lambda nil 42)))) (future-get future)) --=-=-=-- From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 07:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andreas Politz Cc: 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156291767417007 (code B ref 36609); Fri, 12 Jul 2019 07:48:02 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 07:47:54 +0000 Received: from localhost ([127.0.0.1]:39209 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlqHa-0004QE-9P for submit@debbugs.gnu.org; Fri, 12 Jul 2019 03:47:54 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58219) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlqHZ-0004Q1-1T for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 03:47:53 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51268) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hlqHT-0003HY-5Y; Fri, 12 Jul 2019 03:47:47 -0400 Received: from [176.228.60.248] (port=3167 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hlqHS-0001aW-J9; Fri, 12 Jul 2019 03:47:47 -0400 Date: Fri, 12 Jul 2019 10:47:37 +0300 Message-Id: <83sgrb3d9i.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87muhks3b5.fsf@hochschule-trier.de> (message from Andreas Politz on Thu, 11 Jul 2019 22:51:10 +0200) References: <87muhks3b5.fsf@hochschule-trier.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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: Andreas Politz > Date: Thu, 11 Jul 2019 22:51:10 +0200 > > I think there is a race-condition in the implementation of threads. Not sure what you mean by "race condition". Since only one Lisp thread can run at any given time, where could this race happen, and between what threads? > I tried to find a minimal test-case, without success. Thus, I've > attached a lengthy source-file. Loading that file should trigger > this bug and may freeze your session. FWIW, it doesn't freeze my Emacs here, neither on GNU/Linux nor on MS-Windows (with today's master). Are you getting freezes with 100% reproducibility? If so, please show all the details of your build, as collected by report-emacs-bug. > Indications: > > 1. The main-thread has the name of one of created threads (XEmacs in > this case), instead of "emacs". I don't think this is related to the problem. I think we have a bug in the implementation of the 'name' attribute of threads: we call prctl(PR_SET_NAME), which AFAIU changes the name of the _calling_ thread, and the calling thread at that point is the main thread, see sys_thread_create. If I evaluate this: (make-thread 'ignore "XEmacs") and then attach a debugger, I see that the name of the main thread has changed to "XEmacs". > 2. Emacs stops processing all keyboard/mouse input while looping in > wait_reading_process_output. Sending commands via emacsclient still > works. > > GDB output: > > (gdb) info threads > Id Target Id Frame > * 1 Thread 0x7ffff17f5d40 (LWP 26264) "XEmacs" 0x000055555576eac0 in XPNTR (a=XIL(0x7ffff1312533)) at alloc.c:535 > 2 Thread 0x7ffff0ac4700 (LWP 26265) "gmain" 0x00007ffff50d1667 in poll () from /usr/lib/libc.so.6 > 3 Thread 0x7fffebd1a700 (LWP 26266) "gdbus" 0x00007ffff50d1667 in poll () from /usr/lib/libc.so.6 > 4 Thread 0x7fffeb519700 (LWP 26267) "dconf worker" 0x00007ffff50d1667 in poll () from /usr/lib/libc.so.6 > > (gdb) bt full This "bt full" is not enough, because it shows the backtrace of one thread only, the main thread. Please show the backtrace of the other 3 threads by typing "thread apply all bt full" instead. > #5 0x0000555555802a78 in wait_reading_process_output (time_limit=0, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at process.c:5423 > process_skipped = false > channel = 6 > nfds = 1 > Available = { > fds_bits = {32, 0 } > } Is the keyboard descriptor's bit in Available set or not? What is the contents of the fd_callback_info array at this point? > ;; -*- lexical-binding: t -*- > > (require 'threads) > (require 'eieio) > (require 'cl-lib) > (require 'ring) > > (defun debug (fmt &rest args) > (princ (apply #'format fmt args) #'external-debugging-output) > (terpri #'external-debugging-output)) Please describe what this program tries to accomplish, and how. It's not easy to reverse-engineer that from 200 lines of non-trivial code. It's possible that the reason(s) for the freeze will be apparent from describing your implementation ideas. Thanks. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 08:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: politza@hochschule-trier.de Cc: 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156291872518645 (code B ref 36609); Fri, 12 Jul 2019 08:06:02 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 08:05:25 +0000 Received: from localhost ([127.0.0.1]:39236 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlqYW-0004qe-Q5 for submit@debbugs.gnu.org; Fri, 12 Jul 2019 04:05:25 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35239) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlqYV-0004qT-IS for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 04:05:24 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51518) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hlqYQ-0002gu-18; Fri, 12 Jul 2019 04:05:18 -0400 Received: from [176.228.60.248] (port=4400 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hlqYO-0002F2-UF; Fri, 12 Jul 2019 04:05:17 -0400 Date: Fri, 12 Jul 2019 11:05:08 +0300 Message-Id: <83o91z3cgb.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <83sgrb3d9i.fsf@gnu.org> (message from Eli Zaretskii on Fri, 12 Jul 2019 10:47:37 +0300) References: <87muhks3b5.fsf@hochschule-trier.de> <83sgrb3d9i.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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 (---) > Date: Fri, 12 Jul 2019 10:47:37 +0300 > From: Eli Zaretskii > Cc: 36609@debbugs.gnu.org > > Please describe what this program tries to accomplish, and how. It's > not easy to reverse-engineer that from 200 lines of non-trivial code. > It's possible that the reason(s) for the freeze will be apparent from > describing your implementation ideas. Oh, and one more question: does the value of the global variable last_thread_error tell something interesting at that point? From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 09:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andreas Politz Cc: 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156292218623710 (code B ref 36609); Fri, 12 Jul 2019 09:04:01 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 09:03:06 +0000 Received: from localhost ([127.0.0.1]:39262 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlrSL-0006AM-Tr for submit@debbugs.gnu.org; Fri, 12 Jul 2019 05:03:06 -0400 Received: from mail-ot1-f45.google.com ([209.85.210.45]:41116) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlrSK-00069q-Ow for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 05:03:05 -0400 Received: by mail-ot1-f45.google.com with SMTP id o101so8756205ota.8 for <36609@debbugs.gnu.org>; Fri, 12 Jul 2019 02:03:04 -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=zHNRHJZaWTM5dTYtOB/B5Za/6ari5HWZ1jXI1ST8Yjw=; b=pCWJnDp/bLStE+HqQE3vLbgo54LG3Fax/vfmD2jBtGlVt+vyb8gbHNeTTg9i02fMI1 kX+HizPuW3jPTmnuLh2Z7AUMt/PdL3+9H6oUiDKJVlRB6XRu6wJ0XEQYvchGoxYdySmi mqr+wq2+i6qyd9OocSQv62vj9vg+j0DjBQgB30rF41Tj3q9YJSTv3OMLdDUwcFZbf8PD ja6OK3OfRqotfc528Zpn6asQxLlh/7/Ww30t2fk+DftyqFCRcsl+kJSI/wZQ/woIcFCp 4/TD/0hymryAnpTL9amfrrSux5nL4Oo0OloSnu7ApulkQ7d3H+SlfR+sVRKrAZmRetcX ubqA== 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=zHNRHJZaWTM5dTYtOB/B5Za/6ari5HWZ1jXI1ST8Yjw=; b=NVELFlAWlsy9H0o2GjBVKEA474yMHersLU/R0enbz9HAR7bBFiqTL1SDb4FxiGoF+d 4MPfjS7M4pZd2+RwIqzkisrgR/hxguO9m14XOta3oZ7GxRC+IW89I0uyLf24gbheKVIc MHQqRogymQiN/DBlJ3CFLQf6h78+g/Kz3F9Y8LA5gRn+0lV0z52iSC3JZcr90dW3SvC/ 4p/EX8PwQOTekoOFDCe7LNLH4jD3cVnhuBxPdJk6FUVM/ib+p3YjmvFMYWynv9Gqq+AU t4dw8QGS2E0p7rJ0bUeYVVmQznt4LFQq9h65FOVbq8pjwFh2x1PwbDCupKMlWimxKdiG 6k6Q== X-Gm-Message-State: APjAAAUCj336JHxdkVZgJTxT/znCi2BkSOiiXHxwWezIqsjl5nCTESiq gZY1iZGiZcsNg415xhh95mxS3WfPBacb4kD3kZQ= X-Google-Smtp-Source: APXvYqwzbQ1xMNFHmIESl33pt2Lh3LFxcxHMkHdU195gFNfW5yUwK6G5mlCGpczahJ11ZC5otLWzof2Hy54tP5/qmrY= X-Received: by 2002:a9d:6014:: with SMTP id h20mr7548994otj.210.1562922179063; Fri, 12 Jul 2019 02:02:59 -0700 (PDT) MIME-Version: 1.0 References: <87muhks3b5.fsf@hochschule-trier.de> In-Reply-To: <87muhks3b5.fsf@hochschule-trier.de> From: Pip Cet Date: Fri, 12 Jul 2019 09:02:22 +0000 Message-ID: Content-Type: multipart/mixed; boundary="0000000000004bed0f058d782d6c" X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.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 the administrator of that system for details. Content preview: On Thu, Jul 11, 2019 at 8:52 PM Andreas Politz wrote: > I think there is a race-condition in the implementation of threads. I > tried to find a minimal test-case, without success. Thus, I've attache [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: hochschule-trier.de] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pipcet[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.210.45 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.210.45 listed in wl.mailspike.net] 1.3 PDS_NO_HELO_DNS High profile HELO but no A record 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: 0.3 (/) --0000000000004bed0f058d782d6c Content-Type: text/plain; charset="UTF-8" On Thu, Jul 11, 2019 at 8:52 PM Andreas Politz wrote: > I think there is a race-condition in the implementation of threads. I > tried to find a minimal test-case, without success. Thus, I've attached > a lengthy source-file. Loading that file should trigger this bug and > may freeze your session. It does here, so I can provide further debugging information if needed. On first glance, it appears that xgselect returns abnormally with g_main_context acquired in one thread, and then other threads fail to acquire it and loop endlessly. Can you confirm that this very dirty patch avoids (it's not a fix by any means!) the problem? --0000000000004bed0f058d782d6c Content-Type: text/x-patch; charset="US-ASCII"; name="Avoid-glib-issue.patch" Content-Disposition: attachment; filename="Avoid-glib-issue.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jxzvh69j0 ZGlmZiAtLWdpdCBhL3NyYy94Z3NlbGVjdC5jIGIvc3JjL3hnc2VsZWN0LmMKaW5kZXggOTk4MmEx ZjBlOS4uOWZmZWI2YzY2YyAxMDA2NDQKLS0tIGEvc3JjL3hnc2VsZWN0LmMKKysrIGIvc3JjL3hn c2VsZWN0LmMKQEAgLTU4LDggKzU4LDE2IEBAIHhnX3NlbGVjdCAoaW50IGZkc19saW0sIGZkX3Nl dCAqcmZkcywgZmRfc2V0ICp3ZmRzLCBmZF9zZXQgKmVmZHMsCiAgIGludCBpLCBuZmRzLCB0bW9f aW5fbWlsbGlzZWMsIG11c3RfZnJlZSA9IDA7CiAgIGJvb2wgbmVlZF90b19kaXNwYXRjaDsKIAor ICBwdHJkaWZmX3QgY291bnQgPSBTUEVDUERMX0lOREVYICgpOwogICBjb250ZXh0ID0gZ19tYWlu X2NvbnRleHRfZGVmYXVsdCAoKTsKLSAgY29udGV4dF9hY3F1aXJlZCA9IGdfbWFpbl9jb250ZXh0 X2FjcXVpcmUgKGNvbnRleHQpOworICBjb250ZXh0X2FjcXVpcmVkID0gdHJ1ZTsKKworICBhdXRv IHZvaWQgcmVsZWFzZV9nX21haW5fY29udGV4dCAodm9pZCkKKyAgeworICB9CisKKyAgaWYgKGNv bnRleHRfYWNxdWlyZWQpCisgICAgcmVjb3JkX3Vud2luZF9wcm90ZWN0X3ZvaWQgKHJlbGVhc2Vf Z19tYWluX2NvbnRleHQpOwogICAvKiBGSVhNRTogSWYgd2UgY291bGRuJ3QgYWNxdWlyZSB0aGUg Y29udGV4dCwgd2UganVzdCBzaWxlbnRseSBwcm9jZWVkCiAgICAgIGJlY2F1c2UgdGhpcyBmdW5j dGlvbiBoYW5kbGVzIG1vcmUgdGhhbiBqdXN0IGdsaWIgZmlsZSBkZXNjcmlwdG9ycy4KICAgICAg Tm90ZSB0aGF0LCBhcyBpbXBsZW1lbnRlZCwgdGhpcyBmYWlsdXJlIGlzIGNvbXBsZXRlbHkgc2ls ZW50OiB0aGVyZSBpcwpAQCAtMTY0LDkgKzE3Miw2IEBAIHhnX3NlbGVjdCAoaW50IGZkc19saW0s IGZkX3NldCAqcmZkcywgZmRfc2V0ICp3ZmRzLCBmZF9zZXQgKmVmZHMsCiAgICAgICBlcnJubyA9 IHBzZWxlY3RfZXJybm87CiAgICAgfQogCi0gIGlmIChjb250ZXh0X2FjcXVpcmVkKQotICAgIGdf bWFpbl9jb250ZXh0X3JlbGVhc2UgKGNvbnRleHQpOwotCiAgIC8qIFRvIG5vdCBoYXZlIHRvIHJl Y2FsY3VsYXRlIHRpbWVvdXQsIHJldHVybiBsaWtlIHRoaXMuICAqLwogICBpZiAoKG91cl9mZHMg PiAwIHx8IChuZmRzID09IDAgJiYgdG1vcCA9PSAmdG1vKSkgJiYgKHJldHZhbCA9PSAwKSkKICAg ICB7CkBAIC0xNzQsNiArMTc5LDYgQEAgeGdfc2VsZWN0IChpbnQgZmRzX2xpbSwgZmRfc2V0ICpy ZmRzLCBmZF9zZXQgKndmZHMsIGZkX3NldCAqZWZkcywKICAgICAgIGVycm5vID0gRUlOVFI7CiAg ICAgfQogCi0gIHJldHVybiByZXR2YWw7CisgIHJldHVybiB1bmJpbmRfdG8gKGNvdW50LCBRbmls KSwgcmV0dmFsOwogfQogI2VuZGlmIC8qIEhBVkVfR0xJQiAqLwo= --0000000000004bed0f058d782d6c-- From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 12:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156293536719427 (code B ref 36609); Fri, 12 Jul 2019 12:43:02 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 12:42:47 +0000 Received: from localhost ([127.0.0.1]:39354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlusu-00053E-Fa for submit@debbugs.gnu.org; Fri, 12 Jul 2019 08:42:46 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56822) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlusr-00052y-JQ for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 08:42:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39469) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hlusf-0004xT-NW; Fri, 12 Jul 2019 08:42:30 -0400 Received: from [176.228.60.248] (port=1368 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hluse-0005ZJ-9p; Fri, 12 Jul 2019 08:42:29 -0400 Date: Fri, 12 Jul 2019 15:42:20 +0300 Message-Id: <83muhj2zmb.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Pip Cet on Fri, 12 Jul 2019 09:02:22 +0000) References: <87muhks3b5.fsf@hochschule-trier.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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: Pip Cet > Date: Fri, 12 Jul 2019 09:02:22 +0000 > Cc: 36609@debbugs.gnu.org > > On Thu, Jul 11, 2019 at 8:52 PM Andreas Politz > wrote: > > I think there is a race-condition in the implementation of threads. I > > tried to find a minimal test-case, without success. Thus, I've attached > > a lengthy source-file. Loading that file should trigger this bug and > > may freeze your session. > > It does here, so I can provide further debugging information if > needed. Thanks, can you provide the info I asked for? > On first glance, it appears that xgselect returns abnormally with > g_main_context acquired in one thread, and then other threads fail > to acquire it and loop endlessly. If you can describe what causes this to happen, I think we might be half-way to a solution. > + ptrdiff_t count = SPECPDL_INDEX (); I don't think we should do that at this low level. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 12:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andreas Politz Cc: 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156293552119691 (code B ref 36609); Fri, 12 Jul 2019 12:46:01 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 12:45:21 +0000 Received: from localhost ([127.0.0.1]:39358 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hluvQ-00057X-Lu for submit@debbugs.gnu.org; Fri, 12 Jul 2019 08:45:20 -0400 Received: from mail-oi1-f172.google.com ([209.85.167.172]:43439) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hluvO-00057H-PU for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 08:45:19 -0400 Received: by mail-oi1-f172.google.com with SMTP id w79so7163388oif.10 for <36609@debbugs.gnu.org>; Fri, 12 Jul 2019 05:45:18 -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=W9Fh52n93BAaOZXJPz2/3ms5OSpST+RP++o0J5Lljzg=; b=tnYilC2okzQbS6vZ88wKrfFLlBoT8VL6rswycjoEXe5r+GVyrZQ5NgfKPZSD6t5yzT 3cu87Zbb7lo+dxJrhTd4YksO4jhvfahhRHdDbWqw0bVe7cbHcKEf54jwk8YKCIMfxhY+ D441QqdBPRktnUthN1zSC7pyXJ74ev9rz/wW7wQzMXOvpmfOTvlzjhjIrnUNo8LsHMWm lQOg6LaWOTTYvq/etzqSIO73z4Gy3D434IQW+gvrUElP6oOkyssh4WhmNfmnpyGCpfcP KeEol0PHykVBwSk/dnaNKO1md8fZL5s3Pn9zLWFQmeaLyMlX0byFHPLZYC0U7mMRytDg PLDw== 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=W9Fh52n93BAaOZXJPz2/3ms5OSpST+RP++o0J5Lljzg=; b=E/6sY8jYDWmMXh67weRMAYJNhSIZdgT/IyurmPJE/a4dNJZME9g5r2E5fjc8DHXBBF LXz30kx1iEHrBt0umq0zaOWV2xMspA9SaBIcMTDOYpY38xPoLXo7qiwh2yQd/0N9Nk/Q u5E8eZnIiJKqmwCf1nZSysyaCWzzNyQ3NrzUlRod2CNR6iQy8yCiHMTLsivmPv+eQbvc Pypch4LzfxHotoJ9TQqDWUqQzVwqH9S4dmpAnipx9b79ibj94AU5OMYrgi8ujeViHMSn A/NwvE7j4b8925KSEIHc+3q5qmtDHcU6+ojQUwWOI95KF5Qluy7F45Hc15rmbir0Ysv8 kNWQ== X-Gm-Message-State: APjAAAWWV6VpvBSCPusdU+jMZzUl43MFGtsMH7ma9cSioG0puvRpUlWc JueXn/Myk+vz6LJImJtpjEnPotn3wLgz4rAp+s8= X-Google-Smtp-Source: APXvYqwwGkgsiBXtUK7ILtr2AeUfaOD0ArWxcag1Ayb3SUS5SqJb1TZIIYsFOC+vqiqdtdzCd1d9kYfXmmYsG6df/64= X-Received: by 2002:aca:4790:: with SMTP id u138mr6064676oia.44.1562935513113; Fri, 12 Jul 2019 05:45:13 -0700 (PDT) MIME-Version: 1.0 References: <87muhks3b5.fsf@hochschule-trier.de> In-Reply-To: From: Pip Cet Date: Fri, 12 Jul 2019 12:44:35 +0000 Message-ID: Content-Type: multipart/mixed; boundary="00000000000011070b058d7b485c" X-Spam-Score: 0.0 (/) 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 (-) --00000000000011070b058d7b485c Content-Type: text/plain; charset="UTF-8" On Fri, Jul 12, 2019 at 9:02 AM Pip Cet wrote: > > On Thu, Jul 11, 2019 at 8:52 PM Andreas Politz > wrote: > > I think there is a race-condition in the implementation of threads. I > > tried to find a minimal test-case, without success. Thus, I've attached > > a lengthy source-file. Loading that file should trigger this bug and > > may freeze your session. > > It does here, so I can provide further debugging information if > needed. On first glance, it appears that xgselect returns abnormally > with g_main_context acquired in one thread, and then other threads > fail to acquire it and loop endlessly. Okay, I'm still not sure this is really the problem Andreas was seeing, but this code fails to work with xg_select: (let ((thread (make-thread (lambda () (sleep-for 3))))) (thread-yield) (thread-signal thread 'error nil)) Proposed patch attached. --00000000000011070b058d7b485c Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Protect-against-abnormal-exit-in-xg_select.patch" Content-Disposition: attachment; filename="0001-Protect-against-abnormal-exit-in-xg_select.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jy03fdfy0 RnJvbSAwMTIzNDFhOGE2NzRiMTMwYzMzNWNmZGQ4ZDI0ODg4NDA2ZTk4ZWNlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaXAgQ2V0IDxwaXBjZXRAZ21haWwuY29tPgpEYXRlOiBGcmks IDEyIEp1bCAyMDE5IDEyOjM5OjI5ICswMDAwClN1YmplY3Q6IFtQQVRDSF0gUHJvdGVjdCBhZ2Fp bnN0IGFibm9ybWFsIGV4aXQgaW4gYHhnX3NlbGVjdCcKCiogc3JjL3hnc2VsZWN0LmMgKHJlbGVh c2VfZ19tYWluX2NvbnRleHQpOiBOZXcgZnVuY3Rpb24uCih4Z19zZWxlY3QpOiBVbndpbmQtcHJv dGVjdCByZWxlYXNlIG9mIHRoZSBHTGliIG1haW4gY29udGV4dC4KLS0tCiBzcmMveGdzZWxlY3Qu YyB8IDE4ICsrKysrKysrKysrKysrKy0tLQogMSBmaWxlIGNoYW5nZWQsIDE1IGluc2VydGlvbnMo KyksIDMgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvc3JjL3hnc2VsZWN0LmMgYi9zcmMveGdz ZWxlY3QuYwppbmRleCA5OTgyYTFmMGU5Li5lMzUzMTBiZTM0IDEwMDY0NAotLS0gYS9zcmMveGdz ZWxlY3QuYworKysgYi9zcmMveGdzZWxlY3QuYwpAQCAtMjksNiArMjksMTUgQEAgQ29weXJpZ2h0 IChDKSAyMDA5LTIwMTkgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCiAjaW5jbHVkZSAi YmxvY2tpbnB1dC5oIgogI2luY2x1ZGUgInN5c3RpbWUuaCIKIAorLyogSGVscGVyIGZ1bmN0aW9u IGZvciBgdW53aW5kX3Byb3RlY3QnLiAgKi8KKworc3RhdGljIHZvaWQgcmVsZWFzZV9nX21haW5f Y29udGV4dCAodm9pZCAqcHRyKQoreworICBHTWFpbkNvbnRleHQgKmNvbnRleHQgPSAoR01haW5D b250ZXh0ICopIHB0cjsKKworICBnX21haW5fY29udGV4dF9yZWxlYXNlIChjb250ZXh0KTsKK30K KwogLyogYHhnX3NlbGVjdCcgaXMgYSBgcHNlbGVjdCcgcmVwbGFjZW1lbnQuICBXaHkgZG8gd2Ug bmVlZCBhIHNlcGFyYXRlIGZ1bmN0aW9uPwogICAgMS4gVGltZW91dHMuICBHbGliIGFuZCBHdGsg cmVseSBvbiB0aW1lciBldmVudHMuICBJZiB3ZSBkaWQgcHNlbGVjdAogICAgICAgd2l0aCBhIGdy ZWF0ZXIgdGltZW91dCB0aGVuIHRoZSBvbmUgc2NoZWR1bGVkIGJ5IEdsaWIsIHdlIHdvdWxkCkBA IC01OCw4ICs2NywxMiBAQCB4Z19zZWxlY3QgKGludCBmZHNfbGltLCBmZF9zZXQgKnJmZHMsIGZk X3NldCAqd2ZkcywgZmRfc2V0ICplZmRzLAogICBpbnQgaSwgbmZkcywgdG1vX2luX21pbGxpc2Vj LCBtdXN0X2ZyZWUgPSAwOwogICBib29sIG5lZWRfdG9fZGlzcGF0Y2g7CiAKKyAgcHRyZGlmZl90 IGNvdW50ID0gU1BFQ1BETF9JTkRFWCAoKTsKICAgY29udGV4dCA9IGdfbWFpbl9jb250ZXh0X2Rl ZmF1bHQgKCk7CiAgIGNvbnRleHRfYWNxdWlyZWQgPSBnX21haW5fY29udGV4dF9hY3F1aXJlIChj b250ZXh0KTsKKworICBpZiAoY29udGV4dF9hY3F1aXJlZCkKKyAgICByZWNvcmRfdW53aW5kX3By b3RlY3RfcHRyIChyZWxlYXNlX2dfbWFpbl9jb250ZXh0LCAodm9pZCAqKWNvbnRleHQpOwogICAv KiBGSVhNRTogSWYgd2UgY291bGRuJ3QgYWNxdWlyZSB0aGUgY29udGV4dCwgd2UganVzdCBzaWxl bnRseSBwcm9jZWVkCiAgICAgIGJlY2F1c2UgdGhpcyBmdW5jdGlvbiBoYW5kbGVzIG1vcmUgdGhh biBqdXN0IGdsaWIgZmlsZSBkZXNjcmlwdG9ycy4KICAgICAgTm90ZSB0aGF0LCBhcyBpbXBsZW1l bnRlZCwgdGhpcyBmYWlsdXJlIGlzIGNvbXBsZXRlbHkgc2lsZW50OiB0aGVyZSBpcwpAQCAtMTY0 LDkgKzE3Nyw2IEBAIHhnX3NlbGVjdCAoaW50IGZkc19saW0sIGZkX3NldCAqcmZkcywgZmRfc2V0 ICp3ZmRzLCBmZF9zZXQgKmVmZHMsCiAgICAgICBlcnJubyA9IHBzZWxlY3RfZXJybm87CiAgICAg fQogCi0gIGlmIChjb250ZXh0X2FjcXVpcmVkKQotICAgIGdfbWFpbl9jb250ZXh0X3JlbGVhc2Ug KGNvbnRleHQpOwotCiAgIC8qIFRvIG5vdCBoYXZlIHRvIHJlY2FsY3VsYXRlIHRpbWVvdXQsIHJl dHVybiBsaWtlIHRoaXMuICAqLwogICBpZiAoKG91cl9mZHMgPiAwIHx8IChuZmRzID09IDAgJiYg dG1vcCA9PSAmdG1vKSkgJiYgKHJldHZhbCA9PSAwKSkKICAgICB7CkBAIC0xNzQsNiArMTg0LDgg QEAgeGdfc2VsZWN0IChpbnQgZmRzX2xpbSwgZmRfc2V0ICpyZmRzLCBmZF9zZXQgKndmZHMsIGZk X3NldCAqZWZkcywKICAgICAgIGVycm5vID0gRUlOVFI7CiAgICAgfQogCisgIHVuYmluZF90byAo Y291bnQsIFFuaWwpOworCiAgIHJldHVybiByZXR2YWw7CiB9CiAjZW5kaWYgLyogSEFWRV9HTElC ICovCi0tIAoyLjIwLjEKCg== --00000000000011070b058d7b485c-- From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 12:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156293614120546 (code B ref 36609); Fri, 12 Jul 2019 12:56:01 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 12:55:41 +0000 Received: from localhost ([127.0.0.1]:39362 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlv5Q-0005LK-QS for submit@debbugs.gnu.org; Fri, 12 Jul 2019 08:55:41 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60393) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlv5O-0005L6-6R for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 08:55:38 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39596) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hlv5I-00079S-F8; Fri, 12 Jul 2019 08:55:32 -0400 Received: from [176.228.60.248] (port=2170 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hlv5H-0006cs-Bp; Fri, 12 Jul 2019 08:55:31 -0400 Date: Fri, 12 Jul 2019 15:55:22 +0300 Message-Id: <83k1cn2z0l.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Pip Cet on Fri, 12 Jul 2019 12:44:35 +0000) References: <87muhks3b5.fsf@hochschule-trier.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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: Pip Cet > Date: Fri, 12 Jul 2019 12:44:35 +0000 > Cc: 36609@debbugs.gnu.org > > Okay, I'm still not sure this is really the problem Andreas was > seeing, but this code fails to work with xg_select: > > (let ((thread (make-thread (lambda () > (sleep-for 3))))) > (thread-yield) > (thread-signal thread 'error nil)) What do you mean by "fails"? What do you see when you eval this? > Proposed patch attached. As I said earlier, I don't think it's right to use stack unwinding at this level. (Did you try this in a -nw session?) I'd appreciate a description of what you think happens here, and why. Thanks. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 12:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156293631720789 (code B ref 36609); Fri, 12 Jul 2019 12:59:02 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 12:58:37 +0000 Received: from localhost ([127.0.0.1]:39366 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlv8G-0005PE-Dr for submit@debbugs.gnu.org; Fri, 12 Jul 2019 08:58:36 -0400 Received: from mail-oi1-f173.google.com ([209.85.167.173]:36508) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlv8E-0005P1-G4 for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 08:58:35 -0400 Received: by mail-oi1-f173.google.com with SMTP id w7so7199496oic.3 for <36609@debbugs.gnu.org>; Fri, 12 Jul 2019 05:58:34 -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=FNu3Mbi68by3G5rUEgKAu7KRrqoiBdql1+72xqNJFx0=; b=tmV0ZhYgeHTPlkXOXqjOtBrOe9KPlKvyA4+t69q7zbYdBipHQCLPT3rGasHUh1BW6w cyPirBAwdWJ+ED0rfmcQEqh86IqlzIuWitpKh2qviQ0gfTpAhr7Bq0ssEy7fnVzi3zgc NWQUnnTJuyQL/LyNyL4dVy9t/Rj4OJHoxHY6Xk06OyRlu9njTvMAhuKt3cDxgtvbA04F lSEA0fPsBqr9norFwEbejUOqHm0KVpeKWh4mNWbqiOY7084gpGQmawu7Sw2supl1OWG3 Wb0rsoNfnBDDKE8932lV2DknQD58gTheQtwYHRSiyuTg5lwSvJ4IwQfPJT5sPcGXUDw4 7Uiw== 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=FNu3Mbi68by3G5rUEgKAu7KRrqoiBdql1+72xqNJFx0=; b=NKZBTyceG19clhJ0g7mw/CrokUbeAVlfYwfzpqAhviiFeG/IVHvfkcjXp8PuhjrMgP +v9LsBXj9CGCEK3wMl4AAPAF9UoIEjSxK5goxXl3JtCSMPhd79plrOD9y7AE3zY8eM5R qKcqtytuKPhRAc1ahpuWrqngmBlImOXqhx/v3zF329hMx4j/sgKYT8rYwYqEqDFK1qRh pu9YNAysSFiY1yjvqJx5ZDjbPB69BKWBEP7SKFfmzFfYC2oq9DbyhWf45KNPEyuGhjZ2 T7NyXtKzHee0g8JmoM4CKytAlUmNit5Y2cdJi2QXCrIOGHbDeShM1Q195JmAzor5BTzL tHFw== X-Gm-Message-State: APjAAAXGi9vyPcIqOEEO39F4TZ18J6btkKPi5yoIyLowSzNNqiOPzDdo WLMHGvA1ryMwsxG5WZCzkDU5s4oxVvIezJb2bj0= X-Google-Smtp-Source: APXvYqx+Knc8NnxqIYypOyc5OuNwpoKWETAMFN3vC+8jOpreHyk1YAUveMGKdRxcK00fUEuAG7Pu/c3ckGhVEXzYfdw= X-Received: by 2002:aca:aa93:: with SMTP id t141mr5873315oie.128.1562936308527; Fri, 12 Jul 2019 05:58:28 -0700 (PDT) MIME-Version: 1.0 References: <87muhks3b5.fsf@hochschule-trier.de> <83muhj2zmb.fsf@gnu.org> In-Reply-To: <83muhj2zmb.fsf@gnu.org> From: Pip Cet Date: Fri, 12 Jul 2019 12:57:51 +0000 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) 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, Jul 12, 2019 at 12:42 PM Eli Zaretskii wrote: > > > From: Pip Cet > > Date: Fri, 12 Jul 2019 09:02:22 +0000 > > Cc: 36609@debbugs.gnu.org > > > > On Thu, Jul 11, 2019 at 8:52 PM Andreas Politz > > wrote: > > > I think there is a race-condition in the implementation of threads. I > > > tried to find a minimal test-case, without success. Thus, I've attached > > > a lengthy source-file. Loading that file should trigger this bug and > > > may freeze your session. > > > > It does here, so I can provide further debugging information if > > needed. > > Thanks, can you provide the info I asked for? Yes, albeit not right now. > > On first glance, it appears that xgselect returns abnormally with > > g_main_context acquired in one thread, and then other threads fail > > to acquire it and loop endlessly. > > If you can describe what causes this to happen, I think we might be > half-way to a solution. Here's the backtrace of the abnormal exit I see with the patch attached: (gdb) bt full #0 0x00000000006bf987 in release_g_main_context (ptr=0xc1d070) at xgselect.c:36 context = 0x7fffedf79710 #1 0x0000000000616f03 in do_one_unbind (this_binding=0x7fffedf79770, unwinding=true, bindflag=SET_INTERNAL_UNBIND) at eval.c:3446 #2 0x0000000000617245 in unbind_to (count=0, value=XIL(0)) at eval.c:3567 this_binding = { kind = SPECPDL_UNWIND_PTR, unwind = { kind = SPECPDL_UNWIND_PTR, func = 0x6bf97b , arg = XIL(0xc1d070), eval_depth = 0 }, unwind_array = { kind = SPECPDL_UNWIND_PTR, nelts = 7076219, array = 0xc1d070 }, unwind_ptr = { kind = SPECPDL_UNWIND_PTR, func = 0x6bf97b , arg = 0xc1d070 }, unwind_int = { kind = SPECPDL_UNWIND_PTR, func = 0x6bf97b , arg = 12701808 }, unwind_excursion = { kind = SPECPDL_UNWIND_PTR, marker = XIL(0x6bf97b), window = XIL(0xc1d070) }, unwind_void = { kind = SPECPDL_UNWIND_PTR, func = 0x6bf97b }, let = { kind = SPECPDL_UNWIND_PTR, symbol = XIL(0x6bf97b), old_value = XIL(0xc1d070), where = XIL(0), saved_value = XIL(0xef26a0) }, bt = { kind = SPECPDL_UNWIND_PTR, debug_on_exit = false, function = XIL(0x6bf97b), args = 0xc1d070, nargs = 0 } } quitf = XIL(0) #3 0x00000000006116df in unwind_to_catch (catch=0x7fffd8000c50, type=NONLOCAL_EXIT_SIGNAL, value=XIL(0x14d3653)) at eval.c:1162 last_time = false #4 0x00000000006126d9 in signal_or_quit (error_symbol=XIL(0x90), data=XIL(0), keyboard_quit=false) at eval.c:1674 unwind_data = XIL(0x14d3653) conditions = XIL(0x7ffff05d676b) string = XIL(0x5f5e77) real_error_symbol = XIL(0x90) clause = XIL(0x30) h = 0x7fffd8000c50 #5 0x00000000006122e9 in Fsignal (error_symbol=XIL(0x90), data=XIL(0)) at eval.c:1564 #6 0x0000000000698901 in post_acquire_global_lock (self=0xe09db0) at thread.c:115 sym = XIL(0x90) data = XIL(0) prev_thread = 0xa745c0 #7 0x000000000069892b in acquire_global_lock (self=0xe09db0) at thread.c:123 #8 0x0000000000699303 in really_call_select (arg=0x7fffedf79a70) at thread.c:596 sa = 0x7fffedf79a70 self = 0xe09db0 oldset = { __val = {0, 0, 7, 0, 80, 140736817269952, 2031, 2080, 18446744073709550952, 32, 343597383808, 4, 0, 472446402655, 511101108348, 0} } #9 0x00000000005e5ee0 in flush_stack_call_func (func=0x699239 , arg=0x7fffedf79a70) at alloc.c:4969 end = 0x7fffedf79a30 self = 0xe09db0 sentry = { o = { __max_align_ll = 0, __max_align_ld = } } #10 0x0000000000699389 in thread_select (func=0x419320 , max_fds=9, rfds=0x7fffedf79fa0, wfds=0x7fffedf79f20, efds=0x0, timeout=0x7fffedf7a260, sigmask=0x0) at thread.c:616 sa = { func = 0x419320 , max_fds = 9, rfds = 0x7fffedf79fa0, wfds = 0x7fffedf79f20, efds = 0x0, timeout = 0x7fffedf7a260, sigmask = 0x0, result = 1 } #11 0x00000000006bfef5 in xg_select (fds_lim=9, rfds=0x7fffedf7a300, wfds=0x7fffedf7a280, efds=0x0, timeout=0x7fffedf7a260, sigmask=0x0) at xgselect.c:130 all_rfds = { fds_bits = {8, 0 } } all_wfds = { fds_bits = {0 } } tmo = { tv_sec = 0, tv_nsec = 0 } tmop = 0x7fffedf7a260 context = 0xc1d070 have_wfds = true gfds_buf = {{ fd = 5, events = 1, revents = 0 }, { fd = 6, events = 1, revents = 0 }, { fd = 8, events = 1, revents = 0 }, { fd = 0, events = 0, revents = 0 } } gfds = 0x7fffedf79b10 gfds_size = 128 n_gfds = 3 retval = 0 our_fds = 0 max_fds = 8 context_acquired = true i = 3 nfds = 0 tmo_in_millisec = -1 must_free = 0 need_to_dispatch = false count = 3 #12 0x000000000066b757 in wait_reading_process_output (time_limit=3, nsecs=0, read_kbd=0, do_display=false, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at process.c:5423 process_skipped = false channel = 0 nfds = 0 Available = { fds_bits = {8, 0 } } Writeok = { fds_bits = {0 } } check_write = true check_delay = 0 no_avail = false xerrno = 0 proc = XIL(0x7fffedf7a440) timeout = { tv_sec = 3, tv_nsec = 0 } end_time = { tv_sec = 1562935633, tv_nsec = 911868453 } timer_delay = { tv_sec = 0, tv_nsec = -1 } got_output_end_time = { tv_sec = 0, tv_nsec = -1 } wait = TIMEOUT got_some_output = -1 prev_wait_proc_nbytes_read = 0 retry_for_async = false count = 2 now = { tv_sec = 0, tv_nsec = -1 } #13 0x0000000000429bf6 in Fsleep_for (seconds=make_fixnum(3), milliseconds=XIL(0)) at dispnew.c:5825 t = { tv_sec = 3, tv_nsec = 0 } tend = { tv_sec = 1562935633, tv_nsec = 911868112 } duration = 3 #14 0x0000000000613e99 in eval_sub (form=XIL(0xf6df73)) at eval.c:2273 i = 2 maxargs = 2 args_left = XIL(0) numargs = 1 original_fun = XIL(0x7fffefa9fb98) original_args = XIL(0xf6df83) count = 1 fun = XIL(0xa756a5) val = XIL(0) funcar = make_fixnum(35184372085343) argvals = {make_fixnum(3), XIL(0), XIL(0), XIL(0), XIL(0), XIL(0), XIL(0), XIL(0)} #15 0x0000000000610032 in Fprogn (body=XIL(0)) at eval.c:462 form = XIL(0xf6df73) val = XIL(0) #16 0x0000000000616102 in funcall_lambda (fun=XIL(0xf6da43), nargs=0, arg_vector=0xe09dd8) at eval.c:3065 val = XIL(0xc0) syms_left = XIL(0) next = XIL(0x3400000013) lexenv = XIL(0) count = 1 i = 0 optional = false rest = false #17 0x0000000000615542 in Ffuncall (nargs=1, args=0xe09dd0) at eval.c:2813 fun = XIL(0xf6da43) original_fun = XIL(0xf6da43) funcar = XIL(0xc0) numargs = 0 val = XIL(0xaf72e0) count = 0 #18 0x000000000069956f in invoke_thread_function () at thread.c:702 count = 0 #19 0x0000000000611d61 in internal_condition_case (bfun=0x69953e , handlers=XIL(0x30), hfun=0x699596 ) at eval.c:1351 val = make_fixnum(1405386) c = 0x7fffd8000c50 #20 0x0000000000699697 in run_thread (state=0xe09db0) at thread.c:741 stack_pos = { __max_align_ll = 0, __max_align_ld = 0 } self = 0xe09db0 iter = 0x0 c = 0x7fffd8000b20 #21 0x00007ffff4b38fa3 in start_thread (arg=) at pthread_create.c:486 ret = pd = now = unwind_buf = { cancel_jmp_buf = {{ jmp_buf = {140737185822464, -1249422724209328276, 140737488341374, 140737488341375, 140737185822464, 0, 1249453444682727276, 1249398985402204012}, mask_was_saved = 0 }}, priv = { pad = {0x0, 0x0, 0x0, 0x0}, data = { prev = 0x0, cleanup = 0x0, canceltype = 0 } } } not_first_call = #22 0x00007ffff49724cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Lisp Backtrace: "sleep-for" (0xedf7a530) 0xf6da40 Lisp type 3 post_acquire_global_lock () can return abnormally (I didn't know that), so really_call_select() can, too, so thread_select() can, too. > > + ptrdiff_t count = SPECPDL_INDEX (); > > I don't think we should do that at this low level. You're right, it does stick out. I think we're safe because we're calling Fsignal with the global lock held, but it's not a pretty or well-documented situation. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 13:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156293831423811 (code B ref 36609); Fri, 12 Jul 2019 13:32:02 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 13:31:54 +0000 Received: from localhost ([127.0.0.1]:39385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlveT-0006Bz-Kv for submit@debbugs.gnu.org; Fri, 12 Jul 2019 09:31:53 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42811) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlveQ-0006Bk-PZ for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 09:31:51 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40298) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hlveK-000686-HH; Fri, 12 Jul 2019 09:31:44 -0400 Received: from [176.228.60.248] (port=4353 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hlveE-0008KD-03; Fri, 12 Jul 2019 09:31:43 -0400 Date: Fri, 12 Jul 2019 16:31:24 +0300 Message-Id: <83ims72xcj.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Pip Cet on Fri, 12 Jul 2019 12:57:51 +0000) References: <87muhks3b5.fsf@hochschule-trier.de> <83muhj2zmb.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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: Pip Cet > Date: Fri, 12 Jul 2019 12:57:51 +0000 > Cc: politza@hochschule-trier.de, 36609@debbugs.gnu.org > > Lisp Backtrace: > "sleep-for" (0xedf7a530) > 0xf6da40 Lisp type 3 > > post_acquire_global_lock () can return abnormally (I didn't know > that), so really_call_select() can, too, so thread_select() can, too. Do you know which code sets current_thread->error_symbol, and what is that error symbol? > > > + ptrdiff_t count = SPECPDL_INDEX (); > > > > I don't think we should do that at this low level. > > You're right, it does stick out. I think we're safe because we're > calling Fsignal with the global lock held, but it's not a pretty or > well-documented situation. Is this the main thread which does that? if so, there should be no problem with holding the global lock in this case, is there? If this is not the main thread, then the error handlers should be set so as to log the error in last_thread_error, and then terminate the thread (via exiting the thread function, AFAIR). If this is not what happens, I'd like to know what does happen here, and why. Thanks. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 13:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156293886224621 (code B ref 36609); Fri, 12 Jul 2019 13:42:02 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 13:41:02 +0000 Received: from localhost ([127.0.0.1]:39397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlvnJ-0006Od-5I for submit@debbugs.gnu.org; Fri, 12 Jul 2019 09:41:02 -0400 Received: from mail-oi1-f196.google.com ([209.85.167.196]:34097) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlvnG-0006ON-HK for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 09:40:59 -0400 Received: by mail-oi1-f196.google.com with SMTP id l12so7321587oil.1 for <36609@debbugs.gnu.org>; Fri, 12 Jul 2019 06:40:58 -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=1DEIH5Jv/CWabnOp3GZ/IY4thuBSAYjd8Ue6uf+1xX0=; b=HioYuA5HnZHQYRQ5PWlK/E9sl1eWf1gelBUXgKOgkMMXErsr2HmVkLlzBvyKRPpWDB +82b0sbbXJ2QxNVerWoJS7hy6YntoJ9ClNQjjLEN+SsDlaK/J2TbmjoOtmVtlay5uc/M 8k03keUNc3z0VwvGsz1mYOHRR0Z52gy2WHIuSyrBM6Vmrrh3EQT06ufCd5V0tCIkXP6N Wuw4uhB1iiZVfAK89elqqxRViDOqPB/4szdYINBAHDQisNdn9M5lMvKG+NsIt27Coj8T zzZw9Pw9EuxhjWj0EozfxtgON1zWS8ekvkPHRDtWxVfyR3ZeiLc4MsuLCaD+5liduyn5 If4Q== 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=1DEIH5Jv/CWabnOp3GZ/IY4thuBSAYjd8Ue6uf+1xX0=; b=PHivDJa5slJr3dvK+coiq1EdhjGWHKqvFBl6LLL7FWxKnpRmu+PDRQCt64axMOyD/j 1WJlMYHUaUe6RJs5j0aQuZhDJfiPKiEOVCSEGgNutcvhZtegkklGdB6Jnz5R+ldZFRbj G1N7r3+im1bDG+DX1z3qZRBW58+OBAGde/zdet8CSJNMFMxfMdbjTMJsBUW/KrfpOtmm UsUqvFsZlzEXkgbXqohlex2MDz0eqDFlqAUg1OPXgwtE49SrZ7A5Oszcga16WSVBwrKK HeBxjJCDUuXbVHaPW27vwRZwhqwdGYwvo6Ol1aNJ64pf4sOKpgjrTAmMFF7NIpTner1g U9wQ== X-Gm-Message-State: APjAAAXHuw4o6NWVplRk0qLNK03PA4ieFu4PgiBhz1jt1zCel/IHoPiW JdebWfvDvH2OhwhuWoVCJMr2f2NQpd7vsKUTPdc= X-Google-Smtp-Source: APXvYqyb0/lDjpUkSoniKmD+L25oQr2S1dOFs8fovkHPQuJ8p7daxYJEo327MfqWt6Duubv4AT2BTXdwWMobyXMRt4o= X-Received: by 2002:aca:be88:: with SMTP id o130mr5879868oif.122.1562938852221; Fri, 12 Jul 2019 06:40:52 -0700 (PDT) MIME-Version: 1.0 References: <87muhks3b5.fsf@hochschule-trier.de> <83k1cn2z0l.fsf@gnu.org> In-Reply-To: <83k1cn2z0l.fsf@gnu.org> From: Pip Cet Date: Fri, 12 Jul 2019 13:40:15 +0000 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) 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, Jul 12, 2019 at 12:55 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Fri, 12 Jul 2019 12:44:35 +0000 > > Cc: 36609@debbugs.gnu.org > > > > Okay, I'm still not sure this is really the problem Andreas was > > seeing, but this code fails to work with xg_select: > > > > (let ((thread (make-thread (lambda () > > (sleep-for 3))))) > > (thread-yield) > > (thread-signal thread 'error nil)) > > What do you mean by "fails"? What do you see when you eval this? With `emacs -Q', a blinking cursor and an unresponsive emacs (no response to key presses, not even triple C-g). Sometimes, at least. Here's a full backtrace of a session where the hang did happen: Thread 4 (Thread 0x7fffeeb8a700 (LWP 26117)): #0 0x00007ffff4967819 in __GI___poll (fds=0xd93070, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 resultvar = 18446744073709551100 sc_cancel_oldtype = 0 #1 0x00007ffff698e136 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007ffff698e25c in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007fffeebd7ffd in () at /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so #4 0x00007ffff69b6415 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x00007ffff4b38fa3 in start_thread (arg=) at pthread_create.c:486 ret = pd = now = unwind_buf = { cancel_jmp_buf = {{ jmp_buf = {140737198466816, -2332898995959237690, 140737488337566, 140737488337567, 140737198466816, 13933232, 2332932536188793798, 2332875456844002246}, mask_was_saved = 0 }}, priv = { pad = {0x0, 0x0, 0x0, 0x0}, data = { prev = 0x0, cleanup = 0x0, canceltype = 0 } } } not_first_call = #6 0x00007ffff49724cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 3 (Thread 0x7fffef59e700 (LWP 26116)): #0 0x00007ffff4967819 in __GI___poll (fds=0xcb7a20, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 resultvar = 18446744073709551100 sc_cancel_oldtype = 0 #1 0x00007ffff698e136 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007ffff698e4c2 in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007ffff6bba0d6 in () at /lib/x86_64-linux-gnu/libgio-2.0.so.0 #4 0x00007ffff69b6415 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x00007ffff4b38fa3 in start_thread (arg=) at pthread_create.c:486 ret = pd = now = unwind_buf = { cancel_jmp_buf = {{ jmp_buf = {140737209034496, -2332898995959237690, 140737488336926, 140737488336927, 140737209034496, 13323152, 2332932821804118982, 2332875456844002246}, mask_was_saved = 0 }}, priv = { pad = {0x0, 0x0, 0x0, 0x0}, data = { prev = 0x0, cleanup = 0x0, canceltype = 0 } } } not_first_call = #6 0x00007ffff49724cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 2 (Thread 0x7ffff017d700 (LWP 26115)): #0 0x00007ffff4967819 in __GI___poll (fds=0xb400d0, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 resultvar = 18446744073709551100 sc_cancel_oldtype = 0 #1 0x00007ffff698e136 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007ffff698e25c in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007ffff698e2a1 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x00007ffff69b6415 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x00007ffff4b38fa3 in start_thread (arg=) at pthread_create.c:486 ret = pd = now = unwind_buf = { cancel_jmp_buf = {{ jmp_buf = {140737221482240, -2332898995959237690, 140737488347710, 140737488347711, 140737221482240, 0, 2332865253915489222, 2332875456844002246}, mask_was_saved = 0 }}, priv = { pad = {0x0, 0x0, 0x0, 0x0}, data = { prev = 0x0, cleanup = 0x0, canceltype = 0 } } } not_first_call = #6 0x00007ffff49724cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 0x7ffff0e30e00 (LWP 26108)): #0 0x00007ffff4b404c6 in pthread_sigmask (how=2, newmask=, oldmask=0x0) at ../sysdeps/unix/sysv/linux/pthread_sigmask.c:48 local_newmask = { __val = {7, 17697270867008781056, 11498208, 5790296, 0, 140737488342800, 2, 0, 0, 0, 0, 0, 0, 0, 0, 6922490} } result = 0 #1 0x0000000000585a7d in restore_signal_mask (oldset=0x7fffffffcf10) at sysdep.c:876 #2 0x0000000000699292 in really_call_select (arg=0x7fffffffd060) at thread.c:584 sa = 0x7fffffffd060 self = 0xa745c0 oldset = { __val = {0, 5710159, 8192, 126116988112, 140737488344608, 140737298839344, 7, 0, 11381952, 0, 8192, 1562936528, 140737488342720, 5968906924941129, 0, 16538645} } #3 0x00000000005e5ee0 in flush_stack_call_func (func=0x699239 , arg=0x7fffffffd060) at alloc.c:4969 end = 0x7fffffffd020 self = 0xa745c0 sentry = { o = { __max_align_ll = 0, __max_align_ld = } } #4 0x0000000000699389 in thread_select (func=0x419320 , max_fds=6, rfds=0x7fffffffd590, wfds=0x7fffffffd510, efds=0x0, timeout=0x7fffffffd840, sigmask=0x0) at thread.c:616 sa = { func = 0x419320 , max_fds = 6, rfds = 0x7fffffffd590, wfds = 0x7fffffffd510, efds = 0x0, timeout = 0x7fffffffd840, sigmask = 0x0, result = -157757095 } #5 0x00000000006bfeac in xg_select (fds_lim=6, rfds=0x7fffffffd8e0, wfds=0x7fffffffd860, efds=0x0, timeout=0x7fffffffd840, sigmask=0x0) at xgselect.c:117 all_rfds = { fds_bits = {32, 0 } } all_wfds = { fds_bits = {0 } } tmo = { tv_sec = 5621546, tv_nsec = 15785445 } tmop = 0x7fffffffd840 context = 0xc1c200 have_wfds = true gfds_buf = {{ fd = 895, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 8096, events = 65535, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 16, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 } , { fd = -2057698731, events = 39706, revents = 28662 }, { fd = 3, events = 0, revents = 0 }, { fd = -2057698731, events = 39706, revents = 28662 }, { fd = -161788823, events = 32767, revents = 0 }, { fd = -2057698731, events = 39642, revents = 28662 }, { fd = -190624704, events = 32767, revents = 0 }, { fd = 16, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = -664, events = 65535, revents = 65535 }, { fd = -504530176, events = 22038, revents = 62873 }, { fd = 12553216, events = 0, revents = 0 }, { fd = -1252392363, events = 44399, revents = 28662 }, { fd = 32, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 12553216, events = 0, revents = 0 }, { fd = -191458327, events = 32767, revents = 0 }, { fd = -190624704, events = 32767, revents = 0 }, { fd = 139264, events = 0, revents = 0 }, { fd = 17472, events = 0, revents = 0 }, { fd = -191893943, events = 32767, revents = 0 }, { fd = 128, events = 0, revents = 0 }, { fd = -191909562, events = 32767, revents = 0 }, { fd = 48, events = 0, revents = 0 }, { fd = 1, events = 0, revents = 0 }, { fd = 7, events = 0, revents = 0 }, { fd = 64, events = 0, revents = 0 }, { fd = 4, events = 32767, revents = 0 }, { fd = 11649056, events = 0, revents = 0 }, { fd = 47, events = 0, revents = 0 }, { fd = 96, events = 0, revents = 0 }, { fd = -664, events = 65535, revents = 65535 }, { fd = 1, events = 0, revents = 0 }, { fd = 4, events = 49, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 91, events = 110, revents = 0 }, { fd = 124, events = 119, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 17456, events = 0, revents = 0 }, { fd = -190624704, events = 32767, revents = 0 }, { fd = 48, events = 0, revents = 0 }, { fd = 2, events = 0, revents = 0 }, { fd = -664, events = 65535, revents = 65535 }, { fd = 0, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = -191900310, events = 32767, revents = 0 }, { fd = -664, events = 65535, revents = 65535 }, { fd = 0, events = 0, revents = 0 }, { fd = 48, events = 0, revents = 0 }, { fd = 187264016, events = 0, revents = 0 }, { fd = 11498208, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = -11392, events = 32767, revents = 0 }, { fd = 5621546, events = 0, revents = 0 }, { fd = 187264016, events = 0, revents = 0 }, { fd = -11360, events = 32767, revents = 0 }, { fd = 187280083, events = 0, revents = 0 }, { fd = -11344, events = 32767, revents = 0 }, { fd = 5622263, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 187280083, events = 0, revents = 0 }, { fd = -11280, events = 32767, revents = 0 }, { fd = 6170867, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 5627325, events = 0, revents = 0 }, { fd = 6, events = 0, revents = 0 }, { fd = 1, events = 0, revents = 0 }, { fd = 0, events = 1, revents = 0 }, { fd = 11498208, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = -11232, events = 32767, revents = 0 }, { fd = 5621546, events = 0, revents = 0 }, { fd = -134398935, events = 0, revents = 0 }, { fd = -11200, events = 32767, revents = 0 }, { fd = 187280099, events = 0, revents = 0 }, { fd = -11184, events = 32767, revents = 0 }, { fd = 5622263, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 187280099, events = 0, revents = 0 }, { fd = -11120, events = 32767, revents = 0 }, { fd = 6170867, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 5627325, events = 0, revents = 0 }, { fd = 6, events = 0, revents = 0 }, { fd = 1, events = 0, revents = 0 }, { fd = 0, events = 1, revents = 0 }, { fd = 11498208, events = 0, revents = 0 }, { fd = 187280099, events = 0, revents = 0 }, { fd = -11072, events = 32767, revents = 0 }, { fd = 5622263, events = 0, revents = 0 }, { fd = -11024, events = 32767, revents = 0 }, { fd = -134398935, events = 32767, revents = 0 }, { fd = -10944, events = 32767, revents = 0 }, { fd = 15785445, events = 0, revents = 0 }, { fd = -11016, events = 32767, revents = 0 }, { fd = 5623097, events = 0, revents = 0 }, { fd = 11498208, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = 0, events = 0, revents = 0 }, { fd = -10992, events = 32767, revents = 0 }} gfds = 0x7fffffffd100 gfds_size = 128 n_gfds = -1 retval = 0 our_fds = 0 max_fds = 5 context_acquired = false i = 0 nfds = 0 tmo_in_millisec = 0 must_free = 0 need_to_dispatch = false #6 0x000000000066b757 in wait_reading_process_output (time_limit=0, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at process.c:5423 process_skipped = false channel = 6 nfds = 1 Available = { fds_bits = {32, 0 } } Writeok = { fds_bits = {0 } } check_write = true check_delay = 0 no_avail = false xerrno = 11 proc = XIL(0xcf7c00) timeout = { tv_sec = 100000, tv_nsec = 0 } end_time = { tv_sec = 0, tv_nsec = 140737488345168 } timer_delay = { tv_sec = 0, tv_nsec = -1 } got_output_end_time = { tv_sec = 0, tv_nsec = -1 } wait = FOREVER got_some_output = -1 prev_wait_proc_nbytes_read = 0 retry_for_async = false count = 4 now = { tv_sec = 0, tv_nsec = -1 } #7 0x000000000056c31e in kbd_buffer_get_event (kbp=0x7fffffffdbd8, used_mouse_menu=0x7fffffffe1bf, end_time=0x0) at keyboard.c:3836 do_display = true obj = XIL(0x14bfd3fb) #8 0x0000000000568706 in read_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffdf80, used_mouse_menu=0x7fffffffe1bf) at keyboard.c:2138 c = XIL(0) save_jump = {{ __jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = { __val = {0 } } }} kb = 0x55c9f7 count = 3 #9 0x0000000000568970 in read_decoded_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffdf80, prev_event=XIL(0), used_mouse_menu=0x7fffffffe1bf) at keyboard.c:2202 nextevt = XIL(0x7fffffffde30) frame = 0x0 terminal = 0x0 events = {XIL(0x7fffffffddb0), make_fixnum(1422534), XIL(0xaf72e0), XIL(0), XIL(0), XIL(0x7fffffffddb0), make_fixnum(1405386), XIL(0x135b623), XIL(0x7fffffffddf0), make_fixnum(1420782), XIL(0xaf72e0), XIL(0x100000000), XIL(0), XIL(0x7fffffffddf0), make_fixnum(1405386), XIL(0)} n = 0 #10 0x000000000056a002 in read_char (commandflag=1, map=XIL(0xfbaa33), prev_event=XIL(0), used_mouse_menu=0x7fffffffe1bf, end_time=0x0) at keyboard.c:2810 c = XIL(0) jmpcount = 3 local_getcjmp = {{ __jmpbuf = {0, 2332898996579464134, 16538645, 48, 0, 0, 2332898994838827974, -2332899704998988858}, __mask_was_saved = 0, __saved_mask = { __val = {140737214405912, 0, 140737225904168, 11498208, 0, 0, 140737488347152, 5621546, 4032516088, 11498208, 0, 0, 140737488347200, 5621546, 12363987, 140737488347296} } }} save_jump = {{ __jmpbuf = {0, 0, 140737224472304, 0, 0, 11529984, 5621546, 0}, __mask_was_saved = -8336, __saved_mask = { __val = {6254137, 140737231486936, 12884893472, 0, 31776, 140737224472304, 140737231486936, 5623453, 51539607552, 140737224472309, 140737224472304, 5632971, 11529984, 11529984, 0, 11498208} } }} tem = XIL(0x7fffefa759f0) save = XIL(0) previous_echo_area_message = XIL(0) also_record = XIL(0) reread = false recorded = false polling_stopped_here = true orig_kboard = 0xc863c0 #11 0x0000000000576842 in read_key_sequence (keybuf=0x7fffffffe3a0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9124 interrupted_kboard = 0xc863c0 interrupted_frame = 0xf976a0 key = XIL(0xf97ac0) used_mouse_menu = false echo_local_start = 0 last_real_key_start = 0 keys_local_start = 0 new_binding = XIL(0xf97ac0) count = 3 t = 0 echo_start = 0 keys_start = 0 current_binding = XIL(0xfbaa33) first_unbound = 31 mock_input = 0 used_mouse_menu_history = {false } fkey = { parent = XIL(0xbe3cd3), map = XIL(0xbe3cd3), start = 0, end = 0 } keytran = { parent = XIL(0x7ffff0ae0eeb), map = XIL(0x7ffff0ae0eeb), start = 0, end = 0 } indec = { parent = XIL(0xbe3cc3), map = XIL(0xbe3cc3), start = 0, end = 0 } shift_translated = false delayed_switch_frame = XIL(0) original_uppercase = XIL(0) original_uppercase_position = -1 dummyflag = false starting_buffer = 0x7ffff04576f0 fake_prefixed_keys = XIL(0) first_event = XIL(0) second_event = XIL(0) #12 0x00000000005667ae in command_loop_1 () at keyboard.c:1348 cmd = XIL(0x7fffffffe4f0) keybuf = {XIL(0x7fffffffe420), XIL(0x7ffff0b08008), XIL(0x100000007), XIL(0), XIL(0), XIL(0x80a0), XIL(0x11f), XIL(0xaff380), XIL(0xaff380), XIL(0), XIL(0x7fffffffe440), XIL(0x617021), make_fixnum(1073741824), XIL(0x7fffffffe460), XIL(0xaf72e0), XIL(0), XIL(0), XIL(0x7fffffffe440), make_fixnum(1405386), XIL(0xf04576f5), XIL(0x7fffffffe4a0), XIL(0x61729f), XIL(0xaf72e0), XIL(0), XIL(0), XIL(0x7fffffffe480), make_fixnum(1405386), XIL(0xf04576f5), XIL(0x7fffffffe4c0), make_fixnum(1591385)} i = 0 prev_modiff = 0 prev_buffer = 0x0 already_adjusted = false #13 0x0000000000611d61 in internal_condition_case (bfun=0x566384 , handlers=XIL(0x90), hfun=0x565b7d ) at eval.c:1351 val = make_fixnum(1405386) c = 0xb99e70 #14 0x000000000056607a in command_loop_2 (ignore=XIL(0)) at keyboard.c:1091 val = XIL(0) #15 0x000000000061161a in internal_catch (tag=XIL(0xd140), func=0x566051 , arg=XIL(0)) at eval.c:1112 val = XIL(0x7fffffffe5c0) c = 0xb94fd0 #16 0x000000000056601c in command_loop () at keyboard.c:1070 #17 0x0000000000565752 in recursive_edit_1 () at keyboard.c:714 count = 1 val = XIL(0x7fffffffe620) #18 0x00000000005658d4 in Frecursive_edit () at keyboard.c:786 count = 0 buffer = XIL(0) #19 0x0000000000563961 in main (argc=4, argv=0x7fffffffe878) at emacs.c:2086 stack_bottom_variable = 0x5e00 do_initial_setlocale = true no_loadup = false junk = 0x0 dname_arg = 0x0 ch_to_dir = 0x0 original_pwd = 0x0 dump_mode = 0x0 skip_args = 0 temacs = 0x0 attempt_load_pdump = true rlim = { rlim_cur = 10022912, rlim_max = 18446744073709551615 } sockfd = -1 i thr Id Target Id Frame * 1 Thread 0x7ffff0e30e00 (LWP 26108) "emacs" pthread_sigmask (how=0, newmask=, oldmask=0x7fffffffcf10) at ../sysdeps/unix/sysv/linux/pthread_sigmask.c:48 2 Thread 0x7ffff017d700 (LWP 26115) "gmain" 0x00007ffff4967819 in __GI___poll (fds=0xb400d0, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 3 Thread 0x7fffef59e700 (LWP 26116) "gdbus" 0x00007ffff4967819 in __GI___poll (fds=0xcb7a20, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 4 Thread 0x7fffeeb8a700 (LWP 26117) "dconf worker" 0x00007ffff4967819 in __GI___poll (fds=0xd93070, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 > > Proposed patch attached. > > As I said earlier, I don't think it's right to use stack unwinding at > this level. (Did you try this in a -nw session?) Sorry, I didn't see that email until after I'd sent mine. I did try with an -nw session, now, but I really think thread_select should not return abnormally. > I'd appreciate a description of what you think happens here, and why. When a thread is signalled (by thread-signal, which sets another thread's error_symbol) while the signalled thread is inside a select(), thread_select() will return non-locally for that thread, and we fail to release an internal GLib lock through g_main_context_release(). That's the first bug. When xg_select() fails to acquire the internal GLib lock, it simply does a select() on the remaining file descriptors: context_acquired = g_main_context_acquire (context); /* FIXME: If we couldn't acquire the context, we just silently proceed because this function handles more than just glib file descriptors. Note that, as implemented, this failure is completely silent: there is no feedback to the caller. */ This seems like a second, albeit documented, bug to me. I think we're risking not waking up from the actual select because another (non-Emacs) thread happened to hold the main context at the time. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 13:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156293950425565 (code B ref 36609); Fri, 12 Jul 2019 13:52:01 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 13:51:44 +0000 Received: from localhost ([127.0.0.1]:39401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlvxg-0006eG-A2 for submit@debbugs.gnu.org; Fri, 12 Jul 2019 09:51:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48365) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlvxd-0006e2-TO for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 09:51:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40633) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hlvxY-0000L2-3u; Fri, 12 Jul 2019 09:51:36 -0400 Received: from [176.228.60.248] (port=1816 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hlvxW-00039q-Jh; Fri, 12 Jul 2019 09:51:35 -0400 Date: Fri, 12 Jul 2019 16:51:22 +0300 Message-Id: <83ftnb2wf9.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Pip Cet on Fri, 12 Jul 2019 13:40:15 +0000) References: <87muhks3b5.fsf@hochschule-trier.de> <83k1cn2z0l.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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: Pip Cet > Date: Fri, 12 Jul 2019 13:40:15 +0000 > Cc: politza@hochschule-trier.de, 36609@debbugs.gnu.org > > When a thread is signalled (by thread-signal, which sets another > thread's error_symbol) while the signalled thread is inside a > select(), thread_select() will return non-locally for that thread, and > we fail to release an internal GLib lock through > g_main_context_release(). That's the first bug. We should either release the global lock before the thread exits, or defer the acting upon the signal until later. We cannot disable the signal handling altogether because it is entirely legitimate to signal another thread, and when we do, that other thread will _always_ be inside thread_select. For the main thread, handling the signal in that situation shouldn't be a problem, because it is not going to exit. Right? > When xg_select() fails to acquire the internal GLib lock, it simply > does a select() on the remaining file descriptors: Why does it fail to acquire that lock? > context_acquired = g_main_context_acquire (context); > /* FIXME: If we couldn't acquire the context, we just silently proceed > because this function handles more than just glib file descriptors. > Note that, as implemented, this failure is completely silent: there is > no feedback to the caller. */ > > This seems like a second, albeit documented, bug to me. I think we're > risking not waking up from the actual select because another > (non-Emacs) thread happened to hold the main context at the time. So what is the proposal for that? spin waiting for the lock? From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 13:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156293955525652 (code B ref 36609); Fri, 12 Jul 2019 13:53:02 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 13:52:35 +0000 Received: from localhost ([127.0.0.1]:39405 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlvyT-0006fe-Mb for submit@debbugs.gnu.org; Fri, 12 Jul 2019 09:52:35 -0400 Received: from mail-oi1-f196.google.com ([209.85.167.196]:38957) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlvyS-0006fQ-57 for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 09:52:32 -0400 Received: by mail-oi1-f196.google.com with SMTP id m202so7328631oig.6 for <36609@debbugs.gnu.org>; Fri, 12 Jul 2019 06:52:32 -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=+280ro4FM7jUHwvU0erIjWzKO9MvMNZqoANXyWNHPXk=; b=HZMoOSBCHBFKu3feliCfIkvO++VQYl8jdYWOBtLf0+160YZoC8LdvF/FyWTmXsvMd9 txHdOBoguJZ3X8Qa0jr3PYDh/3JWz/MKDS/WxAKitOmfkoSj93mF/bjkbHwMecjTaJGG /ZvDI3D40U5TX8soNBmo5P5vy8niN1VXpQroVP9pFYcOAGWwfK1XAYuPh7oHVtZOwT3U 4XY6WtKKiUEPIJgyyrAMY6QyQoNp8O9Lcn2RuLI5eNXK35eh2qVyPXdhVr19P2KFCCP7 BgZd/53UVjbXuHbXaHrmCr5yHaAfjVsqTk+scxMNbzs+EDdBoXP7UGoj9IxC86nSctTP fDuA== 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=+280ro4FM7jUHwvU0erIjWzKO9MvMNZqoANXyWNHPXk=; b=qABLtIQnJpnyaHSlWx5lxhjZJsNQd8duCDFkrmK2OwkOMe53tiVPAcIo5fN59c3+MR xPQaZm0/g4yPpsqWr03p1Oalo8n1ZjEeiqzUTVnnGFaE7MCOkNEfCYVpf5rsuJL7/B5z 3DIn4e2hXvPc6EW1fSKQ8CgOU0TmmUxbWv4xddz7n/QpvBlzM/DVNtlTVhDNXsPvzaj+ ltOzBITePafdgvBXPDKl7D5EdFHBZsa0UFPU61jRo5jqbrqfG1Hx5jAjT6TuJgYfrIki agkKsxc+FnFeiHjrBtXY/6uHqZX1Io+MWb8Cz5ljFtYiLCVq8n+iXQVB5kOXoNEbI81n L4hQ== X-Gm-Message-State: APjAAAXaiD1NSWrEq1EPk6TCgFKhIA45p7waX3C9WJNA+Tv/kWKRfC2+ yvN3flOJZ3chYtjhtDo7qNi/0KHuSfszxZ4gdg8= X-Google-Smtp-Source: APXvYqzNFo401ElS2IwIAxrf5Col7vm3Y5X3DbHaTl3yqRv12njrxKXJ+YtIVPVcegggxGBvlc+6UdRntg4v9laKTVQ= X-Received: by 2002:aca:4790:: with SMTP id u138mr6269678oia.44.1562939545202; Fri, 12 Jul 2019 06:52:25 -0700 (PDT) MIME-Version: 1.0 References: <87muhks3b5.fsf@hochschule-trier.de> <83muhj2zmb.fsf@gnu.org> <83ims72xcj.fsf@gnu.org> In-Reply-To: <83ims72xcj.fsf@gnu.org> From: Pip Cet Date: Fri, 12 Jul 2019 13:51:48 +0000 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) 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, Jul 12, 2019 at 1:31 PM Eli Zaretskii wrote:> > > From: Pip Cet > > Date: Fri, 12 Jul 2019 12:57:51 +0000 > > Cc: politza@hochschule-trier.de, 36609@debbugs.gnu.org > > > > Lisp Backtrace: > > "sleep-for" (0xedf7a530) > > 0xf6da40 Lisp type 3 > > > > post_acquire_global_lock () can return abnormally (I didn't know > > that), so really_call_select() can, too, so thread_select() can, too. > > Do you know which code sets current_thread->error_symbol, and what is > that error symbol? thread-signal, which my example code calls directly. I passed 'error, and that's what error_symbol is set to. last_thread_error is (error) when the Emacs session freezes. > > > > + ptrdiff_t count = SPECPDL_INDEX (); > > > > > > I don't think we should do that at this low level. > > > > You're right, it does stick out. I think we're safe because we're > > calling Fsignal with the global lock held, but it's not a pretty or > > well-documented situation. > > Is this the main thread which does that? if so, there should be no > problem with holding the global lock in this case, is there? > > If this is not the main thread, then the error handlers should be set > so as to log the error in last_thread_error, and then terminate the > thread (via exiting the thread function, AFAIR). Indeed, that's what happens; but the thread now fails to release the GLib lock it had previously acquired, so other threads cannot acquire it again, ever. > If this is not what happens, I'd like to know what does happen here, > and why. Sure, we should understand what's going on here; even if the fix turns out to be simple. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 14:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156294213030621 (code B ref 36609); Fri, 12 Jul 2019 14:36:01 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 14:35:30 +0000 Received: from localhost ([127.0.0.1]:40476 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlwe1-0007xn-V9 for submit@debbugs.gnu.org; Fri, 12 Jul 2019 10:35:30 -0400 Received: from mail-ot1-f51.google.com ([209.85.210.51]:42309) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlwdz-0007xY-8a for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 10:35:27 -0400 Received: by mail-ot1-f51.google.com with SMTP id l15so9647102otn.9 for <36609@debbugs.gnu.org>; Fri, 12 Jul 2019 07:35:27 -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=vC7KUbM0gjp7ohOiPN9gTjhRmBe1pLu3XUX6aTs6Jk0=; b=sYd+FSiSxpGkd1XTXtMU9tHu7aDTxxu0DMacHkFy9iwgZ1PhPVWLp+VXXbmMrP67V6 61IqhaaJy6TueVypLFjHPLG511bfZfv767xhtNDQnLhJJ3hkxn+jdgWvuQUjMo9GkQlw pR7+3PdcVd7Cfg7+xb4lHyJwXSiXywdHqUXY5Xpx5frhcNmCZ9vl/WS2qE2eMJpkOTXs GwdwSb4mEVlQR0MvZXEiPV9PGTk3b15zDEaMpMNDz3BRt4HetSFgjinjUbPhZyWBVZF+ eduKhEvHuQn9sL2Wb6HvzIiVhPsXkBBbQZW2VA6JOzXDkMQWDyngbeSqOANv8KthbNLD PsrQ== 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=vC7KUbM0gjp7ohOiPN9gTjhRmBe1pLu3XUX6aTs6Jk0=; b=qtgZf7jXtcQkLd7vzRLoQQXT10HlbJxpTy5Cw8flt+CEFsMy05CyWQ/Zr0J7FTgYmM h0Mc2jVlWuagV4StLgkBzYNELNI6Hnins4G4J8GVoX+PJBf0+H/cnazf7gK7bpXl9eRf 3q75CXoduWRNVGO6u8Mzhx5zgMxqF+v8FmvDlsaZurabx6gBb019kzlYs9ptrVv8LgVt cSAu0bRhcOyCGp/2BotRkpcG0/EbObbWgQ9+n/dCxC9s0Awf86j1a9cezfzRW1sW7ev+ CQhhVfQaZGLrrWCbg6uR5mRHiQ+4qOm9uGZJedJKl/MuQUjl5sT+qpEj0VCXbhJH9ZuV xOKg== X-Gm-Message-State: APjAAAVbSBroq6kWnibk0LtChUhWu46VqgJgxEZ2TWJRxWNRG8E1tRn7 z7+iPw7e/WfbIHouZx+RPyJmlfhOKfQ/Yn16oxg= X-Google-Smtp-Source: APXvYqz5eWJAnNIRDo2YIJ9TiyvcSPcc5p7O29jvgRROYt9Yv+gu4mYvkGr+nu/0YW30mTdF8LVitiuDPeS2VLsHPZs= X-Received: by 2002:a9d:6014:: with SMTP id h20mr8770549otj.210.1562942121623; Fri, 12 Jul 2019 07:35:21 -0700 (PDT) MIME-Version: 1.0 References: <87muhks3b5.fsf@hochschule-trier.de> <83k1cn2z0l.fsf@gnu.org> <83ftnb2wf9.fsf@gnu.org> In-Reply-To: <83ftnb2wf9.fsf@gnu.org> From: Pip Cet Date: Fri, 12 Jul 2019 14:34:44 +0000 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) 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, Jul 12, 2019 at 1:51 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Fri, 12 Jul 2019 13:40:15 +0000 > > Cc: politza@hochschule-trier.de, 36609@debbugs.gnu.org > > > > When a thread is signalled (by thread-signal, which sets another > > thread's error_symbol) while the signalled thread is inside a > > select(), thread_select() will return non-locally for that thread, and > > we fail to release an internal GLib lock through > > g_main_context_release(). That's the first bug. > > We should either release the global lock before the thread exits, or > defer the acting upon the signal until later. We cannot disable the > signal handling altogether because it is entirely legitimate to signal > another thread, and when we do, that other thread will _always_ be > inside thread_select. Really? What about thread-yield? > For the main thread, handling the signal in that situation shouldn't > be a problem, because it is not going to exit. Right? I think the main thread can still fail to release the lock... > > When xg_select() fails to acquire the internal GLib lock, it simply > > does a select() on the remaining file descriptors: > > Why does it fail to acquire that lock? Because another thread holds it, either an Emacs or a non-Emacs thread. In both cases, I think we might miss events unless we return with errno == EINTR. > > context_acquired = g_main_context_acquire (context) > > /* FIXME: If we couldn't acquire the context, we just silently proceed > > because this function handles more than just glib file descriptors. > > Note that, as implemented, this failure is completely silent: there is > > no feedback to the caller. */ > > > > This seems like a second, albeit documented, bug to me. I think we're > > risking not waking up from the actual select because another > > (non-Emacs) thread happened to hold the main context at the time. > > So what is the proposal for that? spin waiting for the lock? I don't know, to be honest, but I'm afraid there's currently no better way. There's a way to take the lock without spinning, but it's been deprecated. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 15:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.15629437979406 (code B ref 36609); Fri, 12 Jul 2019 15:04:01 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 15:03:17 +0000 Received: from localhost ([127.0.0.1]:40539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlx4v-0002Re-3I for submit@debbugs.gnu.org; Fri, 12 Jul 2019 11:03:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41566) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlx4t-0002RR-3I for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 11:03:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41860) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hlx4m-00028U-9z; Fri, 12 Jul 2019 11:03:09 -0400 Received: from [176.228.60.248] (port=2185 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hlx4k-00051e-1v; Fri, 12 Jul 2019 11:03:07 -0400 Date: Fri, 12 Jul 2019 18:02:52 +0300 Message-Id: <83blxz2t43.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Pip Cet on Fri, 12 Jul 2019 14:34:44 +0000) References: <87muhks3b5.fsf@hochschule-trier.de> <83k1cn2z0l.fsf@gnu.org> <83ftnb2wf9.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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: Pip Cet > Date: Fri, 12 Jul 2019 14:34:44 +0000 > Cc: politza@hochschule-trier.de, 36609@debbugs.gnu.org > > > > When a thread is signalled (by thread-signal, which sets another > > > thread's error_symbol) while the signalled thread is inside a > > > select(), thread_select() will return non-locally for that thread, and > > > we fail to release an internal GLib lock through > > > g_main_context_release(). That's the first bug. > > > > We should either release the global lock before the thread exits, or > > defer the acting upon the signal until later. We cannot disable the > > signal handling altogether because it is entirely legitimate to signal > > another thread, and when we do, that other thread will _always_ be > > inside thread_select. > > Really? What about thread-yield? What about it? You are asking whether, when thread-signal is executed, the thread which we are signaling is necessarily parked inside thread_select? If so, I don't understand your surprise: only one thread can ever be running, and that is by definition the thread which calls thread-signal. All the other threads cannot be running, which means they are parked either in thread_select or in sys_mutex_lock called from acquire_global_lock. Right? As for thread-yield, I'm not sure I understand how is it related to the issue we are discussing. > > For the main thread, handling the signal in that situation shouldn't > > be a problem, because it is not going to exit. Right? > > I think the main thread can still fail to release the lock... Since the main thread doesn't exit, but just longjmp's to top-level, and then continues to run, why does it need to release the lock? Any thread should hold the lock for as long as it runs. > > > When xg_select() fails to acquire the internal GLib lock, it simply > > > does a select() on the remaining file descriptors: > > > > Why does it fail to acquire that lock? > > Because another thread holds it, either an Emacs or a non-Emacs > thread. OK, and why is it a problem that we continue calling thread_select regardless of the failure to acquire the Glib lock? is the problem this one: > In both cases, I think we might miss events unless we return > with errno == EINTR. ? Or is there something else? If the problem with missing events, then which events are those, and what bad things will happen if we miss them? From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 15:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.15629439839688 (code B ref 36609); Fri, 12 Jul 2019 15:07:01 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 15:06:23 +0000 Received: from localhost ([127.0.0.1]:40543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlx7u-0002WB-Me for submit@debbugs.gnu.org; Fri, 12 Jul 2019 11:06:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42581) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlx7q-0002Vv-Me for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 11:06:19 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41909) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hlx7k-0005GH-V7; Fri, 12 Jul 2019 11:06:13 -0400 Received: from [176.228.60.248] (port=2360 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hlx7c-00013C-OH; Fri, 12 Jul 2019 11:06:12 -0400 Date: Fri, 12 Jul 2019 18:05:46 +0300 Message-Id: <83a7dj2sz9.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Pip Cet on Fri, 12 Jul 2019 13:51:48 +0000) References: <87muhks3b5.fsf@hochschule-trier.de> <83muhj2zmb.fsf@gnu.org> <83ims72xcj.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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: Pip Cet > Date: Fri, 12 Jul 2019 13:51:48 +0000 > Cc: politza@hochschule-trier.de, 36609@debbugs.gnu.org > > > If this is not the main thread, then the error handlers should be set > > so as to log the error in last_thread_error, and then terminate the > > thread (via exiting the thread function, AFAIR). > > Indeed, that's what happens; but the thread now fails to release the > GLib lock it had previously acquired, so other threads cannot acquire > it again, ever. Then we should make sure we release it when the thread function exits, or before we call Fsignal from post_acquire_global_lock. There's no reason to use the unwind-protect machinery for that, I think. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 18:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.15629548333107 (code B ref 36609); Fri, 12 Jul 2019 18:08:02 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 18:07:13 +0000 Received: from localhost ([127.0.0.1]:40696 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlzwu-0000o3-O2 for submit@debbugs.gnu.org; Fri, 12 Jul 2019 14:07:13 -0400 Received: from mail-oi1-f170.google.com ([209.85.167.170]:40788) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlzwt-0000nq-3F for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 14:07:11 -0400 Received: by mail-oi1-f170.google.com with SMTP id w196so7929407oie.7 for <36609@debbugs.gnu.org>; Fri, 12 Jul 2019 11:07:11 -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=CyLNFAqAoxb1aTAgiX1cAXGzhY8r2d5LcZWi5qjkh+s=; b=sbF8YYlKFfZz/tg5YR+wsEytD0oZ8KiS5KMVAeEHqnjvFshQqGW3ctqBS4Ndycqvhj o0v4Z1CcT2lWHPysIDoghDXzANsnhBhnFEgah0Ar88CKBFihlgdkh02A5XJLoybpuCvV OBB9QV+c4meFRr0R52kvMMvr+6mfyN7D0QtyXEmryldVNIV40T4MzSMYMnHd71PkrSnj t1wQxWWfPnYruEmef+bfJ/dAkO1yloCydoWLOsgzPhQ8GpAPSRjBNc/muH+GMzyYHhVB ql1lQZPKQULg/MJpkY53jtpL8BN1/3oidGIpEo/gMwfAfXtqBRbdkobqrybfKZGXjM/L LxNA== 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=CyLNFAqAoxb1aTAgiX1cAXGzhY8r2d5LcZWi5qjkh+s=; b=CA7Sz5BkeOqBiSkgIvuGJEYkioOjTwDaNs/ePCPttTk+lT0N1zbVJZrPxsLFPbUgob hS8a3lot8/HEHklwBoNJDKAI5M4ffHkZ93JPM3ggMlEze3c8P4nOS0e9RDeklIgIe0h3 W4hAfjhxdA1RjWp1PgWy2aNUBxQmTLyjH6a0t9wTOdXn575IRPC+GTNLLWciFdcam7Xc R75VxdKJMUe6Yv4MfKfJRy/QjPBUszPPokOTMIF1MZsfKMMK+IrofYE8UH7FeRlH6AKa iNMmFPPZ/e7+N5kOh8nYk14V6BuzfFdKrhf5lTLIGIZ6JsAbQsCno8u89cN8RJXLk2YZ qXEg== X-Gm-Message-State: APjAAAXWTlMGq/dsQ/TvC0eb9eOGUuyM0qibYgHyGqwoCb8KJ4RhZ5rC LwjYCZSQBjgxWGaUs80EEArWcGC7FY+VO7tmTX0= X-Google-Smtp-Source: APXvYqxpXc0/p1OGiMyvamy9yslWe9+H4tlXbL7WdxGG6j9gu9dYflmXjk6oCiskysSaJ9QFlJSb/HAUlD/xZv7/bs0= X-Received: by 2002:aca:2303:: with SMTP id e3mr6035516oie.112.1562954825474; Fri, 12 Jul 2019 11:07:05 -0700 (PDT) MIME-Version: 1.0 References: <87muhks3b5.fsf@hochschule-trier.de> <83muhj2zmb.fsf@gnu.org> <83ims72xcj.fsf@gnu.org> <83a7dj2sz9.fsf@gnu.org> In-Reply-To: <83a7dj2sz9.fsf@gnu.org> From: Pip Cet Date: Fri, 12 Jul 2019 18:06:29 +0000 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) 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, Jul 12, 2019 at 3:06 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Fri, 12 Jul 2019 13:51:48 +0000 > > Cc: politza@hochschule-trier.de, 36609@debbugs.gnu.org > > > > > If this is not the main thread, then the error handlers should be set > > > so as to log the error in last_thread_error, and then terminate the > > > thread (via exiting the thread function, AFAIR). > > > > Indeed, that's what happens; but the thread now fails to release the > > GLib lock it had previously acquired, so other threads cannot acquire > > it again, ever. > > Then we should make sure we release it when the thread function exits, That's too late, it's legitimate for the thread to have a signal handler. We need to release the lock at precisely the time that unbind_to would release it. > or before we call Fsignal from post_acquire_global_lock. There's no > reason to use the unwind-protect machinery for that, I think. If we call Fsignal, surely the unwind-protect machinery is already set up and we can safely call it? So unbind_to would work again... I guess I've changed my mind: the unwind-protect machinery does precisely what we want, we should simply document that thread_select can exit nonlocally and that the select functions need to be written to cater to that. Two places call xg_select, and they both run long after unbind_to works. Doing this without the unwind-protect machinery is difficult: for example, a comment in post_acquire_global_lock claims unbind_for_thread_switch can exit nonlocally, though I don't think that actually happens or we would have seen the bug report. What's your proposal for doing this? From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 18:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.15629560785070 (code B ref 36609); Fri, 12 Jul 2019 18:28:01 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 18:27:58 +0000 Received: from localhost ([127.0.0.1]:40715 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hm0H0-0001Jh-2E for submit@debbugs.gnu.org; Fri, 12 Jul 2019 14:27:58 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43414) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hm0Gy-0001JU-MA for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 14:27:57 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45519) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hm0Gr-0006gE-SC; Fri, 12 Jul 2019 14:27:50 -0400 Received: from [176.228.60.248] (port=2709 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hm0Gq-0001EM-Bz; Fri, 12 Jul 2019 14:27:49 -0400 Date: Fri, 12 Jul 2019 21:27:40 +0300 Message-Id: <835zo72jmr.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Pip Cet on Fri, 12 Jul 2019 18:06:29 +0000) References: <87muhks3b5.fsf@hochschule-trier.de> <83muhj2zmb.fsf@gnu.org> <83ims72xcj.fsf@gnu.org> <83a7dj2sz9.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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: Pip Cet > Date: Fri, 12 Jul 2019 18:06:29 +0000 > Cc: politza@hochschule-trier.de, 36609@debbugs.gnu.org > > > Then we should make sure we release it when the thread function exits, > > That's too late, it's legitimate for the thread to have a signal > handler. We need to release the lock at precisely the time that > unbind_to would release it. I had also another proposal: > > or before we call Fsignal from post_acquire_global_lock. There's no > > reason to use the unwind-protect machinery for that, I think. > > If we call Fsignal, surely the unwind-protect machinery is already set > up and we can safely call it? So unbind_to would work again... Sorry, I don't want to call unwind-protect there. Call me paranoid, if you want. > I guess I've changed my mind: the unwind-protect machinery does > precisely what we want, we should simply document that thread_select > can exit nonlocally and that the select functions need to be written > to cater to that. > > Two places call xg_select, and they both run long after unbind_to works. > > Doing this without the unwind-protect machinery is difficult: for > example, a comment in post_acquire_global_lock claims > unbind_for_thread_switch can exit nonlocally, though I don't think > that actually happens or we would have seen the bug report. > > What's your proposal for doing this? Like I said: release the lock before calling Fsignal. We could do that before calling unbind_for_thread_switch, if needed. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 18:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: pipcet@gmail.com Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.15629564875768 (code B ref 36609); Fri, 12 Jul 2019 18:35:02 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 18:34:47 +0000 Received: from localhost ([127.0.0.1]:40720 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hm0Na-0001Uy-So for submit@debbugs.gnu.org; Fri, 12 Jul 2019 14:34:47 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45388) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hm0NY-0001Ul-QU for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 14:34:45 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45672) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hm0NR-0002SW-Ez; Fri, 12 Jul 2019 14:34:37 -0400 Received: from [176.228.60.248] (port=3121 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hm0NQ-000894-Rn; Fri, 12 Jul 2019 14:34:37 -0400 Date: Fri, 12 Jul 2019 21:34:29 +0300 Message-Id: <834l3r2jbe.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <835zo72jmr.fsf@gnu.org> (message from Eli Zaretskii on Fri, 12 Jul 2019 21:27:40 +0300) References: <87muhks3b5.fsf@hochschule-trier.de> <83muhj2zmb.fsf@gnu.org> <83ims72xcj.fsf@gnu.org> <83a7dj2sz9.fsf@gnu.org> <835zo72jmr.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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 (---) > Date: Fri, 12 Jul 2019 21:27:40 +0300 > From: Eli Zaretskii > Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de > > Sorry, I don't want to call unwind-protect there. Call me paranoid, > if you want. Maybe I should explain the rationale behind that paranoia. The main reason is that you are proposing to do that inside code that can switch threads. Switching threads means switching to another stack and also to another set of handlers. So using the unwind-protect machinery in this situation is IMO asking for trouble. And then there's the TTY frame case, where C-g triggers SIGINT, and we actually longjmp from wherever we were... From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 19:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156295952210656 (code B ref 36609); Fri, 12 Jul 2019 19:26:01 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 19:25:22 +0000 Received: from localhost ([127.0.0.1]:40744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hm1AY-0002lo-70 for submit@debbugs.gnu.org; Fri, 12 Jul 2019 15:25:22 -0400 Received: from mail-ot1-f67.google.com ([209.85.210.67]:45180) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hm1AW-0002la-VO for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 15:25:21 -0400 Received: by mail-ot1-f67.google.com with SMTP id x21so10513434otq.12 for <36609@debbugs.gnu.org>; Fri, 12 Jul 2019 12:25:20 -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=AhgdYj1G21HGZTdqmJ0skkYYtWUuBTkRPrbWx5ljj24=; b=kwQ9ZOhdaedfKh5ad/jwr3I88OhPo2JYEVlU1NuXyPE2DizAWW1a3EwA1ZVhOUEeqN BNa5yGpWDpnqkUgyuovLzie4Sfcohh6iueVy/VZLdNWpEWuq9wl5X/QfRLPD4c8XenJ9 Myvt01zz4Mntn59afBm9rqQ9IETqssXlGV3Bz3GcRsog0ysx+HmOOFhLBsBhdbC2cIL9 LcXtE21R+xYTq4YlmTYQdeRPfMX79LflXlv2WbhbZZlt+TSkSyWp4jRIqcMU1OhJCU3Y 7i0wR8zLJfvTkDYQvYBo8c5SvsUPd6atm6wobH3dMTc0svwLKIDV8GJzZVuXdR1GZskw 1pMw== 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=AhgdYj1G21HGZTdqmJ0skkYYtWUuBTkRPrbWx5ljj24=; b=GSJj3ClooJh+NbZRvMzJhXtp7s65nsiPgBzBVmGbj7TKhqb19n32O8Vct1hxM+MWdI vuaCjtxz1cF1G15MFHs+lhIld8E1t6T4FgjtXWbUyD8nIwcyLfU0rwNsf9xcDYL3oK8S rEDeCuLyU+WPKXFuUdib/2BhRoXuSE3jtvEvfjQT/MBeO2JP5HEV3kov/72RBbt/8ETQ dovnaqcB4KzGUGnwbN1xb/ljJA9Ef8bOLjsoi/m5kZZa6ozflZlgmDqxTFDrZPmZGcfj TIGKQBu3Z+GpD9E52yFbiMBoQClKJu46Z5TOv1tGeW1CNjOZyRMVoFBnPUGBhGymB7gC IpwA== X-Gm-Message-State: APjAAAV1sP0FnUXBvto+v2qaOt8N+DFnKC7fEJxBAO1ErBrs36llSSkl ik/zo80x74uFeyiLyaRqtj5wHBt/mntD1G65lRg= X-Google-Smtp-Source: APXvYqy9fvljvgoUzipQQGdHbNPPy5nViIzkyzip2oW94L/G0xO57sxVkgQFwwylU3uwwAdGI6BT2alBbFm3Zo+EEDw= X-Received: by 2002:a9d:664c:: with SMTP id q12mr5274838otm.175.1562959515182; Fri, 12 Jul 2019 12:25:15 -0700 (PDT) MIME-Version: 1.0 References: <87muhks3b5.fsf@hochschule-trier.de> <83muhj2zmb.fsf@gnu.org> <83ims72xcj.fsf@gnu.org> <83a7dj2sz9.fsf@gnu.org> <835zo72jmr.fsf@gnu.org> <834l3r2jbe.fsf@gnu.org> In-Reply-To: <834l3r2jbe.fsf@gnu.org> From: Pip Cet Date: Fri, 12 Jul 2019 19:24:38 +0000 Message-ID: Content-Type: multipart/mixed; boundary="000000000000b3a7a4058d80de4f" X-Spam-Score: 0.0 (/) 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 (-) --000000000000b3a7a4058d80de4f Content-Type: text/plain; charset="UTF-8" On Fri, Jul 12, 2019 at 6:34 PM Eli Zaretskii wrote: > > Sorry, I don't want to call unwind-protect there. Call me paranoid, > > if you want. > > Maybe I should explain the rationale behind that paranoia. The main I don't think it's paranoia, I just wasn't sure there was a good way to avoid it. I'm now convinced that there simply is no safe way to call select() from two threads at once when using glib. I think our options are hacking around it and hoping nothing breaks (this is what the attached patch does; it releases the main context glib lock from the wrong thread soon "after" the other thread called select, but there's actually no way to ensure that "after" is accurate), or rewriting things so we have a single thread that does all the select()ing. > reason is that you are proposing to do that inside code that can > switch threads. Switching threads means switching to another stack > and also to another set of handlers. So using the unwind-protect > machinery in this situation is IMO asking for trouble. Thanks for explaining. --000000000000b3a7a4058d80de4f Content-Type: application/x-patch; name="glib-hack.diff" Content-Disposition: attachment; filename="glib-hack.diff" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jy0gqn390 ZGlmZiAtLWdpdCBhL3NyYy90aHJlYWQuYyBiL3NyYy90aHJlYWQuYwppbmRleCBlMmRlYWRkN2E4 Li5iMWFkNWU4OTQ2IDEwMDY0NAotLS0gYS9zcmMvdGhyZWFkLmMKKysrIGIvc3JjL3RocmVhZC5j CkBAIC0xOSw2ICsxOSw5IEBAIENvcHlyaWdodCAoQykgMjAxMi0yMDE5IEZyZWUgU29mdHdhcmUg Rm91bmRhdGlvbiwgSW5jLgogCiAjaW5jbHVkZSA8Y29uZmlnLmg+CiAjaW5jbHVkZSA8c2V0am1w Lmg+CisjaWZkZWYgSEFWRV9HTElCCisjaW5jbHVkZSA8Z2xpYi5oPgorI2VuZGlmCiAjaW5jbHVk ZSAibGlzcC5oIgogI2luY2x1ZGUgImNoYXJhY3Rlci5oIgogI2luY2x1ZGUgImJ1ZmZlci5oIgpA QCAtODAsMTEgKzgzLDI2IEBAIHBvc3RfYWNxdWlyZV9nbG9iYWxfbG9jayAoc3RydWN0IHRocmVh ZF9zdGF0ZSAqc2VsZikKIHsKICAgc3RydWN0IHRocmVhZF9zdGF0ZSAqcHJldl90aHJlYWQgPSBj dXJyZW50X3RocmVhZDsKIAorI2lmZGVmIEhBVkVfR0xJQgorICBpZiAoY3VycmVudF90aHJlYWQg IT0gTlVMTCAmJiBjdXJyZW50X3RocmVhZC0+aG9sZGluZ19nbGliX2xvY2spCisgICAgZ19tYWlu X2NvbnRleHRfcmVsZWFzZSAoY3VycmVudF90aHJlYWQtPmNvbnRleHQpOworI2VuZGlmCisKICAg LyogRG8gdGhpcyBlYXJseSBvbiwgc28gdGhhdCBjb2RlIGJlbG93IGNvdWxkIHNpZ25hbCBlcnJv cnMgKGUuZy4sCiAgICAgIHVuYmluZF9mb3JfdGhyZWFkX3N3aXRjaCBtaWdodCkgY29ycmVjdGx5 LCBiZWNhdXNlIHdlIGFyZSBhbHJlYWR5Ci0gICAgIHJ1bm5pbmcgaW4gdGhlIGNvbnRleHQgb2Yg dGhlIHRocmVhZCBwb2ludGVkIGJ5IFNFTEYuICAqLworICAgICBydW5uaW5nIGluIHRoZSBjb250 ZXh0IG9mIHRoZSB0aHJlYWQgcG9pbnRlZCB0byBieSBTRUxGLiAgKi8KICAgY3VycmVudF90aHJl YWQgPSBzZWxmOwogCisjaWZkZWYgSEFWRV9HTElCCisgIGlmIChjdXJyZW50X3RocmVhZC0+aG9s ZGluZ19nbGliX2xvY2spCisgICAgZG8KKyAgICAgIHsKKwljdXJyZW50X3RocmVhZC0+aG9sZGlu Z19nbGliX2xvY2sgPQorCSAgZ19tYWluX2NvbnRleHRfYWNxdWlyZSAoY3VycmVudF90aHJlYWQt PmNvbnRleHQpOworICAgICAgfQorICAgIHdoaWxlICghY3VycmVudF90aHJlYWQtPmhvbGRpbmdf Z2xpYl9sb2NrKTsKKyNlbmRpZgorCiAgIGlmIChwcmV2X3RocmVhZCAhPSBjdXJyZW50X3RocmVh ZCkKICAgICB7CiAgICAgICAvKiBQUkVWX1RIUkVBRCBpcyBOVUxMIGlmIHRoZSBwcmV2aW91c2x5 IGN1cnJlbnQgdGhyZWFkCkBAIC03NTYsNiArNzc0LDEwIEBAIHJ1bl90aHJlYWQgKHZvaWQgKnN0 YXRlKQogICAgICAgfQogICB9CiAKKyNpZmRlZiBIQVZFX0dMSUIKKyAgaWYgKGN1cnJlbnRfdGhy ZWFkLT5ob2xkaW5nX2dsaWJfbG9jaykKKyAgICBnX21haW5fY29udGV4dF9yZWxlYXNlIChjdXJy ZW50X3RocmVhZC0+Y29udGV4dCk7CisjZW5kaWYKICAgY3VycmVudF90aHJlYWQgPSBOVUxMOwog ICBzeXNfY29uZF9icm9hZGNhc3QgKCZzZWxmLT50aHJlYWRfY29uZHZhcik7CiAKZGlmZiAtLWdp dCBhL3NyYy90aHJlYWQuaCBiL3NyYy90aHJlYWQuaAppbmRleCA0OThiOTkwOWM5Li45ZTVjODcw MDBlIDEwMDY0NAotLS0gYS9zcmMvdGhyZWFkLmgKKysrIGIvc3JjL3RocmVhZC5oCkBAIC0yOSw2 ICsyOSwxMCBAQCAjZGVmaW5lIFRIUkVBRF9ICiAjaW5jbHVkZSA8c2lnbmFsLmg+CQkvKiBzaWdz ZXRfdCAqLwogI2VuZGlmCiAKKyNpZmRlZiBIQVZFX0dMSUIKKyNpbmNsdWRlIDxnbGliLmg+Cisj ZW5kaWYKKwogI2luY2x1ZGUgInN5c3NlbGVjdC5oIgkJLyogRklYTUUgKi8KICNpbmNsdWRlICJz eXN0aHJlYWQuaCIKIApAQCAtMTY5LDYgKzE3MywxMCBAQCAjZGVmaW5lIGdldGNqbXAgKGN1cnJl bnRfdGhyZWFkLT5tX2dldGNqbXApCiAgICAgIGludGVycnVwdGVyIHNob3VsZCBicm9hZGNhc3Qg dG8gdGhpcyBjb25kaXRpb24uICAqLwogICBzeXNfY29uZF90ICp3YWl0X2NvbmR2YXI7CiAKKyNp ZmRlZiBIQVZFX0dMSUIKKyAgYm9vbCBob2xkaW5nX2dsaWJfbG9jazsKKyAgR01haW5Db250ZXh0 ICpjb250ZXh0OworI2VuZGlmCiAgIC8qIFRoaXMgdGhyZWFkIG1pZ2h0IGhhdmUgcmVsZWFzZWQg dGhlIGdsb2JhbCBsb2NrLiAgSWYgc28sIHRoaXMgaXMKICAgICAgbm9uLXplcm8uICBXaGVuIGEg dGhyZWFkIHJ1bnMgb3V0c2lkZSB0aHJlYWRfc2VsZWN0IHdpdGggdGhpcwogICAgICBmbGFnIG5v bi16ZXJvLCBpdCBtZWFucyBpdCBoYXMgYmVlbiBpbnRlcnJ1cHRlZCBieSBTSUdJTlQgd2hpbGUK ZGlmZiAtLWdpdCBhL3NyYy94Z3NlbGVjdC5jIGIvc3JjL3hnc2VsZWN0LmMKaW5kZXggOTk4MmEx ZjBlOS4uMTIwYjQxMGU0ZCAxMDA2NDQKLS0tIGEvc3JjL3hnc2VsZWN0LmMKKysrIGIvc3JjL3hn c2VsZWN0LmMKQEAgLTU0LDEyICs1NCwxNiBAQCB4Z19zZWxlY3QgKGludCBmZHNfbGltLCBmZF9z ZXQgKnJmZHMsIGZkX3NldCAqd2ZkcywgZmRfc2V0ICplZmRzLAogICBHUG9sbEZEICpnZmRzID0g Z2Zkc19idWY7CiAgIGludCBnZmRzX3NpemUgPSBBUlJBWUVMVFMgKGdmZHNfYnVmKTsKICAgaW50 IG5fZ2ZkcywgcmV0dmFsID0gMCwgb3VyX2ZkcyA9IDAsIG1heF9mZHMgPSBmZHNfbGltIC0gMTsK LSAgYm9vbCBjb250ZXh0X2FjcXVpcmVkID0gZmFsc2U7CiAgIGludCBpLCBuZmRzLCB0bW9faW5f bWlsbGlzZWMsIG11c3RfZnJlZSA9IDA7CiAgIGJvb2wgbmVlZF90b19kaXNwYXRjaDsKIAogICBj b250ZXh0ID0gZ19tYWluX2NvbnRleHRfZGVmYXVsdCAoKTsKLSAgY29udGV4dF9hY3F1aXJlZCA9 IGdfbWFpbl9jb250ZXh0X2FjcXVpcmUgKGNvbnRleHQpOworICAvKiBBY3F1aXJlIHRoZSBsb2Nr LiAgVGhpcyBpcyBhIGJ1c3kgd2FpdCBmb3IgdGVzdGluZy4gICovCisgIGN1cnJlbnRfdGhyZWFk LT5jb250ZXh0ID0gY29udGV4dDsKKyAgd2hpbGUgKCFjdXJyZW50X3RocmVhZC0+aG9sZGluZ19n bGliX2xvY2spCisgICAgeworICAgICAgY3VycmVudF90aHJlYWQtPmhvbGRpbmdfZ2xpYl9sb2Nr ID0gZ19tYWluX2NvbnRleHRfYWNxdWlyZSAoY29udGV4dCk7CisgICAgfQogICAvKiBGSVhNRTog SWYgd2UgY291bGRuJ3QgYWNxdWlyZSB0aGUgY29udGV4dCwgd2UganVzdCBzaWxlbnRseSBwcm9j ZWVkCiAgICAgIGJlY2F1c2UgdGhpcyBmdW5jdGlvbiBoYW5kbGVzIG1vcmUgdGhhbiBqdXN0IGds aWIgZmlsZSBkZXNjcmlwdG9ycy4KICAgICAgTm90ZSB0aGF0LCBhcyBpbXBsZW1lbnRlZCwgdGhp cyBmYWlsdXJlIGlzIGNvbXBsZXRlbHkgc2lsZW50OiB0aGVyZSBpcwpAQCAtNzAsNyArNzQsNyBA QCB4Z19zZWxlY3QgKGludCBmZHNfbGltLCBmZF9zZXQgKnJmZHMsIGZkX3NldCAqd2ZkcywgZmRf c2V0ICplZmRzLAogICBpZiAod2ZkcykgYWxsX3dmZHMgPSAqd2ZkczsKICAgZWxzZSBGRF9aRVJP ICgmYWxsX3dmZHMpOwogCi0gIG5fZ2ZkcyA9IChjb250ZXh0X2FjcXVpcmVkCisgIG5fZ2ZkcyA9 IChjdXJyZW50X3RocmVhZC0+aG9sZGluZ19nbGliX2xvY2sKIAkgICAgPyBnX21haW5fY29udGV4 dF9xdWVyeSAoY29udGV4dCwgR19QUklPUklUWV9MT1csICZ0bW9faW5fbWlsbGlzZWMsCiAJCQkJ ICAgIGdmZHMsIGdmZHNfc2l6ZSkKIAkgICAgOiAtMSk7CkBAIC0xNTEsNyArMTU1LDcgQEAgeGdf c2VsZWN0IChpbnQgZmRzX2xpbSwgZmRfc2V0ICpyZmRzLCBmZF9zZXQgKndmZHMsIGZkX3NldCAq ZWZkcywKICNlbHNlCiAgIG5lZWRfdG9fZGlzcGF0Y2ggPSB0cnVlOwogI2VuZGlmCi0gIGlmIChu ZWVkX3RvX2Rpc3BhdGNoICYmIGNvbnRleHRfYWNxdWlyZWQpCisgIGlmIChuZWVkX3RvX2Rpc3Bh dGNoICYmIGN1cnJlbnRfdGhyZWFkLT5ob2xkaW5nX2dsaWJfbG9jaykKICAgICB7CiAgICAgICBp bnQgcHNlbGVjdF9lcnJubyA9IGVycm5vOwogICAgICAgLyogUHJldmVudCBnX21haW5fZGlzcGF0 Y2ggcmVjdXJzaW9uLCB0aGF0IHdvdWxkIG9jY3VyIHdpdGhvdXQKQEAgLTE2NCw4ICsxNjgsMTEg QEAgeGdfc2VsZWN0IChpbnQgZmRzX2xpbSwgZmRfc2V0ICpyZmRzLCBmZF9zZXQgKndmZHMsIGZk X3NldCAqZWZkcywKICAgICAgIGVycm5vID0gcHNlbGVjdF9lcnJubzsKICAgICB9CiAKLSAgaWYg KGNvbnRleHRfYWNxdWlyZWQpCi0gICAgZ19tYWluX2NvbnRleHRfcmVsZWFzZSAoY29udGV4dCk7 CisgIGlmIChjdXJyZW50X3RocmVhZC0+aG9sZGluZ19nbGliX2xvY2spCisgICAgeworICAgICAg Z19tYWluX2NvbnRleHRfcmVsZWFzZSAoY29udGV4dCk7CisgICAgICBjdXJyZW50X3RocmVhZC0+ aG9sZGluZ19nbGliX2xvY2sgPSBmYWxzZTsKKyAgICB9CiAKICAgLyogVG8gbm90IGhhdmUgdG8g cmVjYWxjdWxhdGUgdGltZW91dCwgcmV0dXJuIGxpa2UgdGhpcy4gICovCiAgIGlmICgob3VyX2Zk cyA+IDAgfHwgKG5mZHMgPT0gMCAmJiB0bW9wID09ICZ0bW8pKSAmJiAocmV0dmFsID09IDApKQo= --000000000000b3a7a4058d80de4f-- From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 19:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156295987811291 (code B ref 36609); Fri, 12 Jul 2019 19:32:01 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 19:31:18 +0000 Received: from localhost ([127.0.0.1]:40749 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hm1GI-0002w3-01 for submit@debbugs.gnu.org; Fri, 12 Jul 2019 15:31:18 -0400 Received: from mail-oi1-f178.google.com ([209.85.167.178]:35379) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hm1GG-0002vp-CC for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 15:31:16 -0400 Received: by mail-oi1-f178.google.com with SMTP id a127so8124639oii.2 for <36609@debbugs.gnu.org>; Fri, 12 Jul 2019 12:31:16 -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=uh18TgPOc3bPBJ4lUI/llHtgVdLs1H48yh++40fsg2U=; b=F19rYLdhK8XMXmJoPOZpufPL3I6ABLzdxwiWADRec+hoHMRAKRUi2dvlYy9khKU+pD +XVAZ5Bti1pFsK6SWPd1YfALS6sWwA8NoO5Okbb3YgQl04j2rLabN6/bJNzJCw65pJHD JTzqykZLDInjVDe6bBon5kt7sjANS0/Zmo0y4SeUkG4FA2IKbod/y6q32S9RUT2SXDBe CM/1H4MghoxrR6fFym2ElheLHYF7WmdWtLZVdz293WFsQG7BybEd5KiUmb8Sd5rv3Omd hvOWbzrPeCpk8zshh6zKhzFwTOFqd5o3ZAftW1s4Zw4SWTh+Mc8vti/j7XIY8sXCUe5G c5tg== 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=uh18TgPOc3bPBJ4lUI/llHtgVdLs1H48yh++40fsg2U=; b=HwQJKfv2r51jWwQvnMRaQgIkrP0FZTZ31upSBhyUisQZwDktc4zlGgdQ+yB1U76niu zIwc5YZWhHEQmG43HM8XYoZG1MTzzES7UEHIf8vbyWDw0FtC9QeNOlhnl9zawqZWWDp5 Kt29HDADzi8HmZyn7A8wXkyjfeL/8gxMbUnc+LvXJe18ZXSqR2m4t9IMdDSlNDfxNsja CWDuvCYpoR+clpZmrZ/elV7Cw1A+IqnKJe6pFdwvfQbjP4RNlSg7VtPdV8HT6pNLtfqj 2HD8AOZxcLNihYmFzErpG5rsfkYwDIo+EmJuiMkiCa3/tkGqbard4Irk3BA8ArBPLOBy sfgQ== X-Gm-Message-State: APjAAAU64RMC3LI4XzVAD/zyvywPQtR71QE7Ekesye0zr6xaPiVUe+Jh 4a8LEEgAvtN3It2MeAmwp+E20UeN2NDPULUjbSw= X-Google-Smtp-Source: APXvYqzErcMEOyrktymeGNAhcIZjv7s7pPG4/QZxz1CAB80dwOlaznowZRNnPrFgZxLfh/0AB4JeMx4/PnldMBYjdvE= X-Received: by 2002:a05:6808:313:: with SMTP id i19mr6790386oie.30.1562959870729; Fri, 12 Jul 2019 12:31:10 -0700 (PDT) MIME-Version: 1.0 References: <87muhks3b5.fsf@hochschule-trier.de> <83k1cn2z0l.fsf@gnu.org> <83ftnb2wf9.fsf@gnu.org> <83blxz2t43.fsf@gnu.org> In-Reply-To: <83blxz2t43.fsf@gnu.org> From: Pip Cet Date: Fri, 12 Jul 2019 19:30:34 +0000 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) 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 (-) > > > We should either release the global lock before the thread exits, or > > > defer the acting upon the signal until later. We cannot disable the > > > signal handling altogether because it is entirely legitimate to signal > > > another thread, and when we do, that other thread will _always_ be > > > inside thread_select. > > > > Really? What about thread-yield? > > What about it? > > You are asking whether, when thread-signal is executed, the thread > which we are signaling is necessarily parked inside thread_select? If > so, I don't understand your surprise: only one thread can ever be > running, and that is by definition the thread which calls > thread-signal. All the other threads cannot be running, which means > they are parked either in thread_select or in sys_mutex_lock called > from acquire_global_lock. Right? No, they might also be in the sys_thread_yield syscall, having released the global lock but not yet reacquired it: release_global_lock (); sys_thread_yield (); <<<<< here acquire_global_lock (self); > As for thread-yield, I'm not sure I understand how is it related to > the issue we are discussing. I'm not sure how it's relevant to assert that "that other thread will _always_ be inside thread_select". I have an idea where you might be going with that, but that idea wouldn't work (to release the lock from the signalling thread, not the signalled thread that holds it). > If the problem with missing events, > then which events are those, and what bad things will happen if we > miss them? All events that glib knows about but Emacs doesn't. For example, a glib timeout is apparently used to achieve some kind of scroll effect on GTK menus, which is why we call xg_select from xmenu.c. I don't know which libraries use glib-based threads, but I think dbus does, too. I believe, but am not certain, that this also includes X events when using GTK. That would explain the frozen sessions. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 19:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156296144513675 (code B ref 36609); Fri, 12 Jul 2019 19:58:01 +0000 Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 19:57:25 +0000 Received: from localhost ([127.0.0.1]:40753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hm1fW-0003YR-6f for submit@debbugs.gnu.org; Fri, 12 Jul 2019 15:57:24 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40790) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hm1fU-0003YF-Hf for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 15:57:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46916) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hm1fO-0006LU-PJ; Fri, 12 Jul 2019 15:57:14 -0400 Received: from [176.228.60.248] (port=4397 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hm1fN-0005E9-BI; Fri, 12 Jul 2019 15:57:14 -0400 Date: Fri, 12 Jul 2019 22:57:05 +0300 Message-Id: <8336jb2fhq.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Pip Cet on Fri, 12 Jul 2019 19:24:38 +0000) References: <87muhks3b5.fsf@hochschule-trier.de> <83muhj2zmb.fsf@gnu.org> <83ims72xcj.fsf@gnu.org> <83a7dj2sz9.fsf@gnu.org> <835zo72jmr.fsf@gnu.org> <834l3r2jbe.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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: Pip Cet > Date: Fri, 12 Jul 2019 19:24:38 +0000 > Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de > > I'm now convinced that there simply is no safe way to call select() > from two threads at once when using glib. I hope not, although GTK with its idiosyncrasies caused a lot of pain for the threads implementation in Emacs. > I think our options are hacking around it and hoping nothing breaks > (this is what the attached patch does; it releases the main context > glib lock from the wrong thread soon "after" the other thread called > select, but there's actually no way to ensure that "after" is > accurate), or rewriting things so we have a single thread that does > all the select()ing. Hmm... how would this work with your patch? Suppose one thread calls xg_select, acquires the Glib lock, sets its holding_glib_lock flag, then releases the global Lisp lock and calls pselect. Since the global Lisp lock is now up for grabs, some other Lisp thread can acquire it and start running. If that other thread then calls xg_select, it will hang forever trying to acquire the Glib lock, because the first thread that holds it is stuck in pselect. Am I missing something? I know very little about GTK and the Glib context lock, but AFAIR we really must treat that lock as a global one, not a thread-local one. So I think it's okay for one thread to take the Glib lock, and another to release it, because Glib just wants to know whether the "rest of the program" has it, it doesn't care which thread is that which holds the lock. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Jul 2019 06:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156300062010683 (code B ref 36609); Sat, 13 Jul 2019 06:51:02 +0000 Received: (at 36609) by debbugs.gnu.org; 13 Jul 2019 06:50:20 +0000 Received: from localhost ([127.0.0.1]:41379 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmBrP-0002mE-E5 for submit@debbugs.gnu.org; Sat, 13 Jul 2019 02:50:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57945) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmBrM-0002lM-Pt for 36609@debbugs.gnu.org; Sat, 13 Jul 2019 02:50:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58114) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hmBrH-0003xy-1u; Sat, 13 Jul 2019 02:50:11 -0400 Received: from [176.228.60.248] (port=4320 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hmBrG-00042u-4u; Sat, 13 Jul 2019 02:50:10 -0400 Date: Sat, 13 Jul 2019 09:50:02 +0300 Message-Id: <83wogm1l9h.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Pip Cet on Fri, 12 Jul 2019 19:30:34 +0000) References: <87muhks3b5.fsf@hochschule-trier.de> <83k1cn2z0l.fsf@gnu.org> <83ftnb2wf9.fsf@gnu.org> <83blxz2t43.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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: Pip Cet > Date: Fri, 12 Jul 2019 19:30:34 +0000 > Cc: politza@hochschule-trier.de, 36609@debbugs.gnu.org > > > > > We should either release the global lock before the thread exits, or > > > > defer the acting upon the signal until later. We cannot disable the > > > > signal handling altogether because it is entirely legitimate to signal > > > > another thread, and when we do, that other thread will _always_ be > > > > inside thread_select. > > > > > > Really? What about thread-yield? > > > > What about it? > > > > You are asking whether, when thread-signal is executed, the thread > > which we are signaling is necessarily parked inside thread_select? If > > so, I don't understand your surprise: only one thread can ever be > > running, and that is by definition the thread which calls > > thread-signal. All the other threads cannot be running, which means > > they are parked either in thread_select or in sys_mutex_lock called > > from acquire_global_lock. Right? > > No, they might also be in the sys_thread_yield syscall, having > released the global lock but not yet reacquired it: > > release_global_lock (); > sys_thread_yield (); <<<<< here > acquire_global_lock (self); OK, but that, too, means the thread being signaled is not running, right? And I still think that a very frequent case, perhaps the most frequent, is that the thread being signaled is inside thread_select. > I'm not sure how it's relevant to assert that "that other thread will > _always_ be inside thread_select". OK, we've now established that the other thread could also be in acquire_global_lock or (for a very short time) in sys_thread_yield. > I have an idea where you might be going with that I was merely pointing out that we cannot disable the signal handling as a means to solve the problem. > but that idea wouldn't work (to release the lock from the signalling > thread, not the signalled thread that holds it). Maybe we have a misunderstanding here. I was talking about this part of post_acquire_global_lock: /* We could have been signaled while waiting to grab the global lock for the first time since this thread was created, in which case we didn't yet have the opportunity to set up the handlers. Delay raising the signal in that case (it will be actually raised when the thread comes here after acquiring the lock the next time). */ if (!NILP (current_thread->error_symbol) && handlerlist) { Lisp_Object sym = current_thread->error_symbol; Lisp_Object data = current_thread->error_data; current_thread->error_symbol = Qnil; current_thread->error_data = Qnil; Fsignal (sym, data); } In this part, we have already switched to the thread that has been signaled, so we are in the signaled thread, not in the signaling thread. I meant to release the lock before the call to Fsignal here. > > If the problem with missing events, > > then which events are those, and what bad things will happen if we > > miss them? > > All events that glib knows about but Emacs doesn't. For example, a > glib timeout is apparently used to achieve some kind of scroll effect > on GTK menus, which is why we call xg_select from xmenu.c. > > I don't know which libraries use glib-based threads, but I think dbus does, too. > > I believe, but am not certain, that this also includes X events when > using GTK. That would explain the frozen sessions. So is the problem that the Glib context is locked "forever", or is the problem that it's locked by another Lisp thread, even if this lock is short-lived? If the former, then arranging for the release of that lock when the signaled thread exits would solve the problem, right? And if the problem is the latter one, then why didn't we hear about this much earlier? Can you show the bad effect from missing these events without signaling a thread? Thanks. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Jul 2019 14:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.15630286942614 (code B ref 36609); Sat, 13 Jul 2019 14:39:02 +0000 Received: (at 36609) by debbugs.gnu.org; 13 Jul 2019 14:38:14 +0000 Received: from localhost ([127.0.0.1]:43039 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmJAD-0000g5-Du for submit@debbugs.gnu.org; Sat, 13 Jul 2019 10:38:14 -0400 Received: from mail-ot1-f66.google.com ([209.85.210.66]:37957) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmJA7-0000fa-J2 for 36609@debbugs.gnu.org; Sat, 13 Jul 2019 10:38:08 -0400 Received: by mail-ot1-f66.google.com with SMTP id d17so12379131oth.5 for <36609@debbugs.gnu.org>; Sat, 13 Jul 2019 07:38:07 -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=FAqQN2vS7aqDYXJTpIkMEcxCQY5XmhkSyFZUIkX24Xo=; b=VPCh/AcmZjUvBtdba+5GTT7PZ5Cqj+zw9PFgG6sVQkDRVYLdYsxPpIi3e2qK27voa6 uAg2CUroZ1+7sS+FXbMzSd92QqUxJxCSMs8aBd6hiNE/nY6cRe/TpdJkpQ1otZKdNfI/ XgVKYUc+8ru+uVwhkyyJErIYCoEJ6p5SDDi4yf5C3GrNLsIIYm/D9qBlIzKqyJ1IRGPH czzNEhegRZvWBH6wxVeUWLr5HXQAAievgaKkp6rFDmbR9qAPn8wDAvlxqMy7FcpX8k4D UzwQk0CJI1ROxcGbrHSRfPTdZCpg50UGCxFSLhBsxYMlsQNoxLSkgmdyVC9oBaR8kMnr kRrQ== 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=FAqQN2vS7aqDYXJTpIkMEcxCQY5XmhkSyFZUIkX24Xo=; b=tDeif4CuIQp8NeVTod5VHtFqliJ66W35psZPg3VgEi1/kcRYNtmn0SVjVlfZLZ/fJE atyecbWA5gaffOaV1GWXJYf3MbLEmxu1bXXMsWw3x+3Nl0hhJD1d3Lmft+QdqQtQ0Wp+ f8HLIo0HPjY6ptdq6hQnzMBcAh74P2nYqePKcJSYi1+2y5MEnSYrxlWT7UgAUuRI4GK2 mtBGyug1cyB740cDpysSEW8tfav2yf1u/hlaypw7ENszstLZXCiMTceM0AbaocCvtANk N112+x5cG6czvdH8VQuS6rVwQnZ7/RSGPvP1pD7MVLhrdzxgue4UTo5WRpYOphHLeXUt hdPQ== X-Gm-Message-State: APjAAAU7BVIszUnmLW7S8a7z4nNrrTei8TQ88sRE9jpqK/ApHTO1p1c6 HcnLAH6TBnJL6cIyUasWcVYt2fWyll4iYqbZ1ivsfg== X-Google-Smtp-Source: APXvYqycShPz4iqZw4NaExzvLo18KrEKUyYM3eZKG/QkisMRNtqmO2fIahQdAnGhMQKfOog4g6pFinH24+/VAAaoJcw= X-Received: by 2002:a9d:554b:: with SMTP id h11mr5058923oti.154.1563028681854; Sat, 13 Jul 2019 07:38:01 -0700 (PDT) MIME-Version: 1.0 References: <87muhks3b5.fsf@hochschule-trier.de> <83muhj2zmb.fsf@gnu.org> <83ims72xcj.fsf@gnu.org> <83a7dj2sz9.fsf@gnu.org> <835zo72jmr.fsf@gnu.org> <834l3r2jbe.fsf@gnu.org> <8336jb2fhq.fsf@gnu.org> In-Reply-To: <8336jb2fhq.fsf@gnu.org> From: Pip Cet Date: Sat, 13 Jul 2019 14:37:25 +0000 Message-ID: Content-Type: multipart/mixed; boundary="0000000000005b37e5058d90f9b8" X-Spam-Score: 0.0 (/) 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 (-) --0000000000005b37e5058d90f9b8 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 12, 2019 at 7:57 PM Eli Zaretskii wrote: > > I'm now convinced that there simply is no safe way to call select() > > from two threads at once when using glib. > > I hope not, although GTK with its idiosyncrasies caused a lot of pain > for the threads implementation in Emacs. Well, I think we're going to have to do one or more of the following: - have a race condition - access glib-locked data from the "wrong" thread (another Emacs thread) - release the glib lock from the "wrong" thread (another Emacs thread) Of these, the second is the best alternative, I think: we simply grab the g_main_context lock globally, acting for all Emacs threads, and the last thread to require it releases it when it leaves xg_select. As long as there's at least one thread in the critical section of xg_select, we hold the lock, but access to the context isn't necessarily from the thread which locked it. > > I think our options are hacking around it and hoping nothing breaks > > (this is what the attached patch does; it releases the main context > > glib lock from the wrong thread soon "after" the other thread called > > select, but there's actually no way to ensure that "after" is > > accurate), or rewriting things so we have a single thread that does > > all the select()ing. > > Hmm... how would this work with your patch? Suppose one thread calls > xg_select, acquires the Glib lock, sets its holding_glib_lock flag, > then releases the global Lisp lock and calls pselect. Since the > global Lisp lock is now up for grabs, some other Lisp thread can > acquire it and start running. And when it starts running, it releases the Glib lock. > If that other thread then calls > xg_select, it will hang forever trying to acquire the Glib lock, > because the first thread that holds it is stuck in pselect. The first thread no longer holds the Glib lock, it was released when we switched threads. > I know very little about GTK and the Glib context lock, but AFAIR we > really must treat that lock as a global one, not a thread-local one. > So I think it's okay for one thread to take the Glib lock, and another > to release it, because Glib just wants to know whether the "rest of > the program" has it, it doesn't care which thread is that which holds > the lock. Okay, that sounds like option #2 above. The attached patch exposes glib externals to the generic code, but it appears to work. If you think the approach is okay, I'll move the glib-specific parts to xgselect.c (if that's okay). --0000000000005b37e5058d90f9b8 Content-Type: text/x-patch; charset="US-ASCII"; name="glib-hack-002.diff" Content-Disposition: attachment; filename="glib-hack-002.diff" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jy1mw7ph0 ZGlmZiAtLWdpdCBhL3NyYy90aHJlYWQuYyBiL3NyYy90aHJlYWQuYwppbmRleCBlMmRlYWRkN2E4 Li4wZGRiNzk0NjBiIDEwMDY0NAotLS0gYS9zcmMvdGhyZWFkLmMKKysrIGIvc3JjL3RocmVhZC5j CkBAIC0xOSw2ICsxOSw5IEBAIENvcHlyaWdodCAoQykgMjAxMi0yMDE5IEZyZWUgU29mdHdhcmUg Rm91bmRhdGlvbiwgSW5jLgogCiAjaW5jbHVkZSA8Y29uZmlnLmg+CiAjaW5jbHVkZSA8c2V0am1w Lmg+CisjaWZkZWYgSEFWRV9HTElCCisjaW5jbHVkZSA8Z2xpYi5oPgorI2VuZGlmCiAjaW5jbHVk ZSAibGlzcC5oIgogI2luY2x1ZGUgImNoYXJhY3Rlci5oIgogI2luY2x1ZGUgImJ1ZmZlci5oIgpA QCAtODIsNyArODUsNyBAQCBwb3N0X2FjcXVpcmVfZ2xvYmFsX2xvY2sgKHN0cnVjdCB0aHJlYWRf c3RhdGUgKnNlbGYpCiAKICAgLyogRG8gdGhpcyBlYXJseSBvbiwgc28gdGhhdCBjb2RlIGJlbG93 IGNvdWxkIHNpZ25hbCBlcnJvcnMgKGUuZy4sCiAgICAgIHVuYmluZF9mb3JfdGhyZWFkX3N3aXRj aCBtaWdodCkgY29ycmVjdGx5LCBiZWNhdXNlIHdlIGFyZSBhbHJlYWR5Ci0gICAgIHJ1bm5pbmcg aW4gdGhlIGNvbnRleHQgb2YgdGhlIHRocmVhZCBwb2ludGVkIGJ5IFNFTEYuICAqLworICAgICBy dW5uaW5nIGluIHRoZSBjb250ZXh0IG9mIHRoZSB0aHJlYWQgcG9pbnRlZCB0byBieSBTRUxGLiAg Ki8KICAgY3VycmVudF90aHJlYWQgPSBzZWxmOwogCiAgIGlmIChwcmV2X3RocmVhZCAhPSBjdXJy ZW50X3RocmVhZCkKQEAgLTU4Niw2ICs1ODksMTcgQEAgcmVhbGx5X2NhbGxfc2VsZWN0ICh2b2lk ICphcmcpCiAgIHNhLT5yZXN1bHQgPSAoc2EtPmZ1bmMpIChzYS0+bWF4X2Zkcywgc2EtPnJmZHMs IHNhLT53ZmRzLCBzYS0+ZWZkcywKIAkJCSAgIHNhLT50aW1lb3V0LCBzYS0+c2lnbWFzayk7CiAK KyNpZmRlZiBIQVZFX0dMSUIKKyAgLyogUmVsZWFzZSB0aGUgR2xpYiBsb2NrLCBpZiB0aGVyZSBh cmUgbm8gb3RoZXIgdGhyZWFkcyBpbiB0aGUKKyAgICAgY3JpdGljYWwgc2VjdGlvbi4gICovCisg IGlmIChjdXJyZW50X3RocmVhZCAhPSBOVUxMICYmIGN1cnJlbnRfdGhyZWFkLT5ob2xkaW5nX2ds aWJfbG9jaykKKyAgICB7CisgICAgICBjdXJyZW50X3RocmVhZC0+aG9sZGluZ19nbGliX2xvY2sg PSBmYWxzZTsKKyAgICAgIGlmICgtLXRocmVhZHNfaG9sZGluZ19nbGliX2xvY2sgPT0gMCkKKwln X21haW5fY29udGV4dF9yZWxlYXNlIChnbGliX21haW5fY29udGV4dCk7CisgICAgfQorI2VuZGlm CisKICAgYmxvY2tfaW50ZXJydXB0X3NpZ25hbCAoJm9sZHNldCk7CiAgIC8qIElmIHdlIHdlcmUg aW50ZXJydXB0ZWQgYnkgQy1nIHdoaWxlIGluc2lkZSBzYS0+ZnVuYyBhYm92ZSwgdGhlCiAgICAg IHNpZ25hbCBoYW5kbGVyIGNvdWxkIGhhdmUgY2FsbGVkIG1heWJlX3JlYWNxdWlyZV9nbG9iYWxf bG9jaywgaW4KQEAgLTc1Niw2ICs3NzAsMTMgQEAgcnVuX3RocmVhZCAodm9pZCAqc3RhdGUpCiAg ICAgICB9CiAgIH0KIAorI2lmZGVmIEhBVkVfR0xJQgorICAvKiBSZW1lbWJlciB0byByZWxlYXNl IHRoZSBHbGliIGxvY2sgd2UgbWlnaHQgc3RpbGwgYmUgaG9sZGluZworICAgICAoPykgICovCisg IGlmIChjdXJyZW50X3RocmVhZC0+aG9sZGluZ19nbGliX2xvY2spCisgICAgaWYgKC0tdGhyZWFk c19ob2xkaW5nX2dsaWJfbG9jayA9PSAwKQorICAgICAgZ19tYWluX2NvbnRleHRfcmVsZWFzZSAo Z2xpYl9tYWluX2NvbnRleHQpOworI2VuZGlmCiAgIGN1cnJlbnRfdGhyZWFkID0gTlVMTDsKICAg c3lzX2NvbmRfYnJvYWRjYXN0ICgmc2VsZi0+dGhyZWFkX2NvbmR2YXIpOwogCmRpZmYgLS1naXQg YS9zcmMvdGhyZWFkLmggYi9zcmMvdGhyZWFkLmgKaW5kZXggNDk4Yjk5MDljOS4uMWE1OGY2NWM4 OCAxMDA2NDQKLS0tIGEvc3JjL3RocmVhZC5oCisrKyBiL3NyYy90aHJlYWQuaApAQCAtMjksOSAr MjksMTggQEAgI2RlZmluZSBUSFJFQURfSAogI2luY2x1ZGUgPHNpZ25hbC5oPgkJLyogc2lnc2V0 X3QgKi8KICNlbmRpZgogCisjaWZkZWYgSEFWRV9HTElCCisjaW5jbHVkZSA8Z2xpYi5oPgorI2Vu ZGlmCisKICNpbmNsdWRlICJzeXNzZWxlY3QuaCIJCS8qIEZJWE1FICovCiAjaW5jbHVkZSAic3lz dGhyZWFkLmgiCiAKKyNpZmRlZiBIQVZFX0dMSUIKK2V4dGVybiBwdHJkaWZmX3QgdGhyZWFkc19o b2xkaW5nX2dsaWJfbG9jazsKK2V4dGVybiBHTWFpbkNvbnRleHQgKmdsaWJfbWFpbl9jb250ZXh0 OworI2VuZGlmCisKIHN0cnVjdCB0aHJlYWRfc3RhdGUKIHsKICAgdW5pb24gdmVjdG9ybGlrZV9o ZWFkZXIgaGVhZGVyOwpAQCAtMTY5LDYgKzE3OCw5IEBAICNkZWZpbmUgZ2V0Y2ptcCAoY3VycmVu dF90aHJlYWQtPm1fZ2V0Y2ptcCkKICAgICAgaW50ZXJydXB0ZXIgc2hvdWxkIGJyb2FkY2FzdCB0 byB0aGlzIGNvbmRpdGlvbi4gICovCiAgIHN5c19jb25kX3QgKndhaXRfY29uZHZhcjsKIAorI2lm ZGVmIEhBVkVfR0xJQgorICBib29sIGhvbGRpbmdfZ2xpYl9sb2NrOworI2VuZGlmCiAgIC8qIFRo aXMgdGhyZWFkIG1pZ2h0IGhhdmUgcmVsZWFzZWQgdGhlIGdsb2JhbCBsb2NrLiAgSWYgc28sIHRo aXMgaXMKICAgICAgbm9uLXplcm8uICBXaGVuIGEgdGhyZWFkIHJ1bnMgb3V0c2lkZSB0aHJlYWRf c2VsZWN0IHdpdGggdGhpcwogICAgICBmbGFnIG5vbi16ZXJvLCBpdCBtZWFucyBpdCBoYXMgYmVl biBpbnRlcnJ1cHRlZCBieSBTSUdJTlQgd2hpbGUKZGlmZiAtLWdpdCBhL3NyYy94Z3NlbGVjdC5j IGIvc3JjL3hnc2VsZWN0LmMKaW5kZXggOTk4MmExZjBlOS4uMGM5NTg1N2VmOSAxMDA2NDQKLS0t IGEvc3JjL3hnc2VsZWN0LmMKKysrIGIvc3JjL3hnc2VsZWN0LmMKQEAgLTI5LDYgKzI5LDkgQEAg Q29weXJpZ2h0IChDKSAyMDA5LTIwMTkgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCiAj aW5jbHVkZSAiYmxvY2tpbnB1dC5oIgogI2luY2x1ZGUgInN5c3RpbWUuaCIKIAorcHRyZGlmZl90 IHRocmVhZHNfaG9sZGluZ19nbGliX2xvY2s7CitHTWFpbkNvbnRleHQgKmdsaWJfbWFpbl9jb250 ZXh0OworCiAvKiBgeGdfc2VsZWN0JyBpcyBhIGBwc2VsZWN0JyByZXBsYWNlbWVudC4gIFdoeSBk byB3ZSBuZWVkIGEgc2VwYXJhdGUgZnVuY3Rpb24/CiAgICAxLiBUaW1lb3V0cy4gIEdsaWIgYW5k IEd0ayByZWx5IG9uIHRpbWVyIGV2ZW50cy4gIElmIHdlIGRpZCBwc2VsZWN0CiAgICAgICB3aXRo IGEgZ3JlYXRlciB0aW1lb3V0IHRoZW4gdGhlIG9uZSBzY2hlZHVsZWQgYnkgR2xpYiwgd2Ugd291 bGQKQEAgLTU0LDI2ICs1NywyOCBAQCB4Z19zZWxlY3QgKGludCBmZHNfbGltLCBmZF9zZXQgKnJm ZHMsIGZkX3NldCAqd2ZkcywgZmRfc2V0ICplZmRzLAogICBHUG9sbEZEICpnZmRzID0gZ2Zkc19i dWY7CiAgIGludCBnZmRzX3NpemUgPSBBUlJBWUVMVFMgKGdmZHNfYnVmKTsKICAgaW50IG5fZ2Zk cywgcmV0dmFsID0gMCwgb3VyX2ZkcyA9IDAsIG1heF9mZHMgPSBmZHNfbGltIC0gMTsKLSAgYm9v bCBjb250ZXh0X2FjcXVpcmVkID0gZmFsc2U7CiAgIGludCBpLCBuZmRzLCB0bW9faW5fbWlsbGlz ZWMsIG11c3RfZnJlZSA9IDA7CiAgIGJvb2wgbmVlZF90b19kaXNwYXRjaDsKIAogICBjb250ZXh0 ID0gZ19tYWluX2NvbnRleHRfZGVmYXVsdCAoKTsKLSAgY29udGV4dF9hY3F1aXJlZCA9IGdfbWFp bl9jb250ZXh0X2FjcXVpcmUgKGNvbnRleHQpOwotICAvKiBGSVhNRTogSWYgd2UgY291bGRuJ3Qg YWNxdWlyZSB0aGUgY29udGV4dCwgd2UganVzdCBzaWxlbnRseSBwcm9jZWVkCi0gICAgIGJlY2F1 c2UgdGhpcyBmdW5jdGlvbiBoYW5kbGVzIG1vcmUgdGhhbiBqdXN0IGdsaWIgZmlsZSBkZXNjcmlw dG9ycy4KLSAgICAgTm90ZSB0aGF0LCBhcyBpbXBsZW1lbnRlZCwgdGhpcyBmYWlsdXJlIGlzIGNv bXBsZXRlbHkgc2lsZW50OiB0aGVyZSBpcwotICAgICBubyBmZWVkYmFjayB0byB0aGUgY2FsbGVy LiAgKi8KKyAgLyogQWNxdWlyZSB0aGUgbG9jay4gIFRoaXMgaXMgYSBidXN5IHdhaXQgZm9yIHRl c3RpbmcuICAqLworICBpZiAoY3VycmVudF90aHJlYWQgIT0gTlVMTCAmJiAhY3VycmVudF90aHJl YWQtPmhvbGRpbmdfZ2xpYl9sb2NrKQorICAgIHsKKyAgICAgIGlmICh0aHJlYWRzX2hvbGRpbmdf Z2xpYl9sb2NrKysgPT0gMCkKKwl3aGlsZSAoIWdfbWFpbl9jb250ZXh0X2FjcXVpcmUgKGNvbnRl eHQpKQorCSAgeworCSAgfQorICAgICAgY3VycmVudF90aHJlYWQtPmhvbGRpbmdfZ2xpYl9sb2Nr ID0gdHJ1ZTsKKyAgICAgIGdsaWJfbWFpbl9jb250ZXh0ID0gY29udGV4dDsKKyAgICB9CiAKICAg aWYgKHJmZHMpIGFsbF9yZmRzID0gKnJmZHM7CiAgIGVsc2UgRkRfWkVSTyAoJmFsbF9yZmRzKTsK ICAgaWYgKHdmZHMpIGFsbF93ZmRzID0gKndmZHM7CiAgIGVsc2UgRkRfWkVSTyAoJmFsbF93ZmRz KTsKIAotICBuX2dmZHMgPSAoY29udGV4dF9hY3F1aXJlZAotCSAgICA/IGdfbWFpbl9jb250ZXh0 X3F1ZXJ5IChjb250ZXh0LCBHX1BSSU9SSVRZX0xPVywgJnRtb19pbl9taWxsaXNlYywKLQkJCQkg ICAgZ2ZkcywgZ2Zkc19zaXplKQotCSAgICA6IC0xKTsKKyAgbl9nZmRzID0gZ19tYWluX2NvbnRl eHRfcXVlcnkgKGNvbnRleHQsIEdfUFJJT1JJVFlfTE9XLCAmdG1vX2luX21pbGxpc2VjLAorCQkJ CSBnZmRzLCBnZmRzX3NpemUpOwogCiAgIGlmIChnZmRzX3NpemUgPCBuX2dmZHMpCiAgICAgewpA QCAtMTUxLDggKzE1NiwxOSBAQCB4Z19zZWxlY3QgKGludCBmZHNfbGltLCBmZF9zZXQgKnJmZHMs IGZkX3NldCAqd2ZkcywgZmRfc2V0ICplZmRzLAogI2Vsc2UKICAgbmVlZF90b19kaXNwYXRjaCA9 IHRydWU7CiAjZW5kaWYKLSAgaWYgKG5lZWRfdG9fZGlzcGF0Y2ggJiYgY29udGV4dF9hY3F1aXJl ZCkKKyAgaWYgKG5lZWRfdG9fZGlzcGF0Y2gpCiAgICAgeworICAgICAgLyogQWNxdWlyZSB0aGUg bG9jay4gIFRoaXMgaXMgYSBidXN5IHdhaXQgZm9yIHRlc3RpbmcuICAqLworICAgICAgZ2xpYl9t YWluX2NvbnRleHQgPSBjb250ZXh0OworICAgICAgaWYgKCFjdXJyZW50X3RocmVhZC0+aG9sZGlu Z19nbGliX2xvY2spCisJeworCSAgaWYgKHRocmVhZHNfaG9sZGluZ19nbGliX2xvY2srKyA9PSAw KQorCSAgICB3aGlsZSAoIWdfbWFpbl9jb250ZXh0X2FjcXVpcmUgKGNvbnRleHQpKQorCSAgICAg IHsKKwkgICAgICB9CisJICBjdXJyZW50X3RocmVhZC0+aG9sZGluZ19nbGliX2xvY2sgPSB0cnVl OworCX0KKwogICAgICAgaW50IHBzZWxlY3RfZXJybm8gPSBlcnJubzsKICAgICAgIC8qIFByZXZl bnQgZ19tYWluX2Rpc3BhdGNoIHJlY3Vyc2lvbiwgdGhhdCB3b3VsZCBvY2N1ciB3aXRob3V0CiAg ICAgICAgICBibG9ja19pbnB1dCB3cmFwcGVyLCBiZWNhdXNlIGV2ZW50IGhhbmRsZXJzIGNhbGwK QEAgLTE2NCw4ICsxODAsMTIgQEAgeGdfc2VsZWN0IChpbnQgZmRzX2xpbSwgZmRfc2V0ICpyZmRz LCBmZF9zZXQgKndmZHMsIGZkX3NldCAqZWZkcywKICAgICAgIGVycm5vID0gcHNlbGVjdF9lcnJu bzsKICAgICB9CiAKLSAgaWYgKGNvbnRleHRfYWNxdWlyZWQpCi0gICAgZ19tYWluX2NvbnRleHRf cmVsZWFzZSAoY29udGV4dCk7CisgIGlmIChjdXJyZW50X3RocmVhZCAhPSBOVUxMICYmIGN1cnJl bnRfdGhyZWFkLT5ob2xkaW5nX2dsaWJfbG9jaykKKyAgICBpZiAoLS10aHJlYWRzX2hvbGRpbmdf Z2xpYl9sb2NrID09IDApCisgICAgICB7CisJZ19tYWluX2NvbnRleHRfcmVsZWFzZSAoY29udGV4 dCk7CisJY3VycmVudF90aHJlYWQtPmhvbGRpbmdfZ2xpYl9sb2NrID0gZmFsc2U7CisgICAgICB9 CiAKICAgLyogVG8gbm90IGhhdmUgdG8gcmVjYWxjdWxhdGUgdGltZW91dCwgcmV0dXJuIGxpa2Ug dGhpcy4gICovCiAgIGlmICgob3VyX2ZkcyA+IDAgfHwgKG5mZHMgPT0gMCAmJiB0bW9wID09ICZ0 bW8pKSAmJiAocmV0dmFsID09IDApKQo= --0000000000005b37e5058d90f9b8-- From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Jul 2019 15:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156303023921862 (code B ref 36609); Sat, 13 Jul 2019 15:04:01 +0000 Received: (at 36609) by debbugs.gnu.org; 13 Jul 2019 15:03:59 +0000 Received: from localhost ([127.0.0.1]:43095 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmJZ8-0005gY-Ao for submit@debbugs.gnu.org; Sat, 13 Jul 2019 11:03:58 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41709) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmJZ6-0005gK-St for 36609@debbugs.gnu.org; Sat, 13 Jul 2019 11:03:57 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36235) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hmJYz-0004DX-Ed; Sat, 13 Jul 2019 11:03:50 -0400 Received: from [176.228.60.248] (port=3536 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hmJYx-0001fc-VE; Sat, 13 Jul 2019 11:03:49 -0400 Date: Sat, 13 Jul 2019 18:03:35 +0300 Message-Id: <83wogmyo1k.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Pip Cet on Sat, 13 Jul 2019 14:37:25 +0000) References: <87muhks3b5.fsf@hochschule-trier.de> <83muhj2zmb.fsf@gnu.org> <83ims72xcj.fsf@gnu.org> <83a7dj2sz9.fsf@gnu.org> <835zo72jmr.fsf@gnu.org> <834l3r2jbe.fsf@gnu.org> <8336jb2fhq.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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: Pip Cet > Date: Sat, 13 Jul 2019 14:37:25 +0000 > Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de > > Well, I think we're going to have to do one or more of the following: > > - have a race condition > - access glib-locked data from the "wrong" thread (another Emacs thread) > - release the glib lock from the "wrong" thread (another Emacs thread) > > Of these, the second is the best alternative, I think: we simply grab > the g_main_context lock globally, acting for all Emacs threads, and > the last thread to require it releases it when it leaves xg_select. I agree. > As long as there's at least one thread in the critical section of > xg_select, we hold the lock, but access to the context isn't > necessarily from the thread which locked it. Hmm... wouldn't this cause us always hold that lock when there's more than one Lisp thread? And if so, what will that do to GTK and its own threads, which also want to acquire the Glib context? IOW, I guess I don't understand what problem would the proposed changes solve that the current code doesn't. Can you tell? > > Hmm... how would this work with your patch? Suppose one thread calls > > xg_select, acquires the Glib lock, sets its holding_glib_lock flag, > > then releases the global Lisp lock and calls pselect. Since the > > global Lisp lock is now up for grabs, some other Lisp thread can > > acquire it and start running. > > And when it starts running, it releases the Glib lock. But only if its holding_glib_lock flag is set, which is not necessarily true. For example, what about a thread that was just created, and never called xg_select yet? > Okay, that sounds like option #2 above. The attached patch exposes > glib externals to the generic code, but it appears to work. If you > think the approach is okay, I'll move the glib-specific parts to > xgselect.c (if that's okay). Yes, we should have accessor functions in xgselect.c instead of letting thread.c etc. access the GTK/Glib data directly. But I still would like to understand why we need to maintain a flag per thread. Also, I think I lost the context: does this attempt to solve the original problem reported by Andreas, or only the problem reported by you later in the discussion? Thanks. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Andreas Politz Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Jul 2019 15:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: Eli Zaretskii , 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156303026721930 (code B ref 36609); Sat, 13 Jul 2019 15:05:02 +0000 Received: (at 36609) by debbugs.gnu.org; 13 Jul 2019 15:04:27 +0000 Received: from localhost ([127.0.0.1]:43099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmJZa-0005hd-Vv for submit@debbugs.gnu.org; Sat, 13 Jul 2019 11:04:27 -0400 Received: from gateway-a.fh-trier.de ([143.93.54.181]:41619) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmJZZ-0005hW-KQ for 36609@debbugs.gnu.org; Sat, 13 Jul 2019 11:04:26 -0400 X-Virus-Scanned: by Amavisd-new + Sophos + ClamAV [Rechenzentrum Hochschule Trier (RZ/HT)] Received: from localhost (x4dbd379a.dyn.telefonica.de [77.189.55.154]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: politza) by gateway-a.fh-trier.de (Postfix) with ESMTPSA id B57B0186C482; Sat, 13 Jul 2019 17:04:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=hochschule-trier.de; s=default; t=1563030263; bh=s7ry+QO/HWcP6ovjmQNkhxDKcdc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=NBTkPIhqmNb3tgs4WulsQX2xgcGALQXpO4HiCiA1uYEQWVCvpElnrv6GBtw+QA6QW M7E4eLb2Xnf+o6LS/03AIHCnutz7XFbKLFQkrLjp4siQhzVGyNx/ZY1cQycT/FYPFu jIWFGnMvUF5oIrQbHCHV415/XjqXFmdsXkzK8klo= From: Andreas Politz References: <87muhks3b5.fsf@hochschule-trier.de> <83muhj2zmb.fsf@gnu.org> <83ims72xcj.fsf@gnu.org> <83a7dj2sz9.fsf@gnu.org> <835zo72jmr.fsf@gnu.org> <834l3r2jbe.fsf@gnu.org> <8336jb2fhq.fsf@gnu.org> Date: Sat, 13 Jul 2019 17:04:23 +0200 In-Reply-To: (Pip Cet's message of "Sat, 13 Jul 2019 14:37:25 +0000") Message-ID: <87k1cm2cy0.fsf@hochschule-trier.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) 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 (---) I ran my problematic code a couple thousand times on this patch without freezes, while producing the expected results. Thanks for figuring this out. Andreas From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Jul 2019 15:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: pipcet@gmail.com Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156303083122922 (code B ref 36609); Sat, 13 Jul 2019 15:14:02 +0000 Received: (at 36609) by debbugs.gnu.org; 13 Jul 2019 15:13:51 +0000 Received: from localhost ([127.0.0.1]:43124 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmJig-0005xa-Jk for submit@debbugs.gnu.org; Sat, 13 Jul 2019 11:13:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44133) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmJie-0005x8-Kc for 36609@debbugs.gnu.org; Sat, 13 Jul 2019 11:13:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36445) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hmJiY-0000na-I9; Sat, 13 Jul 2019 11:13:42 -0400 Received: from [176.228.60.248] (port=4137 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hmJiX-0002TH-Sp; Sat, 13 Jul 2019 11:13:42 -0400 Date: Sat, 13 Jul 2019 18:13:30 +0300 Message-Id: <83v9w6ynl1.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <83wogmyo1k.fsf@gnu.org> (message from Eli Zaretskii on Sat, 13 Jul 2019 18:03:35 +0300) References: <87muhks3b5.fsf@hochschule-trier.de> <83muhj2zmb.fsf@gnu.org> <83ims72xcj.fsf@gnu.org> <83a7dj2sz9.fsf@gnu.org> <835zo72jmr.fsf@gnu.org> <834l3r2jbe.fsf@gnu.org> <8336jb2fhq.fsf@gnu.org> <83wogmyo1k.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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 (---) > Date: Sat, 13 Jul 2019 18:03:35 +0300 > From: Eli Zaretskii > Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de > > Also, I think I lost the context: does this attempt to solve the > original problem reported by Andreas, or only the problem reported by > you later in the discussion? I guess Andreas just answered this question. Thanks. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Jul 2019 15:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: pipcet@gmail.com Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156303330119811 (code B ref 36609); Sat, 13 Jul 2019 15:55:02 +0000 Received: (at 36609) by debbugs.gnu.org; 13 Jul 2019 15:55:01 +0000 Received: from localhost ([127.0.0.1]:43220 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmKMX-00059T-7M for submit@debbugs.gnu.org; Sat, 13 Jul 2019 11:55:01 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56583) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmKMU-00059D-QT for 36609@debbugs.gnu.org; Sat, 13 Jul 2019 11:54:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37210) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hmKMP-0005Uz-2x; Sat, 13 Jul 2019 11:54:53 -0400 Received: from [176.228.60.248] (port=2649 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hmKMO-0004bG-Fn; Sat, 13 Jul 2019 11:54:52 -0400 Date: Sat, 13 Jul 2019 18:54:40 +0300 Message-Id: <83sgraylof.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <83wogmyo1k.fsf@gnu.org> (message from Eli Zaretskii on Sat, 13 Jul 2019 18:03:35 +0300) References: <87muhks3b5.fsf@hochschule-trier.de> <83muhj2zmb.fsf@gnu.org> <83ims72xcj.fsf@gnu.org> <83a7dj2sz9.fsf@gnu.org> <835zo72jmr.fsf@gnu.org> <834l3r2jbe.fsf@gnu.org> <8336jb2fhq.fsf@gnu.org> <83wogmyo1k.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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 (---) > Date: Sat, 13 Jul 2019 18:03:35 +0300 > From: Eli Zaretskii > Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de > > But I still would like to understand why we need to maintain a flag > per thread. Specifically, why not make this flag thread-independent, and have any thread release the context lock if that variable is non-zero? I don't think it matters which thread locked the Glib context, we just need to release it once we emerge from thread_select, and do it before we might call Fsignal. That the lock might be released by a thread other than the one which locked it shouldn't matter, I think, as long as we consider all the Lisp threads acting together on behalf of Emacs. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Jul 2019 15:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156303348120132 (code B ref 36609); Sat, 13 Jul 2019 15:58:02 +0000 Received: (at 36609) by debbugs.gnu.org; 13 Jul 2019 15:58:01 +0000 Received: from localhost ([127.0.0.1]:43229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmKPR-0005EZ-AB for submit@debbugs.gnu.org; Sat, 13 Jul 2019 11:58:01 -0400 Received: from mail-ot1-f54.google.com ([209.85.210.54]:46479) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmKPP-0005EK-Kr for 36609@debbugs.gnu.org; Sat, 13 Jul 2019 11:58:00 -0400 Received: by mail-ot1-f54.google.com with SMTP id z23so12465499ote.13 for <36609@debbugs.gnu.org>; Sat, 13 Jul 2019 08:57:59 -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=gx2dwGDHTSKy1W7N9Zf+G+Rm++uSMVXOmjVEVpjKRbU=; b=F9xdfU6Wz+RVxMM2o6DEc64ARH94mh66tKRihBNPLo8grJa6INVNU11PHR8yF1fRMd 3edPTtBv/OuYlQxbfBYfwKwjOg421JCL7QQyzlkXSqhb/B9tjTdwHZ4lTuYtZddNqG+A sAAG7RDiTQGzETdjpYg/1hmWeo2rp7A9VWX+IOBvZgb3b1kUoPWmnh4aRQuq9YsNLJJ7 aXAWdcpyM5cM+LQdx4wz8w3B26J72RGhfyuNm+D4iyK3Q5Jt3hv8oAfcMR+XZaMQQV9O UJidxYkTeLFLtVti/v301vYm3rF3hrfEXp27Y/gjH1rDi+CuIH3Gb1k8dmqD1ti4+msr hLXw== 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=gx2dwGDHTSKy1W7N9Zf+G+Rm++uSMVXOmjVEVpjKRbU=; b=mTmrg1iEsWx6YruRO7/iX6OKGjfssQrNdWP/s2uu6OEEKMTi0PK/iXW1VnUDJwvL6Q HNO77itg1wlBDlrGOEo9o2vOC38RC9/IACw3xpDrAAAYKYRgEWferxfQCICCNZtAWaMN XelQHf+XehTej35sIJxW8yWcL6q9H0a9pBBpmxnmq5icRI7lSngExUTEVQ4N9CJIbB6E m1rFTNjb7FlZzoFzTfyNULwTzL3jnku3RIJsxspH2dvJHElp+zcy9+3eOXLDIdYIo8Sx 25vjkeh75ibvrvtzrmL7EYzNSEk/NjU9HbdBX1rGs4tDBuoobpQ3LkBnKIsCpA6W3doo VyvA== X-Gm-Message-State: APjAAAUAovj0JND+DoXqvR4a/F3u+fMdJH24wmjy4mco1Ry4h6L4jSEu bYFdREOHxg/zJcF3sH1ySFSkVLQOuBkiDHcF3/Q= X-Google-Smtp-Source: APXvYqwEzJUmkMpyLWKE3r4qn67hr+QfRe8W2Hc0i8dZDwKN4UxV0pd3bpP44gISge+y0OqevRjwmWvYC7BT0Ev8nuY= X-Received: by 2002:a9d:664c:: with SMTP id q12mr8278598otm.175.1563033473979; Sat, 13 Jul 2019 08:57:53 -0700 (PDT) MIME-Version: 1.0 References: <87muhks3b5.fsf@hochschule-trier.de> <83muhj2zmb.fsf@gnu.org> <83ims72xcj.fsf@gnu.org> <83a7dj2sz9.fsf@gnu.org> <835zo72jmr.fsf@gnu.org> <834l3r2jbe.fsf@gnu.org> <8336jb2fhq.fsf@gnu.org> <83wogmyo1k.fsf@gnu.org> <83sgraylof.fsf@gnu.org> In-Reply-To: <83sgraylof.fsf@gnu.org> From: Pip Cet Date: Sat, 13 Jul 2019 15:57:17 +0000 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) 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 Sat, Jul 13, 2019 at 3:54 PM Eli Zaretskii wrote: > > But I still would like to understand why we need to maintain a flag > > per thread. We don't. I had originally planned to make reacquiring the lock fail gracefully if we can't spin-lock, but that didn't make it into the patch, so it should be simplified as you suggest. > Specifically, why not make this flag thread-independent, and have any > thread release the context lock if that variable is non-zero? I don't > think it matters which thread locked the Glib context, we just need to > release it once we emerge from thread_select, and do it before we > might call Fsignal. That the lock might be released by a thread other > than the one which locked it shouldn't matter, I think, as long as we > consider all the Lisp threads acting together on behalf of Emacs. I agree entirely. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Jul 2019 16:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156303378528942 (code B ref 36609); Sat, 13 Jul 2019 16:04:02 +0000 Received: (at 36609) by debbugs.gnu.org; 13 Jul 2019 16:03:05 +0000 Received: from localhost ([127.0.0.1]:43235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmKUL-0007Wk-50 for submit@debbugs.gnu.org; Sat, 13 Jul 2019 12:03:05 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58966) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmKUJ-0007WG-7h for 36609@debbugs.gnu.org; Sat, 13 Jul 2019 12:03:03 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37388) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hmKU8-0005q2-Cj; Sat, 13 Jul 2019 12:02:52 -0400 Received: from [176.228.60.248] (port=3142 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hmKU6-00041L-9R; Sat, 13 Jul 2019 12:02:52 -0400 Date: Sat, 13 Jul 2019 19:02:37 +0300 Message-Id: <83r26tzzvm.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Pip Cet on Sat, 13 Jul 2019 15:57:17 +0000) References: <87muhks3b5.fsf@hochschule-trier.de> <83muhj2zmb.fsf@gnu.org> <83ims72xcj.fsf@gnu.org> <83a7dj2sz9.fsf@gnu.org> <835zo72jmr.fsf@gnu.org> <834l3r2jbe.fsf@gnu.org> <8336jb2fhq.fsf@gnu.org> <83wogmyo1k.fsf@gnu.org> <83sgraylof.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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: Pip Cet > Date: Sat, 13 Jul 2019 15:57:17 +0000 > Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de > > > Specifically, why not make this flag thread-independent, and have any > > thread release the context lock if that variable is non-zero? I don't > > think it matters which thread locked the Glib context, we just need to > > release it once we emerge from thread_select, and do it before we > > might call Fsignal. That the lock might be released by a thread other > > than the one which locked it shouldn't matter, I think, as long as we > > consider all the Lisp threads acting together on behalf of Emacs. > > I agree entirely. Great, then I think we are in agreement. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Jul 2019 18:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156304190926086 (code B ref 36609); Sat, 13 Jul 2019 18:19:01 +0000 Received: (at 36609) by debbugs.gnu.org; 13 Jul 2019 18:18:29 +0000 Received: from localhost ([127.0.0.1]:43368 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmMbM-0006mf-Vt for submit@debbugs.gnu.org; Sat, 13 Jul 2019 14:18:29 -0400 Received: from mail-oi1-f177.google.com ([209.85.167.177]:41749) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmMbH-0006mL-B6 for 36609@debbugs.gnu.org; Sat, 13 Jul 2019 14:18:23 -0400 Received: by mail-oi1-f177.google.com with SMTP id g7so9725565oia.8 for <36609@debbugs.gnu.org>; Sat, 13 Jul 2019 11:18:23 -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=mzZkaJHW5nmlIWExZb8uKEaZ798kWzs9JJmSzRAb3CA=; b=XotH7si4/rukADUozTeYizxEwg0IJWVBUJtkB5BH7+AiMbICtsVWKuo3NXht5GzESK +pRh3g024mX58Xa0rML5tqc6kjcqCmH07bTiJa1xAi9xLyoY+bqiJQhqstfJqvqHgiPa y2TkyUZRQxjc9KkKF7extT/tudh06akbdsP3TTnC30jCUOe0rYaTRb7o/j1iF/BTaSQd LUNi+N4aXU6niCp/72JcMkB9SHnrqSRRhobUsNVtrefnK70iIPdBHufdk4vM9kP5EUCX ArAlevXWUzWRF6kNMDjY/3T+bycnGEZ+2zSjxzjZ8EI7+zU+/ubm0RGfnWbqoVv7DIv6 jfng== 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=mzZkaJHW5nmlIWExZb8uKEaZ798kWzs9JJmSzRAb3CA=; b=Uih8gCaqOYuKuGlYEe03f1kwVHTjurA3fGwK9mjAcH27eMH9UN0G3qY8dBrH5mLh+Q wzALRRpezTk5uZ0j1ktchEy7Kxwodsx0c48sYaP1enmgaLddnzgAcTD+vzzgGx5cfHmv SiTbkWPDhtilpzv3Qw6yzI7UrazQ7iUiwi+ERQ6CjMkOOrXAB/Ap3MSlIdSGyeZE57r3 EAEZ4Jasm0B3EpZqpPq/rkr4Qfkhuq/eBEYjPiceuOg6gV+0Adtm6Qy1RjErLu3I2QA7 o7lzkKhbb44qransHmIQ23GU/ACwqe/KqenP69lhF9Lakhml+j6VcOkpqfo7nFvJxY9z t6xw== X-Gm-Message-State: APjAAAWwdK/dISn0BuJ1SSVP2k/gYcEkdfOfF4psRaUNcetvIuX2qeSn J8M32FHSgkpcKISgpGkIEPHcmlicemBmoESBphQ= X-Google-Smtp-Source: APXvYqxNcbYc4E5h+fZJvy5tsNR1OHiUVj+lskARB2mIQ5rXi55Duk5vMxEPEKn0icOt9l/rnk3WV1SypecJ/Xo51eg= X-Received: by 2002:aca:aa93:: with SMTP id t141mr9177172oie.128.1563041897631; Sat, 13 Jul 2019 11:18:17 -0700 (PDT) MIME-Version: 1.0 References: <87muhks3b5.fsf@hochschule-trier.de> <83muhj2zmb.fsf@gnu.org> <83ims72xcj.fsf@gnu.org> <83a7dj2sz9.fsf@gnu.org> <835zo72jmr.fsf@gnu.org> <834l3r2jbe.fsf@gnu.org> <8336jb2fhq.fsf@gnu.org> <83wogmyo1k.fsf@gnu.org> <83sgraylof.fsf@gnu.org> <83r26tzzvm.fsf@gnu.org> In-Reply-To: <83r26tzzvm.fsf@gnu.org> From: Pip Cet Date: Sat, 13 Jul 2019 18:17:41 +0000 Message-ID: Content-Type: multipart/mixed; boundary="000000000000147891058d940dfa" X-Spam-Score: 0.0 (/) 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 (-) --000000000000147891058d940dfa Content-Type: text/plain; charset="UTF-8" Patch attached. It's possible this'll livelock certain glib libraries that want to modify the glib main context while another thread is running. I don't see a good way to fix that, but a bad way would be to apply some heuristic (such as a 10 ms delay between calling select() and assuming it actually was called). --000000000000147891058d940dfa Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Fix-lock-failures-in-xg_select-bug-36609.patch" Content-Disposition: attachment; filename="0001-Fix-lock-failures-in-xg_select-bug-36609.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jy1uq3dr0 RnJvbSBkOTkyMjJiMWNmNWI2M2U4MzYxZTlhN2NkYmUxM2ZhYWZiNDBjMWQ1IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaXAgQ2V0IDxwaXBjZXRAZ21haWwuY29tPgpEYXRlOiBTYXQs IDEzIEp1bCAyMDE5IDE4OjA5OjM4ICswMDAwClN1YmplY3Q6IFtQQVRDSF0gRml4IGxvY2sgZmFp bHVyZXMgaW4geGdfc2VsZWN0IChidWcjMzY2MDkpCgoqIHNyYy94Z3NlbGVjdC5jIChyZWxlYXNl X3NlbGVjdF9sb2NrLCBhY3F1aXJlX3NlbGVjdF9sb2NrKToKSW50cm9kdWNlLgooeGdfc2VsZWN0 KTogVXNlIGBhY3F1aXJlX3NlbGVjdF9sb2NrJywgYHJlbGVhc2Vfc2VsZWN0X2xvY2snLgoqIHNy Yy90aHJlYWQuYyAocmVsZWFzZV9zZWxlY3RfbG9jayk6IEludHJvZHVjZSBmb3Igbm9uLUdMaWIg YnVpbGRzLgoocmVhbGx5X2NhbGxfc2VsZWN0KTogQ2FsbCBgcmVsZWFzZV9zZWxlY3RfbG9jaycu ICBTaW1wbGlmeSBieQplbnN1cmluZyBhY3F1aXNpdGlvbiBvZiB0aGUgbG9jayBhbHdheXMgc3Vj Y2VlZHMuCi0tLQogc3JjL3RocmVhZC5jICAgfCAgOCArKysrKysrKwogc3JjL3hnc2VsZWN0LmMg fCA0MiArKysrKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0KIHNyYy94Z3Nl bGVjdC5oIHwgIDIgKysKIDMgZmlsZXMgY2hhbmdlZCwgMzggaW5zZXJ0aW9ucygrKSwgMTQgZGVs ZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvc3JjL3RocmVhZC5jIGIvc3JjL3RocmVhZC5jCmluZGV4 IGUyZGVhZGQ3YTguLjQwYTI1ZmI1Y2QgMTAwNjQ0Ci0tLSBhL3NyYy90aHJlYWQuYworKysgYi9z cmMvdGhyZWFkLmMKQEAgLTI4LDYgKzI4LDEyIEBAIENvcHlyaWdodCAoQykgMjAxMi0yMDE5IEZy ZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLgogI2luY2x1ZGUgInBkdW1wZXIuaCIKICNpbmNs dWRlICJrZXlib2FyZC5oIgogCisjaWZkZWYgSEFWRV9HTElCCisjaW5jbHVkZSA8eGdzZWxlY3Qu aD4KKyNlbHNlCisjZGVmaW5lIHJlbGVhc2Vfc2VsZWN0X2xvY2soKSBkbyB7IH0gd2hpbGUgKDAp CisjZW5kaWYKKwogdW5pb24gYWxpZ25lZF90aHJlYWRfc3RhdGUKIHsKICAgc3RydWN0IHRocmVh ZF9zdGF0ZSBzOwpAQCAtNTg2LDYgKzU5Miw4IEBAIHJlYWxseV9jYWxsX3NlbGVjdCAodm9pZCAq YXJnKQogICBzYS0+cmVzdWx0ID0gKHNhLT5mdW5jKSAoc2EtPm1heF9mZHMsIHNhLT5yZmRzLCBz YS0+d2Zkcywgc2EtPmVmZHMsCiAJCQkgICBzYS0+dGltZW91dCwgc2EtPnNpZ21hc2spOwogCisg IHJlbGVhc2Vfc2VsZWN0X2xvY2sgKCk7CisKICAgYmxvY2tfaW50ZXJydXB0X3NpZ25hbCAoJm9s ZHNldCk7CiAgIC8qIElmIHdlIHdlcmUgaW50ZXJydXB0ZWQgYnkgQy1nIHdoaWxlIGluc2lkZSBz YS0+ZnVuYyBhYm92ZSwgdGhlCiAgICAgIHNpZ25hbCBoYW5kbGVyIGNvdWxkIGhhdmUgY2FsbGVk IG1heWJlX3JlYWNxdWlyZV9nbG9iYWxfbG9jaywgaW4KZGlmZiAtLWdpdCBhL3NyYy94Z3NlbGVj dC5jIGIvc3JjL3hnc2VsZWN0LmMKaW5kZXggOTk4MmExZjBlOS4uODJmMGE2MTg4MiAxMDA2NDQK LS0tIGEvc3JjL3hnc2VsZWN0LmMKKysrIGIvc3JjL3hnc2VsZWN0LmMKQEAgLTI5LDYgKzI5LDI3 IEBAIENvcHlyaWdodCAoQykgMjAwOS0yMDE5IEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5j LgogI2luY2x1ZGUgImJsb2NraW5wdXQuaCIKICNpbmNsdWRlICJzeXN0aW1lLmgiCiAKK3N0YXRp YyBwdHJkaWZmX3QgdGhyZWFkc19ob2xkaW5nX2dsaWJfbG9jazsKK3N0YXRpYyBHTWFpbkNvbnRl eHQgKmdsaWJfbWFpbl9jb250ZXh0OworCit2b2lkIHJlbGVhc2Vfc2VsZWN0X2xvY2sgKHZvaWQp Cit7CisgIGlmICgtLXRocmVhZHNfaG9sZGluZ19nbGliX2xvY2sgPT0gMCkKKyAgICBnX21haW5f Y29udGV4dF9yZWxlYXNlIChnbGliX21haW5fY29udGV4dCk7Cit9CisKK3N0YXRpYyB2b2lkIGFj cXVpcmVfc2VsZWN0X2xvY2sgKEdNYWluQ29udGV4dCAqY29udGV4dCkKK3sKKyAgaWYgKHRocmVh ZHNfaG9sZGluZ19nbGliX2xvY2srKyA9PSAwKQorICAgIHsKKyAgICAgIGdsaWJfbWFpbl9jb250 ZXh0ID0gY29udGV4dDsKKyAgICAgIHdoaWxlICghZ19tYWluX2NvbnRleHRfYWNxdWlyZSAoY29u dGV4dCkpCisJeworCSAgLyogU3Bpbi4gKi8KKwl9CisgICAgfQorfQorCiAvKiBgeGdfc2VsZWN0 JyBpcyBhIGBwc2VsZWN0JyByZXBsYWNlbWVudC4gIFdoeSBkbyB3ZSBuZWVkIGEgc2VwYXJhdGUg ZnVuY3Rpb24/CiAgICAxLiBUaW1lb3V0cy4gIEdsaWIgYW5kIEd0ayByZWx5IG9uIHRpbWVyIGV2 ZW50cy4gIElmIHdlIGRpZCBwc2VsZWN0CiAgICAgICB3aXRoIGEgZ3JlYXRlciB0aW1lb3V0IHRo ZW4gdGhlIG9uZSBzY2hlZHVsZWQgYnkgR2xpYiwgd2Ugd291bGQKQEAgLTU0LDI2ICs3NSwxOSBA QCB4Z19zZWxlY3QgKGludCBmZHNfbGltLCBmZF9zZXQgKnJmZHMsIGZkX3NldCAqd2ZkcywgZmRf c2V0ICplZmRzLAogICBHUG9sbEZEICpnZmRzID0gZ2Zkc19idWY7CiAgIGludCBnZmRzX3NpemUg PSBBUlJBWUVMVFMgKGdmZHNfYnVmKTsKICAgaW50IG5fZ2ZkcywgcmV0dmFsID0gMCwgb3VyX2Zk cyA9IDAsIG1heF9mZHMgPSBmZHNfbGltIC0gMTsKLSAgYm9vbCBjb250ZXh0X2FjcXVpcmVkID0g ZmFsc2U7CiAgIGludCBpLCBuZmRzLCB0bW9faW5fbWlsbGlzZWMsIG11c3RfZnJlZSA9IDA7CiAg IGJvb2wgbmVlZF90b19kaXNwYXRjaDsKIAogICBjb250ZXh0ID0gZ19tYWluX2NvbnRleHRfZGVm YXVsdCAoKTsKLSAgY29udGV4dF9hY3F1aXJlZCA9IGdfbWFpbl9jb250ZXh0X2FjcXVpcmUgKGNv bnRleHQpOwotICAvKiBGSVhNRTogSWYgd2UgY291bGRuJ3QgYWNxdWlyZSB0aGUgY29udGV4dCwg d2UganVzdCBzaWxlbnRseSBwcm9jZWVkCi0gICAgIGJlY2F1c2UgdGhpcyBmdW5jdGlvbiBoYW5k bGVzIG1vcmUgdGhhbiBqdXN0IGdsaWIgZmlsZSBkZXNjcmlwdG9ycy4KLSAgICAgTm90ZSB0aGF0 LCBhcyBpbXBsZW1lbnRlZCwgdGhpcyBmYWlsdXJlIGlzIGNvbXBsZXRlbHkgc2lsZW50OiB0aGVy ZSBpcwotICAgICBubyBmZWVkYmFjayB0byB0aGUgY2FsbGVyLiAgKi8KKyAgYWNxdWlyZV9zZWxl Y3RfbG9jayAoY29udGV4dCk7CiAKICAgaWYgKHJmZHMpIGFsbF9yZmRzID0gKnJmZHM7CiAgIGVs c2UgRkRfWkVSTyAoJmFsbF9yZmRzKTsKICAgaWYgKHdmZHMpIGFsbF93ZmRzID0gKndmZHM7CiAg IGVsc2UgRkRfWkVSTyAoJmFsbF93ZmRzKTsKIAotICBuX2dmZHMgPSAoY29udGV4dF9hY3F1aXJl ZAotCSAgICA/IGdfbWFpbl9jb250ZXh0X3F1ZXJ5IChjb250ZXh0LCBHX1BSSU9SSVRZX0xPVywg JnRtb19pbl9taWxsaXNlYywKLQkJCQkgICAgZ2ZkcywgZ2Zkc19zaXplKQotCSAgICA6IC0xKTsK KyAgbl9nZmRzID0gZ19tYWluX2NvbnRleHRfcXVlcnkgKGNvbnRleHQsIEdfUFJJT1JJVFlfTE9X LCAmdG1vX2luX21pbGxpc2VjLAorCQkJCSBnZmRzLCBnZmRzX3NpemUpOwogCiAgIGlmIChnZmRz X3NpemUgPCBuX2dmZHMpCiAgICAgewpAQCAtMTUxLDggKzE2NSwxMCBAQCB4Z19zZWxlY3QgKGlu dCBmZHNfbGltLCBmZF9zZXQgKnJmZHMsIGZkX3NldCAqd2ZkcywgZmRfc2V0ICplZmRzLAogI2Vs c2UKICAgbmVlZF90b19kaXNwYXRjaCA9IHRydWU7CiAjZW5kaWYKLSAgaWYgKG5lZWRfdG9fZGlz cGF0Y2ggJiYgY29udGV4dF9hY3F1aXJlZCkKKyAgaWYgKG5lZWRfdG9fZGlzcGF0Y2gpCiAgICAg eworICAgICAgYWNxdWlyZV9zZWxlY3RfbG9jayAoY29udGV4dCk7CisKICAgICAgIGludCBwc2Vs ZWN0X2Vycm5vID0gZXJybm87CiAgICAgICAvKiBQcmV2ZW50IGdfbWFpbl9kaXNwYXRjaCByZWN1 cnNpb24sIHRoYXQgd291bGQgb2NjdXIgd2l0aG91dAogICAgICAgICAgYmxvY2tfaW5wdXQgd3Jh cHBlciwgYmVjYXVzZSBldmVudCBoYW5kbGVycyBjYWxsCkBAIC0xNjIsMTEgKzE3OCw5IEBAIHhn X3NlbGVjdCAoaW50IGZkc19saW0sIGZkX3NldCAqcmZkcywgZmRfc2V0ICp3ZmRzLCBmZF9zZXQg KmVmZHMsCiAgICAgICAgIGdfbWFpbl9jb250ZXh0X2Rpc3BhdGNoIChjb250ZXh0KTsKICAgICAg IHVuYmxvY2tfaW5wdXQgKCk7CiAgICAgICBlcnJubyA9IHBzZWxlY3RfZXJybm87CisgICAgICBy ZWxlYXNlX3NlbGVjdF9sb2NrICgpOwogICAgIH0KIAotICBpZiAoY29udGV4dF9hY3F1aXJlZCkK LSAgICBnX21haW5fY29udGV4dF9yZWxlYXNlIChjb250ZXh0KTsKLQogICAvKiBUbyBub3QgaGF2 ZSB0byByZWNhbGN1bGF0ZSB0aW1lb3V0LCByZXR1cm4gbGlrZSB0aGlzLiAgKi8KICAgaWYgKChv dXJfZmRzID4gMCB8fCAobmZkcyA9PSAwICYmIHRtb3AgPT0gJnRtbykpICYmIChyZXR2YWwgPT0g MCkpCiAgICAgewpkaWZmIC0tZ2l0IGEvc3JjL3hnc2VsZWN0LmggYi9zcmMveGdzZWxlY3QuaApp bmRleCA5MmM3OWM1ZjY0Li4wZDVjOTZjZDIxIDEwMDY0NAotLS0gYS9zcmMveGdzZWxlY3QuaAor KysgYi9zcmMveGdzZWxlY3QuaApAQCAtMjksNCArMjksNiBAQCAjZGVmaW5lIFhHU0VMRUNUX0gK IAkJICAgICAgZmRfc2V0ICpyZmRzLCBmZF9zZXQgKndmZHMsIGZkX3NldCAqZWZkcywKIAkJICAg ICAgc3RydWN0IHRpbWVzcGVjICp0aW1lb3V0LCBzaWdzZXRfdCAqc2lnbWFzayk7CiAKK2V4dGVy biB2b2lkIHJlbGVhc2Vfc2VsZWN0X2xvY2sgKHZvaWQpOworCiAjZW5kaWYgLyogWEdTRUxFQ1Rf SCAqLwotLSAKMi4yMC4xCgo= --000000000000147891058d940dfa-- From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Aug 2020 12:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: Eli Zaretskii , 36609@debbugs.gnu.org, politza@hochschule-trier.de Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.15980146628695 (code B ref 36609); Fri, 21 Aug 2020 12:58:01 +0000 Received: (at 36609) by debbugs.gnu.org; 21 Aug 2020 12:57:42 +0000 Received: from localhost ([127.0.0.1]:45366 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k96c1-0002GB-VR for submit@debbugs.gnu.org; Fri, 21 Aug 2020 08:57:42 -0400 Received: from quimby.gnus.org ([95.216.78.240]:42260) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k96bz-0002Fu-UN for 36609@debbugs.gnu.org; Fri, 21 Aug 2020 08:57:40 -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=AJf+no//z+rCxMapo96qn4Plo3WH7jMdAvt3RrT3jTo=; b=PScV1AO2vk1uFj4xLhYQkOVxie LywRJnxBGkAHbumAGhJ1N1d8lGSU7wQvEvoYJyKUynBQZWDI/46P/+3PYlWmUmy00v3LtxxhjMhg5 bjN9u/rYsAou+ZzvtAefgO1oavhQetyPGvJMqBiz0792WBkhfAQdHLYk5fT3zE9K6t/o=; 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 1k96br-0003sc-5Z; Fri, 21 Aug 2020 14:57:33 +0200 From: Lars Ingebrigtsen References: <87muhks3b5.fsf@hochschule-trier.de> <83muhj2zmb.fsf@gnu.org> <83ims72xcj.fsf@gnu.org> <83a7dj2sz9.fsf@gnu.org> <835zo72jmr.fsf@gnu.org> <834l3r2jbe.fsf@gnu.org> <8336jb2fhq.fsf@gnu.org> <83wogmyo1k.fsf@gnu.org> <83sgraylof.fsf@gnu.org> <83r26tzzvm.fsf@gnu.org> X-Now-Playing: The Raincoats's _The Raincoats_: "You're a Million" Date: Fri, 21 Aug 2020 14:57:29 +0200 In-Reply-To: (Pip Cet's message of "Sat, 13 Jul 2019 18:17:41 +0000") Message-ID: <874kow5f7q.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: > Patch attached. > > It's possible this'll livelock certain glib libraries that want to > modify the glib main context while another thread is running. I don't > see a good way to fix that, but a bad [...] 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-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: > Patch attached. > > It's possible this'll livelock certain glib libraries that want to > modify the glib main context while another thread is running. I don't > see a good way to fix that, but a bad way would be to apply some > heuristic (such as a 10 ms delay between calling select() and assuming > it actually was called). Skimming this thread, it seems that Eli was in agreement with applying it, and Andreas has tried it extensively and it fixes the problem, so I've applied it to Emacs 28 now. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 21 08:57:49 2020 Received: (at control) by debbugs.gnu.org; 21 Aug 2020 12:57:49 +0000 Received: from localhost ([127.0.0.1]:45369 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k96c9-0002GX-5q for submit@debbugs.gnu.org; Fri, 21 Aug 2020 08:57:49 -0400 Received: from quimby.gnus.org ([95.216.78.240]:42278) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k96c6-0002GA-Jd for control@debbugs.gnu.org; Fri, 21 Aug 2020 08:57:47 -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=qH7NnleGgudjM3gn8SgLCJTdarewz5afY3b/ZMyaClo=; b=Ft2G/neGfoswwtpDEfeykT08tE EIdQOYUK2+yPobf4DcuyuI0i0lgMQt3chc95jJgQ0jKPkCMeh6Gs42WZNs5T3dlnduwdeBHEnavXo E+wuHZpqWvk+o34fpxzQ0yM9o/JkMBGai9VHEpO7Kg6VsjpUrEhG7V8u/3fKag8bO5gM=; 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 1k96by-0003so-O3 for control@debbugs.gnu.org; Fri, 21 Aug 2020 14:57:41 +0200 Date: Fri, 21 Aug 2020 14:57:37 +0200 Message-Id: <87364g5f7i.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #36609 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: tags 36609 fixed close 36609 28.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: 0.0 (/) 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: -1.0 (-) tags 36609 fixed close 36609 28.1 quit From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 06 11:42:22 2021 Received: (at control) by debbugs.gnu.org; 6 Jun 2021 15:42:22 +0000 Received: from localhost ([127.0.0.1]:53729 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpuus-0004CW-Bt for submit@debbugs.gnu.org; Sun, 06 Jun 2021 11:42:22 -0400 Received: from mail-qk1-f177.google.com ([209.85.222.177]:43822) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpuup-0004CI-9n for control@debbugs.gnu.org; Sun, 06 Jun 2021 11:42:21 -0400 Received: by mail-qk1-f177.google.com with SMTP id j62so598564qke.10 for ; Sun, 06 Jun 2021 08:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:user-agent:mime-version; bh=2KNdblnkwOTmTxqTpXkZcFpJV9jG0GX02C0xFwFfK+o=; b=VBwWRoo/9+7z/9bn13C3v07joo0lUDQetdSN98aPZIQmEfWGXIx9ambWnYQQwKUQqw sBhB/NjpJUM7lbq835UdhXVX2kqn5iBKWN2OTt10xed/p2f2wZndptjDCh6f015BSjTy 1hyFKDvLgpyxEhoJz+5SIw7TuP/sWDD3gcfp1gkRzDuuDn++ePqaPNbMM7hXU0/eWVCp 8XA6QcNwIivXwM1S4nP99BuHUBB+jkPQYpwYLh8gcQc5HAV916aXsAOIMCbi22MyRS2P sze0OGZmg/XiNvP0+GDWxnb2gjBdj+kQgxt5ey+QAolzoBpPqWpAvpFSx/eqZISDgl7u oETg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :mime-version; bh=2KNdblnkwOTmTxqTpXkZcFpJV9jG0GX02C0xFwFfK+o=; b=REKBwNUbP9/e85rSS3ZTaB+hiV5xLnW7K/BPJ+BgZW8Hd2GIXyY/x044Q0/IvqbsiA nI1mhbnaxRdiI3iLzAINV95gWD6jb7nAv0gSzLVGj0Ns/rncwnSiM3KPL76eQB75T8pZ idgcsjwK2Iq3FAA1mvb6FqBaUcSA5S6ZJmjzzaZftzmW0VprILQrwygHMzaHN6CnrxS1 26MitR78MhHD52obvUdL+aH97s73wDNcw69XDc6IFWlZ05cGroNrDJnGHprEUAlayF06 SRUhn/18AW6Wf4CRaHXL4tVhxYi5s+zOe2B4qg3poDVVxCWyIxPkOlcVRRJwWQAsNnza eAXg== X-Gm-Message-State: AOAM531E6mKaCB7Yx9N9SudpkpLuInL9nDaoMM9Hwwoh2KP7O6TXQ44h L5mxm/G6z7Ur2oxuOOEmKbsEyOYAcH0= X-Google-Smtp-Source: ABdhPJxepQH9X6d6Ha3+Rcl8CUgunfv9IrS2KJfRtxmgl2+mQfjpAsqI2V56sPa80umE8JYVSRESIw== X-Received: by 2002:a05:620a:1249:: with SMTP id a9mr2682169qkl.114.1622994133534; Sun, 06 Jun 2021 08:42:13 -0700 (PDT) Received: from localhost (pool-71-190-212-171.nycmny.fios.verizon.net. [71.190.212.171]) by smtp.gmail.com with ESMTPSA id b6sm7223081qtg.1.2021.06.06.08.42.12 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sun, 06 Jun 2021 08:42:13 -0700 (PDT) From: dick.r.chiang@gmail.com To: control@debbugs.gnu.org Subject: Date: Sun, 06 Jun 2021 11:42:12 -0400 Message-ID: <87v96r3sq3.fsf@dick> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.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 the administrator of that system for details. Content preview: unarchive 36609 reopen 36609 Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dick.r.chiang[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.222.177 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.222.177 listed in wl.mailspike.net] 2.0 BLANK_SUBJECT Subject is present but empty 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: 1.0 (+) unarchive 36609 reopen 36609 From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: dick.r.chiang@gmail.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Jun 2021 15:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: Andreas Politz Cc: 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162299461525369 (code B ref 36609); Sun, 06 Jun 2021 15:51:01 +0000 Received: (at 36609) by debbugs.gnu.org; 6 Jun 2021 15:50:15 +0000 Received: from localhost ([127.0.0.1]:53742 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpv2U-0006b7-S2 for submit@debbugs.gnu.org; Sun, 06 Jun 2021 11:50:15 -0400 Received: from mail-qt1-f178.google.com ([209.85.160.178]:44813) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpv2T-0006ao-Jh for 36609@debbugs.gnu.org; Sun, 06 Jun 2021 11:50:14 -0400 Received: by mail-qt1-f178.google.com with SMTP id t17so10838033qta.11 for <36609@debbugs.gnu.org>; Sun, 06 Jun 2021 08:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=qocpl6/YCSHRbXI2SwuMZIljjMga9yV3hKgLIpnWUP0=; b=Lom9jLP0cWh4xJuNKna9qBob9ejVI7+xoSCe/VpmG1SBJ4l+/Qmn5fd4Jui9N2WdZB nFIkfopw3Mhr7d+JQ/EB37Prs0G57zjvizuXDVz21y7HtJHcHQKRgIcoGYI9V/XhqukN 5Gb3CPA+p9lJ2Pgy24f+CfeGnm26sYkIpRGaIf4i/XtMuc6zga0pHQsp1AGyPnNSe/VC lZu/MfGP0nEmKAdiJzm5AtwSp9X+ix9/Yikb3wz54/TVSN9x6DFVIamhDSaVSwDgW8M5 bmh+mRnkpEVV/S0ojIhOmfbxw1IyCGgZBL0vDGsFVSTlWLvt4dsG5Gdq0KIGxBv0ev/W oFaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=qocpl6/YCSHRbXI2SwuMZIljjMga9yV3hKgLIpnWUP0=; b=Oo7fK2C9QrqVtAQ2ps9lAEVRiqiIcFDBGMKwZN5EHBXpBnxO0zls1qUh3j65iUBmjF ELXyyFKtpOp47/qYfZ5KAsUGTAAN1IJu/hycfTQJU+DK5Q1sx0BoEqPjaAN1L46nkaNb gJfyRGWvEZhB4zeGB0u1YV5aSYBOHEtBy7HGu4HrnBg8EWdnYnsKlddA2bezP581umLy dKmYld+rHstXbKIIJ2nLgPZisZ6lGIiN4upoJyRFTfKQBJBRVY2IQOG1yab/F29LF1vZ BZi8cZYVOBwb24IdQBcPCq/jCUtu2GzZ2f7qFO4eZLqPXpEEfPcftUMyNdoXgZJrnkgR RJcQ== X-Gm-Message-State: AOAM532EnyigoQiEm6SgaeobSHj6bNCi8yF2s1mhriR+twu3AA3Ch4+b BBO0rqHiSpBCIMFR9gRo8N0= X-Google-Smtp-Source: ABdhPJwJmbvLBh+3CPJsZMpWHwDOm7ssnvbH/2hLKA2+FanZgecX8snhkCEohHkZU2sXDaathoDogg== X-Received: by 2002:a05:622a:14ca:: with SMTP id u10mr12743277qtx.280.1622994608031; Sun, 06 Jun 2021 08:50:08 -0700 (PDT) Received: from localhost (pool-71-190-212-171.nycmny.fios.verizon.net. [71.190.212.171]) by smtp.gmail.com with ESMTPSA id r4sm652269qtx.4.2021.06.06.08.50.07 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sun, 06 Jun 2021 08:50:07 -0700 (PDT) From: dick.r.chiang@gmail.com X-Google-Original-From: 36609@debbugs.gnu.org References: <87muhks3b5.fsf@hochschule-trier.de> Date: Sun, 06 Jun 2021 11:50:06 -0400 In-Reply-To: <87muhks3b5.fsf@hochschule-trier.de> (Andreas Politz's message of "Thu, 11 Jul 2019 22:51:10 +0200") Message-ID: <87k0n73scx.fsf@dick> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.0 (/) 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 (-) --=-=-= Content-Type: text/plain Four attachments: #1. Want to revert commit 9c62ffb --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-Revert-Fix-lock-failures-in-xg_select.patch >From 01b8b847f5fc4b65eaac06c7c2d85f8c5410c497 Mon Sep 17 00:00:00 2001 From: dickmao Date: Sun, 6 Jun 2021 11:10:13 -0400 Subject: [PATCH] Revert "Fix lock failures in xg_select" This reverts commit 9c62ffb08262c82b7e38e6eb5767f2087424aa47. * src/thread.c (really_call_select): revert 9c62ffb * src/xgselect.c (xg_select): revert 9c62ffb --- src/thread.c | 8 -------- src/xgselect.c | 42 ++++++++++++++---------------------------- src/xgselect.h | 2 -- 3 files changed, 14 insertions(+), 38 deletions(-) diff --git a/src/thread.c b/src/thread.c index f74f611148..609cd7c5fc 100644 --- a/src/thread.c +++ b/src/thread.c @@ -28,12 +28,6 @@ Copyright (C) 2012-2021 Free Software Foundation, Inc. #include "pdumper.h" #include "keyboard.h" -#if defined HAVE_GLIB && ! defined (HAVE_NS) -#include -#else -#define release_select_lock() do { } while (0) -#endif - union aligned_thread_state { struct thread_state s; @@ -592,8 +586,6 @@ really_call_select (void *arg) sa->result = (sa->func) (sa->max_fds, sa->rfds, sa->wfds, sa->efds, sa->timeout, sa->sigmask); - release_select_lock (); - block_interrupt_signal (&oldset); /* If we were interrupted by C-g while inside sa->func above, the signal handler could have called maybe_reacquire_global_lock, in diff --git a/src/xgselect.c b/src/xgselect.c index 0d91d55bad..d7c63e3be1 100644 --- a/src/xgselect.c +++ b/src/xgselect.c @@ -29,27 +29,6 @@ Copyright (C) 2009-2021 Free Software Foundation, Inc. #include "blockinput.h" #include "systime.h" -static ptrdiff_t threads_holding_glib_lock; -static GMainContext *glib_main_context; - -void release_select_lock (void) -{ - if (--threads_holding_glib_lock == 0) - g_main_context_release (glib_main_context); -} - -static void acquire_select_lock (GMainContext *context) -{ - if (threads_holding_glib_lock++ == 0) - { - glib_main_context = context; - while (!g_main_context_acquire (context)) - { - /* Spin. */ - } - } -} - /* `xg_select' is a `pselect' replacement. Why do we need a separate function? 1. Timeouts. Glib and Gtk rely on timer events. If we did pselect with a greater timeout then the one scheduled by Glib, we would @@ -75,19 +54,26 @@ xg_select (int fds_lim, fd_set *rfds, fd_set *wfds, fd_set *efds, GPollFD *gfds = gfds_buf; int gfds_size = ARRAYELTS (gfds_buf); int n_gfds, retval = 0, our_fds = 0, max_fds = fds_lim - 1; + bool context_acquired = false; int i, nfds, tmo_in_millisec, must_free = 0; bool need_to_dispatch; context = g_main_context_default (); - acquire_select_lock (context); + context_acquired = g_main_context_acquire (context); + /* FIXME: If we couldn't acquire the context, we just silently proceed + because this function handles more than just glib file descriptors. + Note that, as implemented, this failure is completely silent: there is + no feedback to the caller. */ if (rfds) all_rfds = *rfds; else FD_ZERO (&all_rfds); if (wfds) all_wfds = *wfds; else FD_ZERO (&all_wfds); - n_gfds = g_main_context_query (context, G_PRIORITY_LOW, &tmo_in_millisec, - gfds, gfds_size); + n_gfds = (context_acquired + ? g_main_context_query (context, G_PRIORITY_LOW, &tmo_in_millisec, + gfds, gfds_size) + : -1); if (gfds_size < n_gfds) { @@ -165,10 +151,8 @@ xg_select (int fds_lim, fd_set *rfds, fd_set *wfds, fd_set *efds, #else need_to_dispatch = true; #endif - if (need_to_dispatch) + if (need_to_dispatch && context_acquired) { - acquire_select_lock (context); - int pselect_errno = errno; /* Prevent g_main_dispatch recursion, that would occur without block_input wrapper, because event handlers call @@ -178,9 +162,11 @@ xg_select (int fds_lim, fd_set *rfds, fd_set *wfds, fd_set *efds, g_main_context_dispatch (context); unblock_input (); errno = pselect_errno; - release_select_lock (); } + if (context_acquired) + g_main_context_release (context); + /* To not have to recalculate timeout, return like this. */ if ((our_fds > 0 || (nfds == 0 && tmop == &tmo)) && (retval == 0)) { diff --git a/src/xgselect.h b/src/xgselect.h index 2142a236b2..e00dce1283 100644 --- a/src/xgselect.h +++ b/src/xgselect.h @@ -29,6 +29,4 @@ #define XGSELECT_H fd_set *rfds, fd_set *wfds, fd_set *efds, struct timespec *timeout, sigset_t *sigmask); -extern void release_select_lock (void); - #endif /* XGSELECT_H */ -- 2.26.2 --=-=-= Content-Type: text/plain #2. Fails on tip of master, succeeds after patch in #1. --=-=-= Content-Type: application/emacs-lisp Content-Disposition: attachment; filename=42.el Content-Transfer-Encoding: quoted-printable ;; -*- lexical-binding: t -*- (require 'threads) (require 'eieio) (require 'cl-lib) (require 'ring) (defun debug (fmt &rest args) (princ (apply #'format fmt args) #'external-debugging-output) (terpri #'external-debugging-output)) (define-error 'thread-utils-thread-interrupted "Thread was interrupted" 'error) (defun thread-utils-main-thread-p (&optional object) (let ((object (or object (current-thread)))) (and (threadp object) (eq object (car (all-threads)))))) (defun thread-utils-quittable-apply (fn &rest args) (let* ((this-thread (current-thread)) (quit-thread (make-thread (lambda nil (condition-case nil (cl-loop (sleep-for 3)) (quit (thread-signal this-thread 'quit nil)) (thread-utils-thread-interrupted nil)))))) (unwind-protect (apply fn args) (thread-signal quit-thread 'thread-utils-thread-interrupted nil)))) (defun thread-utils-condition-quittable-wait (condition) (cl-check-type condition condition-variable) (thread-utils-quittable-apply #'condition-wait condition)) (defun thread-utils-condition-wait (condition) (if (thread-utils-main-thread-p) (thread-utils-condition-quittable-wait condition) (condition-wait condition))) (defclass channel-terminal nil ((mutex :initarg :mutex :type mutex) (condition :initarg :condition :type condition-variable) (msg-queue :initarg :msg-queue :type ring) (closed-p :initform nil) (other-terminal :type (or null channel-terminal)))) (defclass channel-source (channel-terminal) nil) (defclass channel-sink (channel-terminal) nil) (define-error 'channel-closed "Trying to send/recv from a closed channel") (defun make-channel (capacity) (let* ((mutex (make-mutex "channel")) (condition (make-condition-variable mutex "channel")) (msg-queue (make-ring capacity)) (source (channel-source :mutex mutex :condition condition :msg-queue msg-queue)) (sink (channel-sink :mutex mutex :condition condition :msg-queue msg-queue))) (oset source other-terminal sink) (oset sink other-terminal source) (cons source sink))) (cl-defgeneric channel-send ((source channel-source) message) (with-mutex (oref source mutex) (with-slots (condition msg-queue) source (while (and (not (channel-closed-p source)) (=3D (ring-size msg-queue) (ring-length msg-queue))) (thread-utils-condition-wait condition)) (when (channel-closed-p source) (signal 'channel-closed (list source))) (let ((inhibit-quit t)) (ring-insert msg-queue message) (when (=3D 1 (ring-length msg-queue)) (condition-notify condition t))) nil))) (cl-defgeneric channel-recv ((sink channel-terminal)) (with-mutex (oref sink mutex) (with-slots (condition msg-queue) sink (while (and (not (channel-closed-p sink)) (ring-empty-p msg-queue)) (thread-utils-condition-wait condition)) (when (channel-closed-p sink) (signal 'channel-closed (list sink))) (let ((inhibit-quit t)) (prog1 (ring-remove msg-queue) (when (=3D 1 (- (ring-size msg-queue) (ring-length msg-queue))) (condition-notify condition t))))))) (cl-defgeneric channel-peek ((sink channel-terminal)) (with-mutex (oref sink mutex) (with-slots (condition msg-queue) sink (while (and (not (channel-closed-p sink)) (ring-empty-p msg-queue)) (thread-utils-condition-wait condition)) (when (channel-closed-p sink) (signal 'channel-closed (list sink))) (ring-ref msg-queue -1)))) (cl-defgeneric channel-close ((terminal channel-terminal)) (with-mutex (oref terminal mutex) (with-slots (closed-p condition) terminal (setq closed-p t) (condition-notify condition t)) nil)) (cl-defmethod channel-closed-p ((source channel-source)) (with-mutex (oref source mutex) (with-slots (closed-p other-terminal) source (or closed-p (oref other-terminal closed-p))))) (cl-defmethod channel-closed-p ((sink channel-sink)) (with-mutex (oref sink mutex) (with-slots (closed-p other-terminal msg-queue) sink (or closed-p (and (oref other-terminal closed-p) (ring-empty-p msg-queue)))))) (defmacro start-thread (name what) `(make-thread (lambda () (condition-case err (progn (sleep-for (+ 2 (random 3))) (funcall ,what)) (channel-closed (message "wtf %s: %s" ,name (error-message-string err))))) ,name)) (let ((n 3)) (cl-destructuring-bind (source . sink) (make-channel 1) (dotimes (i n) (let ((send-name (format "send-%d" (1+ i))) (recv-name (format "recv-%d" (- n i)))) (start-thread send-name (lambda () (channel-send source (format "data-%d" i)) (debug "%s: sent %s" send-name (format "data-%d" i)))) (start-thread recv-name (lambda () (when-let ((ret (channel-recv sink))) (debug "%s: recv %s" recv-name ret)))))) (start-thread "clear" (lambda () (while (> (length (cl-remove-if (lambda (thr) (eq (current-thread thr))) (all-threads))) 1) (accept-process-output nil 0.5)) (channel-close source) (channel-close sink))))) (ignore-errors (enable-command 'list-threads)) (call-interactively #'list-threads) --=-=-= Content-Type: text/plain #3. Abridged original example, fails after patch in #1. --=-=-= Content-Type: application/emacs-lisp Content-Disposition: attachment; filename=report.el Content-Transfer-Encoding: quoted-printable ;; -*- lexical-binding: t -*- (require 'threads) (require 'eieio) (require 'cl-lib) (require 'ring) (define-error 'thread-utils-thread-interrupted "Thread was interrupted" 'error) (defun thread-utils-main-thread-p (&optional object) (let ((object (or object (current-thread)))) (and (threadp object) (eq object (car (all-threads)))))) (defun thread-utils-quittable-apply (fn &rest args) (let* ((this-thread (current-thread)) (quit-thread (make-thread (lambda nil (condition-case nil (cl-loop (sleep-for 3)) (quit (thread-signal this-thread 'quit nil)) (thread-utils-thread-interrupted nil)))))) (unwind-protect (apply fn args) (thread-signal quit-thread 'thread-utils-thread-interrupted nil)))) (defun thread-utils-condition-quittable-wait (condition) (cl-check-type condition condition-variable) (thread-utils-quittable-apply #'condition-wait condition)) (defun thread-utils-condition-wait (condition) (if (thread-utils-main-thread-p) (thread-utils-condition-quittable-wait condition) (condition-wait condition))) (defconst channel-default-capacity 16) (defclass channel-terminal nil ((mutex :initarg :mutex :type mutex) (condition :initarg :condition :type condition-variable) (msg-queue :initarg :msg-queue :type ring) (closed-p :initform nil) (other-terminal :type (or null channel-terminal)))) (defclass channel-source (channel-terminal) nil) (defclass channel-sink (channel-terminal) nil) (define-error 'channel-closed "Trying to send/recv from a closed channel") (defun make-channel (&optional capacity) (unless capacity (setq capacity channel-default-capacity)) (cl-check-type capacity (integer 1 *)) (let* ((mutex (make-mutex "channel")) (condition (make-condition-variable mutex "channel")) (msg-queue (make-ring capacity)) (source (channel-source :mutex mutex :condition condition :msg-queue msg-queue)) (sink (channel-sink :mutex mutex :condition condition :msg-queue msg-queue))) (oset source other-terminal sink) (oset sink other-terminal source) (cons source sink))) (cl-defgeneric channel-send ((source channel-source) message) (with-mutex (oref source mutex) (with-slots (condition msg-queue) source (while (and (not (channel-closed-p source)) (=3D (ring-size msg-queue) (ring-length msg-queue))) (thread-utils-condition-wait condition)) (when (channel-closed-p source) (signal 'channel-closed (list source))) (let ((inhibit-quit t)) (ring-insert msg-queue message) (when (=3D 1 (ring-length msg-queue)) (condition-notify condition t))) nil))) (cl-defgeneric channel-recv ((sink channel-terminal)) (with-mutex (oref sink mutex) (with-slots (condition msg-queue) sink (while (and (not (channel-closed-p sink)) (ring-empty-p msg-queue)) (thread-utils-condition-wait condition)) (when (channel-closed-p sink) (signal 'channel-closed (list sink))) (let ((inhibit-quit t)) (prog1 (ring-remove msg-queue) (when (=3D 1 (- (ring-size msg-queue) (ring-length msg-queue))) (condition-notify condition t))))))) (cl-defgeneric channel-peek ((sink channel-terminal)) (with-mutex (oref sink mutex) (with-slots (condition msg-queue) sink (while (and (not (channel-closed-p sink)) (ring-empty-p msg-queue)) (thread-utils-condition-wait condition)) (when (channel-closed-p sink) (signal 'channel-closed (list sink))) (ring-ref msg-queue -1)))) (cl-defgeneric channel-close ((terminal channel-terminal)) (with-mutex (oref terminal mutex) (with-slots (closed-p condition) terminal (setq closed-p t) (condition-notify condition t)) nil)) (cl-defmethod channel-closed-p ((source channel-source)) (with-mutex (oref source mutex) (with-slots (closed-p other-terminal) source (or closed-p (oref other-terminal closed-p))))) (cl-defmethod channel-closed-p ((sink channel-sink)) (with-mutex (oref sink mutex) (with-slots (closed-p other-terminal msg-queue) sink (or closed-p (and (oref other-terminal closed-p) (ring-empty-p msg-queue)))))) (let ((channel (make-channel 1))) (make-thread (lambda nil (channel-send (car channel) 42)) "produce") (channel-recv (cdr channel)) (ignore-errors (enable-command 'list-threads)) (call-interactively #'list-threads)) --=-=-= Content-Type: text/plain Fails not necessarily because xgselect.c is wrong, but rather because channel-recv blocks on a mutex before channel-send can get its act together. This was hard for all to discern because OP seemed to have gone out of his way to obfuscate his "minimum" example. #4. What #3 probably intended, succeeds after patch in #1. --=-=-= Content-Type: application/emacs-lisp Content-Disposition: attachment; filename=report-2.el Content-Transfer-Encoding: quoted-printable ;; -*- lexical-binding: t -*- (require 'threads) (require 'eieio) (require 'cl-lib) (require 'ring) (define-error 'thread-utils-thread-interrupted "Thread was interrupted" 'error) (defun thread-utils-main-thread-p (&optional object) (let ((object (or object (current-thread)))) (and (threadp object) (eq object (car (all-threads)))))) (defun thread-utils-quittable-apply (fn &rest args) (let* ((this-thread (current-thread)) (quit-thread (make-thread (lambda nil (condition-case nil (cl-loop (sleep-for 3)) (quit (thread-signal this-thread 'quit nil)) (thread-utils-thread-interrupted nil)))))) (unwind-protect (apply fn args) (thread-signal quit-thread 'thread-utils-thread-interrupted nil)))) (defun thread-utils-condition-quittable-wait (condition) (cl-check-type condition condition-variable) (thread-utils-quittable-apply #'condition-wait condition)) (defun thread-utils-condition-wait (condition) (if (thread-utils-main-thread-p) (thread-utils-condition-quittable-wait condition) (condition-wait condition))) (defconst channel-default-capacity 16) (defclass channel-terminal nil ((mutex :initarg :mutex :type mutex) (condition :initarg :condition :type condition-variable) (msg-queue :initarg :msg-queue :type ring) (closed-p :initform nil) (other-terminal :type (or null channel-terminal)))) (defclass channel-source (channel-terminal) nil) (defclass channel-sink (channel-terminal) nil) (define-error 'channel-closed "Trying to send/recv from a closed channel") (defun make-channel (&optional capacity) (unless capacity (setq capacity channel-default-capacity)) (cl-check-type capacity (integer 1 *)) (let* ((mutex (make-mutex "channel")) (condition (make-condition-variable mutex "channel")) (msg-queue (make-ring capacity)) (source (channel-source :mutex mutex :condition condition :msg-queue msg-queue)) (sink (channel-sink :mutex mutex :condition condition :msg-queue msg-queue))) (oset source other-terminal sink) (oset sink other-terminal source) (cons source sink))) (cl-defgeneric channel-send ((source channel-source) message) (with-mutex (oref source mutex) (with-slots (condition msg-queue) source (while (and (not (channel-closed-p source)) (=3D (ring-size msg-queue) (ring-length msg-queue))) (thread-utils-condition-wait condition)) (when (channel-closed-p source) (signal 'channel-closed (list source))) (let ((inhibit-quit t)) (ring-insert msg-queue message) (when (=3D 1 (ring-length msg-queue)) (condition-notify condition t))) nil))) (cl-defgeneric channel-recv ((sink channel-terminal)) (with-mutex (oref sink mutex) (with-slots (condition msg-queue) sink (while (and (not (channel-closed-p sink)) (ring-empty-p msg-queue)) (thread-utils-condition-wait condition)) (when (channel-closed-p sink) (signal 'channel-closed (list sink))) (let ((inhibit-quit t)) (prog1 (ring-remove msg-queue) (when (=3D 1 (- (ring-size msg-queue) (ring-length msg-queue))) (condition-notify condition t))))))) (cl-defgeneric channel-peek ((sink channel-terminal)) (with-mutex (oref sink mutex) (with-slots (condition msg-queue) sink (while (and (not (channel-closed-p sink)) (ring-empty-p msg-queue)) (thread-utils-condition-wait condition)) (when (channel-closed-p sink) (signal 'channel-closed (list sink))) (ring-ref msg-queue -1)))) (cl-defgeneric channel-close ((terminal channel-terminal)) (with-mutex (oref terminal mutex) (with-slots (closed-p condition) terminal (setq closed-p t) (condition-notify condition t)) nil)) (cl-defmethod channel-closed-p ((source channel-source)) (with-mutex (oref source mutex) (with-slots (closed-p other-terminal) source (or closed-p (oref other-terminal closed-p))))) (cl-defmethod channel-closed-p ((sink channel-sink)) (with-mutex (oref sink mutex) (with-slots (closed-p other-terminal msg-queue) sink (or closed-p (and (oref other-terminal closed-p) (ring-empty-p msg-queue)))))) (let ((channel (make-channel 1))) (make-thread (lambda nil (channel-send (car channel) 42)) "produce") (make-thread (lambda nil (sleep-for 2) (channel-recv (cdr channel))) "consume") (ignore-errors (enable-command 'list-threads)) (call-interactively #'list-threads)) --=-=-=-- From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Jun 2021 16:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: dick.r.chiang@gmail.com Cc: larsi@gnus.org, pipcet@gmail.com, politza@hochschule-trier.de, 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162299734529728 (code B ref 36609); Sun, 06 Jun 2021 16:36:02 +0000 Received: (at 36609) by debbugs.gnu.org; 6 Jun 2021 16:35:45 +0000 Received: from localhost ([127.0.0.1]:53770 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpvkW-0007jQ-NC for submit@debbugs.gnu.org; Sun, 06 Jun 2021 12:35:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39358) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpvkU-0007jB-BD for 36609@debbugs.gnu.org; Sun, 06 Jun 2021 12:35:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54066) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpvkN-0003nv-NM; Sun, 06 Jun 2021 12:35:35 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3922 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 1lpvkN-0003wU-9q; Sun, 06 Jun 2021 12:35:35 -0400 Date: Sun, 06 Jun 2021 19:35:31 +0300 Message-Id: <83wnr7gdd8.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87fsxv8182.fsf@dick> (dick.r.chiang@gmail.com) References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> X-Spam-Score: -2.3 (--) 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: dick.r.chiang@gmail.com > Cc: Pip Cet , larsi@gnus.org, 36609@debbugs.gnu.org, > Eli Zaretskii > Date: Sun, 06 Jun 2021 11:25:01 -0400 > > #1. Want to revert commit 9c62ffb This will bring back bug#36609, so we cannot do that without discussing first why you think that commit was wrong. > #2. Fails on tip of master, succeeds after patch in #1. Please explain what does "fails" mean, and why do you think the above commit is the culprit. (A much simpler test case will be appreciated, btw.) > Fails not necessarily because xgselect.c is wrong, but rather because > channel-recv blocks on a mutex before channel-send can get its act together. You mean, in this code: (let ((channel (make-channel 1))) (make-thread (lambda nil (channel-send (car channel) 42)) "produce") (channel-recv (cdr channel)) (ignore-errors (enable-command 'list-threads)) (call-interactively #'list-threads)) ? Here, channel-send is called by a new thread, created by make-thread. In this code, it is _expected_ that channel-recv will be called (by the main thread) _before_ channel-send is called by the new thread, because make-thread creates a thread, but the newly created thread doesn't run until it can acquire the global lock. Meanwhile, the main thread continues running and calls channel-recv. The new thread will not begin running, AFAIU, until the main thread calls condition-wait inside channel-recv. By "blocks on a mutex", did you mean that channel-recv blocks trying to acquire the mutex here: (cl-defgeneric channel-recv ((sink channel-terminal)) (with-mutex (oref sink mutex) <<<<<<<<<<<<<<<<<<<<<<<<<< (with-slots (condition msg-queue) sink If so, which thread holds that mutex at this point? > #4. What #3 probably intended, succeeds after patch in #1. Yes, race conditions can be solved by using sleep-for, but that's not really a clean solution, at least not in my book. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: dick.r.chiang@gmail.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Jun 2021 19:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: Eli Zaretskii Cc: larsi@gnus.org, politza@hochschule-trier.de, pipcet@gmail.com, 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162300665312830 (code B ref 36609); Sun, 06 Jun 2021 19:11:02 +0000 Received: (at 36609) by debbugs.gnu.org; 6 Jun 2021 19:10:53 +0000 Received: from localhost ([127.0.0.1]:53931 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpyAe-0003Ks-SH for submit@debbugs.gnu.org; Sun, 06 Jun 2021 15:10:53 -0400 Received: from mail-qt1-f172.google.com ([209.85.160.172]:41889) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpyAc-0003Ke-J8 for 36609@debbugs.gnu.org; Sun, 06 Jun 2021 15:10:52 -0400 Received: by mail-qt1-f172.google.com with SMTP id t20so11106063qtx.8 for <36609@debbugs.gnu.org>; Sun, 06 Jun 2021 12:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=Ii2/Rl1Fw+a5g8FFIrlPqc75+C/SZyw+VDsLidLI4zg=; b=gehuvzjASn3FJz7He/4ycY2HcsMI3LzRTHgXrBbAY1InrfWFUxDBFgEZbY7hJ1aS7U Rwl9tkY7bjCw4/u8OygJQyfW/Imxsmx+DvO05IhHxTDqLiKY09ZO7vUsjwW/OW1zpccY swL8KeQAFWwldRwaZgsn3WCUY77VjTfHNbg/MmR4HWMZViELwpIh93iixNns0c449Zb+ IDD2SI+gEYJIZiqzAoISu7ZGuUpjQNF0Z1m1jGKYLbHbKdrbz1oeXnEjeUhe8v9Fr7Rh 2ZvnKjtM/zYUXiTYZmmO8V7lVBUS4Wa2mXxyTJAJZNFvjN/eB8CFFglJopxJJUo8Fg4f T/pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=Ii2/Rl1Fw+a5g8FFIrlPqc75+C/SZyw+VDsLidLI4zg=; b=g0OnxP3V0FGZRiB4Z1E6XCzcvUx94Hi84CYnb17++vM3DUsNiAZO47Ys0ufoUmxRVe fsUEpJ1nCLRFhPmWi2on+ZZdllW0SzLGdDLsl8F1MKRDeqGQ5re685rNT8nu4P+cE+WD 0qbitUQ8fVkV9R1VOZoxM/Dw65TgZCisG94w50ZzSswCso87ikWsxsyS5XLQeBPn5Zx7 llz5bP5aZxkkY4wrBtAzlJBkJDqwgCbmTVwowccGVdH7Gyn7WutBIP0eD26BR8TWuHQr tLpgfJYaDpeBRGpXTGVB+Ze0wQowPqz2V9Qfmm9WP5P5jLIfOzTetEh4VYIvVv0EaIs3 kJVQ== X-Gm-Message-State: AOAM5318iTNnewg25jNZYG9rRAt/zxJIKEm1spPWyBztN8DO5l+ygtc4 tTrWDGZV0glq6TjQDqA9oYY= X-Google-Smtp-Source: ABdhPJw+WShAN5HHm+9ljRf9M+ffbwMFHwB7znfm2L6ZD8bQ1ofT3tHPc9ka2Gd1QDfsHkljJjl80g== X-Received: by 2002:aed:210f:: with SMTP id 15mr13784398qtc.149.1623006645070; Sun, 06 Jun 2021 12:10:45 -0700 (PDT) Received: from localhost (pool-71-190-212-171.nycmny.fios.verizon.net. [71.190.212.171]) by smtp.gmail.com with ESMTPSA id a191sm8374803qkg.61.2021.06.06.12.10.44 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sun, 06 Jun 2021 12:10:44 -0700 (PDT) From: dick.r.chiang@gmail.com References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> Date: Sun, 06 Jun 2021 15:10:43 -0400 In-Reply-To: <83wnr7gdd8.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 06 Jun 2021 19:35:31 +0300") Message-ID: <875yyqg66k.fsf@dick> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) 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 (-) EZ> This will bring back bug#36609, so we cannot do that without EZ> discussing first why you think that commit was wrong. By enforcing bijection between acquires and releases in xgselect.c -- cavalierly so as the releases now come out-of-band from another module thread.c -- commit 9c62ffb admits deadlock. The conditions under which that happens are not at all rarefied as evidenced by `for i in 1 2 3 ; do src/emacs -Q -l ./42.el & done ;` Generally, a commit made to remedy a phantom problem should always be suspect. In this case OP was squatting on the main thread, so he deserves what he got. EZ> Yes, race conditions can be solved by using sleep-for, but that's not EZ> really a clean solution, at least not in my book. Case #4 was not meant to solve anything, only to set OP straight on what he really wanted. You can remove the sleep-for. Still works under patch #1. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Jun 2021 19:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: dick.r.chiang@gmail.com Cc: larsi@gnus.org, politza@hochschule-trier.de, pipcet@gmail.com, 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162300767914341 (code B ref 36609); Sun, 06 Jun 2021 19:28:02 +0000 Received: (at 36609) by debbugs.gnu.org; 6 Jun 2021 19:27:59 +0000 Received: from localhost ([127.0.0.1]:53948 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpyRD-0003jE-4L for submit@debbugs.gnu.org; Sun, 06 Jun 2021 15:27:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpyR9-0003it-Gu for 36609@debbugs.gnu.org; Sun, 06 Jun 2021 15:27:57 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58646) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpyR2-00067W-QW; Sun, 06 Jun 2021 15:27:48 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2778 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 1lpyR2-0000iB-AX; Sun, 06 Jun 2021 15:27:48 -0400 Date: Sun, 06 Jun 2021 22:27:45 +0300 Message-Id: <83k0n6hjym.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <875yyqg66k.fsf@dick> (dick.r.chiang@gmail.com) References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> X-Spam-Score: -2.3 (--) 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: dick.r.chiang@gmail.com > Cc: larsi@gnus.org, pipcet@gmail.com, politza@hochschule-trier.de, > 36609@debbugs.gnu.org > Date: Sun, 06 Jun 2021 15:10:43 -0400 > > EZ> This will bring back bug#36609, so we cannot do that without > EZ> discussing first why you think that commit was wrong. > > By enforcing bijection between acquires and releases in xgselect.c -- > cavalierly so as the releases now come out-of-band from another module > thread.c -- commit 9c62ffb admits deadlock. The conditions under which that > happens are not at all rarefied as evidenced by `for i in 1 2 3 ; do src/emacs > -Q -l ./42.el & done ;` You will have to provide a more detailed analysis, sorry. The fact that some Lisp can cause deadlock does not prove anything, there are too many ways to write such deadlocking code. > Generally, a commit made to remedy a phantom problem should always be > suspect. In this case OP was squatting on the main thread, so he deserves > what he got. That was not the analysis of that test case. See the discussion of the bug. The problems with the GTK lock are real, not phantom. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: dick.r.chiang@gmail.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Jun 2021 21:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: Eli Zaretskii Cc: larsi@gnus.org, pipcet@gmail.com, politza@hochschule-trier.de, 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162327484113394 (code B ref 36609); Wed, 09 Jun 2021 21:41:01 +0000 Received: (at 36609) by debbugs.gnu.org; 9 Jun 2021 21:40:41 +0000 Received: from localhost ([127.0.0.1]:34794 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lr5wG-0003Ty-RS for submit@debbugs.gnu.org; Wed, 09 Jun 2021 17:40:41 -0400 Received: from mail-qk1-f172.google.com ([209.85.222.172]:40875) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lr5wC-0003Tg-Ja for 36609@debbugs.gnu.org; Wed, 09 Jun 2021 17:40:39 -0400 Received: by mail-qk1-f172.google.com with SMTP id u30so25260743qke.7 for <36609@debbugs.gnu.org>; Wed, 09 Jun 2021 14:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=JVtouAO+wsqgDxIC6mqjcOiWtk6odQlpL0hRdvzXPgk=; b=ml7hwuLraUKMbi73BCJdkiFBB1y1gPc9wfbfASSqgf1dYFEVTJvOukvkQsthAegdBA kXjfSZ5tizLxpqIUekQzK2EpooZzqBbzU09norTml3rLxN+Ni1SOUZYniVW3IuQIKlIw gor5WQ5HIxaGrppgDwgVIterU7eGhPL1f0HHjSna78rEOIPboWCc48bw9Cj//kYSU8Yz w0pwmJJjHhL9jR6OL+AkbVvWWMsDMX0zZbrvb7GnTB4P6IxuBR50Qj+BTUs1CGKwB97R h5nwc/yf79R/GE+4+PIt0B64xm/3xGKJ0LrzL2SfC5jWOTgnALkuX5Xsrk7vFdxBm7pW 3ntg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=JVtouAO+wsqgDxIC6mqjcOiWtk6odQlpL0hRdvzXPgk=; b=kghYXCq7TU3DDlj8aST0zK5nhay+tOdJOv8E9BdND1NSbqlLDymnZSg9V+ca3eRTlZ LMVBRHlvl7hGrUb8zRVreLoDuC02CUlGsXJqn6UUiiHevZMpoa7SV5RKdWKjGasyk2jc VIv4/I+8Kk4pWX8zgb+OAXtZN/DT3unYAMRImluZRc8Abv0QVF5yOpx5hdyu/S4EGC8S bTrF1HOu6AU+CB8GWJVGxHCymNnUmNKez6kIbZ+TfYZcvuqYM3/zIFic8VVy7I0mIONW jcX7I7GPf5BQhKSw8TPB8F5xPVMtWoRL9niS7ghxQ/imdDmlbWQ6iR9dGHaElBd71yYc 84cA== X-Gm-Message-State: AOAM530st2xQccfzqfycTMzFRRuNXsgMFf2oxTpUJ0haxA88ZVkw+5le uaCZwkyurD8xSOzhD4nhcCg= X-Google-Smtp-Source: ABdhPJyNfHa5S0OgYUO/FtPnk4dY3zkrOCi3RTgAMf0iZG6n397zCQvFXb73VhmvBvhlhtMHIP5Q2w== X-Received: by 2002:a37:848:: with SMTP id 69mr1705148qki.411.1623274830830; Wed, 09 Jun 2021 14:40:30 -0700 (PDT) Received: from localhost (pool-71-190-212-171.nycmny.fios.verizon.net. [71.190.212.171]) by smtp.gmail.com with ESMTPSA id u123sm873846qkh.83.2021.06.09.14.40.29 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 09 Jun 2021 14:40:29 -0700 (PDT) From: dick.r.chiang@gmail.com References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> <83k0n6hjym.fsf@gnu.org> Date: Wed, 09 Jun 2021 17:40:28 -0400 In-Reply-To: <83k0n6hjym.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 06 Jun 2021 22:27:45 +0300") Message-ID: <87wnr2lnsj.fsf@dick> User-Agent: Gnus/5.14 (Gnus v5.14pre) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) 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 (-) --=-=-= Content-Type: text/plain EZ> You will have to provide a more detailed analysis, sorry. There is no guarantee the static variable `threads_holding_glib_lock` introduced in xgselect.c in commit 9c62ffb is synchronized across threads. As such, relying on it becoming zero in time for release_select_lock() is fraught. (If you add print statements, this particular heisenbug disappears, at least on Linux kernel 4.15.0-99-generic). Four attachments: 1. Desired patch to master (reverts 9c62ffb, adds main-thread-p check). --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-Only-acquire-glib-context-if-main-thread.patch >From 5b30b55f60844ada43b119640e052f8ed5ee6e9c Mon Sep 17 00:00:00 2001 From: dickmao Date: Wed, 9 Jun 2021 17:11:48 -0400 Subject: [PATCH] Only acquire glib context if main thread * src/thread.c (really_call_select): revert 9c62ffb * src/xgselect.c (xg_select): revert 9c62ffb, only acquire glib if main --- src/thread.c | 8 -------- src/xgselect.c | 44 ++++++++++++++++---------------------------- src/xgselect.h | 2 -- 3 files changed, 16 insertions(+), 38 deletions(-) diff --git a/src/thread.c b/src/thread.c index f74f611148..609cd7c5fc 100644 --- a/src/thread.c +++ b/src/thread.c @@ -28,12 +28,6 @@ Copyright (C) 2012-2021 Free Software Foundation, Inc. #include "pdumper.h" #include "keyboard.h" -#if defined HAVE_GLIB && ! defined (HAVE_NS) -#include -#else -#define release_select_lock() do { } while (0) -#endif - union aligned_thread_state { struct thread_state s; @@ -592,8 +586,6 @@ really_call_select (void *arg) sa->result = (sa->func) (sa->max_fds, sa->rfds, sa->wfds, sa->efds, sa->timeout, sa->sigmask); - release_select_lock (); - block_interrupt_signal (&oldset); /* If we were interrupted by C-g while inside sa->func above, the signal handler could have called maybe_reacquire_global_lock, in diff --git a/src/xgselect.c b/src/xgselect.c index 0d91d55bad..b40f75cb50 100644 --- a/src/xgselect.c +++ b/src/xgselect.c @@ -28,27 +28,7 @@ Copyright (C) 2009-2021 Free Software Foundation, Inc. #include "lisp.h" #include "blockinput.h" #include "systime.h" - -static ptrdiff_t threads_holding_glib_lock; -static GMainContext *glib_main_context; - -void release_select_lock (void) -{ - if (--threads_holding_glib_lock == 0) - g_main_context_release (glib_main_context); -} - -static void acquire_select_lock (GMainContext *context) -{ - if (threads_holding_glib_lock++ == 0) - { - glib_main_context = context; - while (!g_main_context_acquire (context)) - { - /* Spin. */ - } - } -} +#include "thread.h" /* `xg_select' is a `pselect' replacement. Why do we need a separate function? 1. Timeouts. Glib and Gtk rely on timer events. If we did pselect @@ -75,19 +55,27 @@ xg_select (int fds_lim, fd_set *rfds, fd_set *wfds, fd_set *efds, GPollFD *gfds = gfds_buf; int gfds_size = ARRAYELTS (gfds_buf); int n_gfds, retval = 0, our_fds = 0, max_fds = fds_lim - 1; + bool context_acquired = false; int i, nfds, tmo_in_millisec, must_free = 0; bool need_to_dispatch; context = g_main_context_default (); - acquire_select_lock (context); + if (main_thread_p (current_thread)) + context_acquired = g_main_context_acquire (context); + /* FIXME: If we couldn't acquire the context, we just silently proceed + because this function handles more than just glib file descriptors. + Note that, as implemented, this failure is completely silent: there is + no feedback to the caller. */ if (rfds) all_rfds = *rfds; else FD_ZERO (&all_rfds); if (wfds) all_wfds = *wfds; else FD_ZERO (&all_wfds); - n_gfds = g_main_context_query (context, G_PRIORITY_LOW, &tmo_in_millisec, - gfds, gfds_size); + n_gfds = (context_acquired + ? g_main_context_query (context, G_PRIORITY_LOW, &tmo_in_millisec, + gfds, gfds_size) + : -1); if (gfds_size < n_gfds) { @@ -165,10 +153,8 @@ xg_select (int fds_lim, fd_set *rfds, fd_set *wfds, fd_set *efds, #else need_to_dispatch = true; #endif - if (need_to_dispatch) + if (need_to_dispatch && context_acquired) { - acquire_select_lock (context); - int pselect_errno = errno; /* Prevent g_main_dispatch recursion, that would occur without block_input wrapper, because event handlers call @@ -178,9 +164,11 @@ xg_select (int fds_lim, fd_set *rfds, fd_set *wfds, fd_set *efds, g_main_context_dispatch (context); unblock_input (); errno = pselect_errno; - release_select_lock (); } + if (context_acquired) + g_main_context_release (context); + /* To not have to recalculate timeout, return like this. */ if ((our_fds > 0 || (nfds == 0 && tmop == &tmo)) && (retval == 0)) { diff --git a/src/xgselect.h b/src/xgselect.h index 2142a236b2..e00dce1283 100644 --- a/src/xgselect.h +++ b/src/xgselect.h @@ -29,6 +29,4 @@ #define XGSELECT_H fd_set *rfds, fd_set *wfds, fd_set *efds, struct timespec *timeout, sigset_t *sigmask); -extern void release_select_lock (void); - #endif /* XGSELECT_H */ -- 2.26.2 --=-=-= Content-Type: text/plain 2. OP's original "my code doesn't work, here you figure it out", obfuscated MRE Run as: for i in 1 2 3 ; do src/emacs -Q -l ./report-orig.el & done Fails if: One of the emacsen stops responding --=-=-= Content-Type: application/emacs-lisp Content-Disposition: attachment; filename=report-orig.el Content-Transfer-Encoding: quoted-printable ;; -*- lexical-binding: t -*- (require 'threads) (require 'eieio) (require 'cl-lib) (require 'ring) (defun debug (fmt &rest args) (princ (apply #'format fmt args) #'external-debugging-output) (terpri #'external-debugging-output)) (define-error 'thread-utils-thread-interrupted "Thread was interrupted" 'error) (defun thread-utils-main-thread-p (&optional object) (let ((object (or object (current-thread)))) (and (threadp object) (eq object (car (all-threads)))))) (defun thread-utils-quitable-apply (fn &rest args) (let ((quit-thread (make-thread (lambda nil (condition-case nil (cl-loop (sleep-for 3)) (thread-utils-thread-interrupted nil)))))) (unwind-protect (apply fn args) (thread-signal quit-thread 'thread-utils-thread-interrupted nil)))) (defun thread-utils-condition-quitable-wait (condition) (cl-check-type condition condition-variable) (thread-utils-quitable-apply #'condition-wait condition)) (defun thread-utils-condition-wait (condition) (if (thread-utils-main-thread-p) (thread-utils-condition-quitable-wait condition) (condition-wait condition))) (defconst channel-default-capacity 16) (defclass channel-terminal nil ((mutex :initarg :mutex :type mutex) (condition :initarg :condition :type condition-variable) (msg-queue :initarg :msg-queue :type ring) (closed-p :initform nil) (other-terminal :type (or null channel-terminal)))) (defclass channel-source (channel-terminal) nil) (defclass channel-sink (channel-terminal) nil) (define-error 'channel-closed "Trying to send/recv from a closed channel") (defun make-channel (&optional capacity) (unless capacity (setq capacity channel-default-capacity)) (cl-check-type capacity (integer 1 *)) (let* ((mutex (make-mutex "channel")) (condition (make-condition-variable mutex "channel")) (msg-queue (make-ring capacity)) (source (channel-source :mutex mutex :condition condition :msg-queue msg-queue)) (sink (channel-sink :mutex mutex :condition condition :msg-queue msg-queue))) (oset source other-terminal sink) (oset sink other-terminal source) (cons source sink))) (cl-defgeneric channel-send ((source channel-source) message) (with-mutex (oref source mutex) (with-slots (condition msg-queue) source (while (and (not (channel-closed-p source)) (=3D (ring-size msg-queue) (ring-length msg-queue))) (thread-utils-condition-wait condition)) (when (channel-closed-p source) (signal 'channel-closed (list source))) (let ((inhibit-quit t)) (ring-insert msg-queue message) (when (=3D 1 (ring-length msg-queue)) (condition-notify condition t))) nil))) (cl-defgeneric channel-recv ((sink channel-terminal)) (with-mutex (oref sink mutex) (with-slots (condition msg-queue) sink (while (and (not (channel-closed-p sink)) (ring-empty-p msg-queue)) (thread-utils-condition-wait condition)) (when (channel-closed-p sink) (signal 'channel-closed (list sink))) (let ((inhibit-quit t)) (prog1 (ring-remove msg-queue) (when (=3D 1 (- (ring-size msg-queue) (ring-length msg-queue))) (condition-notify condition t))))))) (cl-defgeneric channel-peek ((sink channel-terminal)) (with-mutex (oref sink mutex) (with-slots (condition msg-queue) sink (while (and (not (channel-closed-p sink)) (ring-empty-p msg-queue)) (thread-utils-condition-wait condition)) (when (channel-closed-p sink) (signal 'channel-closed (list sink))) (ring-ref msg-queue -1)))) (cl-defgeneric channel-close ((terminal channel-terminal)) (with-mutex (oref terminal mutex) (with-slots (closed-p condition) terminal (setq closed-p t) (condition-notify condition t)) nil)) (cl-defmethod channel-closed-p ((source channel-source)) (with-mutex (oref source mutex) (with-slots (closed-p other-terminal) source (or closed-p (oref other-terminal closed-p))))) (cl-defmethod channel-closed-p ((sink channel-sink)) (with-mutex (oref sink mutex) (with-slots (closed-p other-terminal msg-queue) sink (or closed-p (and (oref other-terminal closed-p) (ring-empty-p msg-queue)))))) (defclass future nil ((channel :initform (make-channel 1)))) (defun make-future () (make-instance 'future)) (cl-defgeneric future-set ((future future) value) (with-slots (channel) future (let ((inhibit-quit t)) (condition-case nil (progn (debug "Sending future") (channel-send (car channel) value) (debug "Future send")) (channel-closed (signal 'error (list future)))) (debug "Closing future") (channel-close (car channel)) (debug "Future closed")))) (cl-defgeneric future-get ((future future)) (with-slots (channel) future (debug "Getting future") (channel-peek (cdr channel)) (debug "Future got"))) (defclass future-deferred (future) ((producer :initarg :producer :type function) (value-produced-p :initform nil) (mutex :initform (make-mutex "future-deferred")))) (defun make-deferred-future (producer) (make-instance 'future-deferred :producer producer)) (cl-defmethod future-get :before ((future future-deferred)) (with-slots (mutex value-produced-p producer) future (with-mutex mutex (unless value-produced-p (unwind-protect (make-thread (lambda nil (debug "Setting Future") (future-set future (funcall producer)) (debug "Future set")) "XEmacs") (setq value-produced-p t)))))) (ignore-errors (enable-command 'list-threads)) (call-interactively #'list-threads) (let ((future (make-deferred-future (lambda nil 42)))) (future-get future)) --=-=-= Content-Type: text/plain 3. "Affine" redaction of OP's MRE *infrequently* breaks on tip of master (succeeds after patch) Run as: for i in 1 2 3 ; do src/emacs -Q -l ./report.el & done Fails if: One of the emacsen stops responding --=-=-= Content-Type: application/emacs-lisp Content-Disposition: attachment; filename=report.el Content-Transfer-Encoding: quoted-printable ;; -*- lexical-binding: t -*- (call-interactively #'list-threads) (let* ((cv (make-condition-variable (make-mutex) "CV")) condition (notify (lambda () (sleep-for 1) ;; let wait() start spinning first (with-mutex (condition-mutex cv) (setq condition t) (condition-notify cv)))) (wait (lambda () (with-mutex (condition-mutex cv) (while (not condition) (condition-wait cv))))) (herring (make-thread (apply-partially #'sleep-for 1000) "unrelated"= ))) (make-thread notify "notify") (funcall wait) (thread-signal herring 'quit nil)) --=-=-= Content-Type: text/plain 4. My MRE *frequently* breaks tip of master (succeeds after patch) --=-=-= Content-Type: application/emacs-lisp Content-Disposition: attachment; filename=42.el Content-Transfer-Encoding: quoted-printable ;; -*- lexical-binding: t -*- (require 'eieio) (defclass channel () ((condition :initarg :condition :type condition-variable) (msg-queue :initarg :msg-queue :type ring))) (cl-defgeneric channel-send ((channel channel) message) (with-slots (condition msg-queue) channel (with-mutex (condition-mutex condition) (while (<=3D (ring-size msg-queue) (ring-length msg-queue)) (condition-wait condition)) (ring-insert msg-queue message) (condition-notify condition t)))) (cl-defgeneric channel-recv ((channel channel)) (with-slots (condition msg-queue) channel (with-mutex (condition-mutex condition) (while (ring-empty-p msg-queue) (condition-wait condition)) (prog1 (ring-remove msg-queue) (condition-notify condition t))))) (defmacro run-thread (name what) `(make-thread (lambda () (sleep-for (1+ (random 3))) (funcall ,what) (princ (format "%s finished\n" ,name) #'external-debugging-output)) ,name)) (call-interactively #'list-threads) (let* ((n 3) (capacity 1) (channel (make-instance 'channel :condition (make-condition-variable (make-mutex) "channel") :msg-queue (make-ring capacity)))) (dotimes (i n) (let ((send-name (format "send-%d" (1+ i))) (recv-name (format "recv-%d" (- n i)))) (run-thread send-name (lambda () (channel-send channel 42))) (run-thread recv-name (lambda () (channel-recv channel)))))) --=-=-= Content-Type: text/plain Run as: for i in 1 2 3 ; do src/emacs -Q -l ./42.el & done Fails if: One of the emacsen stops responding --=-=-=-- From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Jun 2021 06:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: dick.r.chiang@gmail.com Cc: larsi@gnus.org, pipcet@gmail.com, politza@hochschule-trier.de, 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162330760516996 (code B ref 36609); Thu, 10 Jun 2021 06:47:01 +0000 Received: (at 36609) by debbugs.gnu.org; 10 Jun 2021 06:46:45 +0000 Received: from localhost ([127.0.0.1]:35260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrESi-0004Q3-Mu for submit@debbugs.gnu.org; Thu, 10 Jun 2021 02:46:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57962) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrESh-0004Pq-KM for 36609@debbugs.gnu.org; Thu, 10 Jun 2021 02:46:44 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38634) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrESa-0005Sy-Km; Thu, 10 Jun 2021 02:46:36 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3651 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 1lrESa-00066i-3G; Thu, 10 Jun 2021 02:46:36 -0400 Date: Thu, 10 Jun 2021 09:46:24 +0300 Message-Id: <83h7i6cj3z.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87wnr2lnsj.fsf@dick> (dick.r.chiang@gmail.com) References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> <83k0n6hjym.fsf@gnu.org> <87wnr2lnsj.fsf@dick> X-Spam-Score: -2.3 (--) 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: dick.r.chiang@gmail.com > Cc: larsi@gnus.org, politza@hochschule-trier.de, pipcet@gmail.com, > 36609@debbugs.gnu.org > Date: Wed, 09 Jun 2021 17:40:28 -0400 > > There is no guarantee the static variable `threads_holding_glib_lock` > introduced in xgselect.c in commit 9c62ffb is synchronized across threads. How can that happen? It's a single word, and its change should therefore be atomic. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: dick.r.chiang@gmail.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Jun 2021 11:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: Eli Zaretskii Cc: 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162332597516451 (code B ref 36609); Thu, 10 Jun 2021 11:53:02 +0000 Received: (at 36609) by debbugs.gnu.org; 10 Jun 2021 11:52:55 +0000 Received: from localhost ([127.0.0.1]:35634 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrJF1-0004HF-9h for submit@debbugs.gnu.org; Thu, 10 Jun 2021 07:52:55 -0400 Received: from mail-qv1-f51.google.com ([209.85.219.51]:38877) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrJEy-0004Gy-6D for 36609@debbugs.gnu.org; Thu, 10 Jun 2021 07:52:54 -0400 Received: by mail-qv1-f51.google.com with SMTP id t6so8637607qvp.5 for <36609@debbugs.gnu.org>; Thu, 10 Jun 2021 04:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=G5gOhau7OwddOgsuslG080qUr3P0q6a2IhhJsOIjURM=; b=PtBA+q3iRiWGRLUMVGIk9GebIGiI6Nj0Z7gi2CYMR2rUNq7vZX6kr/1CKheC2cbGWK 2cAGdDR0wdJne8lxAjguBHGcnsAlREUVUl8GrrQM+3f5R9Mf3fiPgQ3UPMRyE6Eh4O59 CPhi5CEjST2s1yRPvbhn/0qm6gRWhbk6C+2SgDgzCQN65muRcdydo5sgZDGQ1ZnTCLl9 wxtoAxLg+zBn8CfKoKYFA6KRNJ84iyg+5seks2JeYfDKQkNrcSkb/F1p1AA4VD28ToIw FwdW2BX1pVuIfGrD57aI1LtVMpIm6V4jXuHHJfmslaWlxYhulO6X1O3XwABkqWb/4Rus x+KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=G5gOhau7OwddOgsuslG080qUr3P0q6a2IhhJsOIjURM=; b=FCP+h3kTrnLPkcG7ccKejFCT+Tz8mkQaEB3K7aEv1B6nu7qO9pf8iYv1OEU9yzCLIW wlWHH5iPwwnLxRWA8wqcesfr+Rr2dsgqauoIXw8Eihl7WHE37CdFJMbiqrb/NjaTATRu uPtVnNSC8Ezi2BEr6zTHM6dVjEQeY0C35a1/HrM5oCTZlTEgSlBbCd2VaZNBqLU1ueQ2 5+BHjU5GlJCnEg+TPt2dxPSOuR3ydQiMlxZ41hnxQR+7FBeQ/CB8L6+W3yTes1TuI/+i 7tj/qXgYZ8+ElvsGcMYg03VnV2cACCi/Nveem/rsMK7UxkSa2GNzw7Yvma2Dj5OftlPk o10A== X-Gm-Message-State: AOAM5312qve2WTeTJJUd974/Sd4a2loj5DZGwUoaiLaCttsZ0l7m4cHZ ncmQEzHapl091QxoVbfEJAw= X-Google-Smtp-Source: ABdhPJy0G3LTwQ/LCSL8UWOwcGXfNkxoScet6opE8zl6k07qn/S9GqX/geftr9djoe5/zAN+7XQxdg== X-Received: by 2002:ad4:4863:: with SMTP id u3mr4556554qvy.7.1623325966636; Thu, 10 Jun 2021 04:52:46 -0700 (PDT) Received: from localhost (pool-71-190-212-171.nycmny.fios.verizon.net. [71.190.212.171]) by smtp.gmail.com with ESMTPSA id e24sm1914610qtp.97.2021.06.10.04.52.45 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 10 Jun 2021 04:52:45 -0700 (PDT) From: dick.r.chiang@gmail.com References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> <83k0n6hjym.fsf@gnu.org> <87wnr2lnsj.fsf@dick> <83h7i6cj3z.fsf@gnu.org> Date: Thu, 10 Jun 2021 07:52:45 -0400 In-Reply-To: <83h7i6cj3z.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 10 Jun 2021 09:46:24 +0300") Message-ID: <87bl8e2aya.fsf@dick> User-Agent: Gnus/5.14 (Gnus v5.14pre) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) 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 (-) [Standard disclaimer about not being a compiler semanticist] > a single word... change should ... be atomic. I've never heard that. I googled around; one helpful and only mildly sententious monograph on the topic is https://stefansf.de/post/qualifier-volatile-c/ Adding the volatile qualifier to `threads_holding_glib_lock` did not resolve my MRE on my particular architecture (whatever that may be). From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Jun 2021 14:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: dick.r.chiang@gmail.com Cc: 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162333475831691 (code B ref 36609); Thu, 10 Jun 2021 14:20:02 +0000 Received: (at 36609) by debbugs.gnu.org; 10 Jun 2021 14:19:18 +0000 Received: from localhost ([127.0.0.1]:37513 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrLWg-0008F3-Kj for submit@debbugs.gnu.org; Thu, 10 Jun 2021 10:19:18 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60882) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrLWd-0008En-NA for 36609@debbugs.gnu.org; Thu, 10 Jun 2021 10:19:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52224) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrLWY-0008Hr-Gv; Thu, 10 Jun 2021 10:19:10 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4194 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 1lrLWY-0004bV-5x; Thu, 10 Jun 2021 10:19:10 -0400 Date: Thu, 10 Jun 2021 17:18:54 +0300 Message-Id: <8335tpdcq9.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87bl8e2aya.fsf@dick> (dick.r.chiang@gmail.com) References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> <83k0n6hjym.fsf@gnu.org> <87wnr2lnsj.fsf@dick> <83h7i6cj3z.fsf@gnu.org> <87bl8e2aya.fsf@dick> X-Spam-Score: -2.3 (--) 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: dick.r.chiang@gmail.com > Cc: 36609@debbugs.gnu.org > Date: Thu, 10 Jun 2021 07:52:45 -0400 > > > a single word... change should ... be atomic. > > I've never heard that. The idea is that a variable that is modified in a single machine instruction will always have the value assigned by the last thread which set that. You cannot have, for example, half of the bits of the variable set by one thread and the other half by another thread. > Adding the volatile qualifier to `threads_holding_glib_lock` did not > resolve my MRE on my particular architecture (whatever that may be). So can you describe what you think happens in your scenario that the offending change that added threads_holding_glib_lock causes? Because I still don't see the connection, to tell the truth. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: dick.r.chiang@gmail.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Jun 2021 14:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: Eli Zaretskii Cc: 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.16233369782878 (code B ref 36609); Thu, 10 Jun 2021 14:57:01 +0000 Received: (at 36609) by debbugs.gnu.org; 10 Jun 2021 14:56:18 +0000 Received: from localhost ([127.0.0.1]:37549 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrM6T-0000kL-6X for submit@debbugs.gnu.org; Thu, 10 Jun 2021 10:56:18 -0400 Received: from mail-qt1-f179.google.com ([209.85.160.179]:44684) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrM6C-0000jS-G5 for 36609@debbugs.gnu.org; Thu, 10 Jun 2021 10:56:15 -0400 Received: by mail-qt1-f179.google.com with SMTP id t17so21134829qta.11 for <36609@debbugs.gnu.org>; Thu, 10 Jun 2021 07:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=ClckA7g4rvcs3CP0fvoSLzNGGBp4QzG+Q37VJuVsBu0=; b=NqwR2Ikt1IS529X0V5AHkuUSg5uRszUad0cs1tEmYf2eq4+ZVidmiTmBRxcgewb3Rb PINciJC7BVGfALxXkizdl+UEJ5YsoOk1fDa00ftvAjGz/EMemAj9MC6ls+CXa+GNpk/Y BaRQWQ5UZCdQk51xWecfYj+r4CuvziqX0Tdc1Tm/SIAd3ClV0qnECgXvnbbTPzt2/I6M HhkZjv/x4CjM8qPUk4AMOYHYmYblyosWPtwl/1LcPaORRnhDNttWq0OVEj3gcqZlb9gv 1QnQnwnT37SZFl6Ndwg8ua25InLXu0BwWh7lDg0dCWkht4IgMmPSaYdcFF+HSu9PpCiO OJjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=ClckA7g4rvcs3CP0fvoSLzNGGBp4QzG+Q37VJuVsBu0=; b=Fvu/vRoYjih430briF6k5Ac2rtBSErem4QkNXo5wABAl8ud612WpwZy0sd6fuU5bre Ah/0an4g/Bw1nfysps04DmznSTIMEQRIZkzYL/k/I3utiPVScOIdmd6UsOOPj3barsnx 9lO5BOCIh/KPdyaeiMBxCDUWqP3G5DYTNRU50VfkRl5EzHNY17UCJ6PcKFw8HAxLy3ls fclj7IHQ3a4Z8vQWLg4BUof1C5U39sHMlBLlbgy/JzRrLGM0w03uoeHO+uwDkLxazlGd uN88xQ/LK3pS9N2ASU00r0HjEw+Pro16VmvhQHH1O26AgCTwLxuZeLWbCqCikJChIzNl KZDQ== X-Gm-Message-State: AOAM531ATsOjt+horL4Y+IuTvrG/roOYgn0RyH0WY+Uc0C+HyUmeyjFW hrq1OEUpMc7LZw1sDgIH1TA= X-Google-Smtp-Source: ABdhPJwGQZ+gie2TFK3wc1dRUt4bLvH3Gnpk160iJx14spN8XQhQ/yZiN6K7dNu+7L9eCdPaxX5wbA== X-Received: by 2002:ac8:7352:: with SMTP id q18mr9878qtp.306.1623336954868; Thu, 10 Jun 2021 07:55:54 -0700 (PDT) Received: from localhost (pool-71-190-212-171.nycmny.fios.verizon.net. [71.190.212.171]) by smtp.gmail.com with ESMTPSA id u13sm2340739qke.41.2021.06.10.07.55.53 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 10 Jun 2021 07:55:54 -0700 (PDT) From: dick.r.chiang@gmail.com References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> <83k0n6hjym.fsf@gnu.org> <87wnr2lnsj.fsf@dick> <83h7i6cj3z.fsf@gnu.org> <87bl8e2aya.fsf@dick> <8335tpdcq9.fsf@gnu.org> Date: Thu, 10 Jun 2021 10:55:53 -0400 In-Reply-To: <8335tpdcq9.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 10 Jun 2021 17:18:54 +0300") Message-ID: <87y2bhepl2.fsf@dick> User-Agent: Gnus/5.14 (Gnus v5.14pre) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) 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 (-) > You cannot have, for example, half of the bits of the variable set by one thread > and the other half by another thread. I dunno, this seems like a sophomoric, rose-colored view of variable sharing without regard to caching, or really any generally accepted guarantees about POSIX threads. > So can you describe what you think happens in your scenario that the > offending change that added threads_holding_glib_lock causes? Two threads see `threads_holding_glib_lock` is "0" and both attempt acquiring the lock (line 43, xgselect.c) Or, two threads see `threads_holding_glib_lock` as "2" and glib lock is never released. (line 37, xgselect.c) From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Jun 2021 15:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: dick.r.chiang@gmail.com Cc: 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.16233375283820 (code B ref 36609); Thu, 10 Jun 2021 15:06:02 +0000 Received: (at 36609) by debbugs.gnu.org; 10 Jun 2021 15:05:28 +0000 Received: from localhost ([127.0.0.1]:37561 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrMFM-0000zY-3G for submit@debbugs.gnu.org; Thu, 10 Jun 2021 11:05:28 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50278) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrMFK-0000zL-3n for 36609@debbugs.gnu.org; Thu, 10 Jun 2021 11:05:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54262) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrMFE-0006Lj-Jr; Thu, 10 Jun 2021 11:05:20 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3120 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 1lrMF2-0001OZ-UR; Thu, 10 Jun 2021 11:05:11 -0400 Date: Thu, 10 Jun 2021 18:04:55 +0300 Message-Id: <83y2bhbw14.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87y2bhepl2.fsf@dick> (dick.r.chiang@gmail.com) References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> <83k0n6hjym.fsf@gnu.org> <87wnr2lnsj.fsf@dick> <83h7i6cj3z.fsf@gnu.org> <87bl8e2aya.fsf@dick> <8335tpdcq9.fsf@gnu.org> <87y2bhepl2.fsf@dick> X-Spam-Score: -2.3 (--) 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: dick.r.chiang@gmail.com > Cc: 36609@debbugs.gnu.org > Date: Thu, 10 Jun 2021 10:55:53 -0400 > > > You cannot have, for example, half of the bits of the variable set by one thread > > and the other half by another thread. > > I dunno, this seems like a sophomoric, rose-colored view of variable sharing > without regard to caching, or really any generally accepted guarantees about > POSIX threads. Is it, really? > > So can you describe what you think happens in your scenario that the > > offending change that added threads_holding_glib_lock causes? > > Two threads see `threads_holding_glib_lock` is "0" and both attempt > acquiring the lock (line 43, xgselect.c) > > Or, two threads see `threads_holding_glib_lock` as "2" and glib > lock is never released. (line 37, xgselect.c) And you can show a GDB backtrace with values of the variable that supports that? And tell how that explains the hang that you see on the Lisp level? These are the details that I was asking from the first message you posted here. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Andreas Schwab Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Jun 2021 15:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: Eli Zaretskii Cc: dick.r.chiang@gmail.com, 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162333935915067 (code B ref 36609); Thu, 10 Jun 2021 15:36:01 +0000 Received: (at 36609) by debbugs.gnu.org; 10 Jun 2021 15:35:59 +0000 Received: from localhost ([127.0.0.1]:37591 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrMit-0003ux-Gs for submit@debbugs.gnu.org; Thu, 10 Jun 2021 11:35:59 -0400 Received: from mail-out.m-online.net ([212.18.0.10]:57284) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrMiq-0003uo-Qi for 36609@debbugs.gnu.org; Thu, 10 Jun 2021 11:35:57 -0400 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4G17NW5X6Yz1s46H; Thu, 10 Jun 2021 17:35:55 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4G17NW3Ghlz1qr42; Thu, 10 Jun 2021 17:35:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id flt8JSJX9wEm; Thu, 10 Jun 2021 17:35:54 +0200 (CEST) X-Auth-Info: h7NT1Kua0AHy7vYjmAiEIflybecsFG48Bt5VLZNdSU6eZmFFtL4T+4MNmFAbVPdl Received: from igel.home (ppp-46-244-161-203.dynamic.mnet-online.de [46.244.161.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Thu, 10 Jun 2021 17:35:54 +0200 (CEST) Received: by igel.home (Postfix, from userid 1000) id 4B7372C36A1; Thu, 10 Jun 2021 17:35:54 +0200 (CEST) From: Andreas Schwab References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> <83k0n6hjym.fsf@gnu.org> <87wnr2lnsj.fsf@dick> <83h7i6cj3z.fsf@gnu.org> <87bl8e2aya.fsf@dick> <8335tpdcq9.fsf@gnu.org> X-Yow: Once, there was NO fun... This was before MENU planning, FASHION statements or NAUTILUS equipment... Then, in 1985.. FUN was completely encoded in this tiny MICROCHIP.. It contain 14,768 vaguely amusing SIT-COM pilots!! We had to wait FOUR BILLION years but we finally got JERRY LEWIS, MTV and a large selection of cream-filled snack cakes! Date: Thu, 10 Jun 2021 17:35:54 +0200 In-Reply-To: <8335tpdcq9.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 10 Jun 2021 17:18:54 +0300") Message-ID: <8735tpivfp.fsf@igel.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.4 (/) 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.4 (-) On Jun 10 2021, Eli Zaretskii wrote: > The idea is that a variable that is modified in a single machine > instruction will always have the value assigned by the last thread > which set that. You cannot have that without explicit atomic operations. An ordinary RMW access is never atomic across cpus. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Jun 2021 15:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: Andreas Schwab Cc: dick.r.chiang@gmail.com, 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162333960915493 (code B ref 36609); Thu, 10 Jun 2021 15:41:01 +0000 Received: (at 36609) by debbugs.gnu.org; 10 Jun 2021 15:40:09 +0000 Received: from localhost ([127.0.0.1]:37613 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrMmv-00041p-2E for submit@debbugs.gnu.org; Thu, 10 Jun 2021 11:40:09 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59784) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrMmt-00041b-Kq for 36609@debbugs.gnu.org; Thu, 10 Jun 2021 11:40:08 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55382) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrMmn-0001ly-Pi; Thu, 10 Jun 2021 11:40:01 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1281 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 1lrMmn-0007gm-9Q; Thu, 10 Jun 2021 11:40:01 -0400 Date: Thu, 10 Jun 2021 18:39:50 +0300 Message-Id: <83mtrxbuex.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <8735tpivfp.fsf@igel.home> (message from Andreas Schwab on Thu, 10 Jun 2021 17:35:54 +0200) References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> <83k0n6hjym.fsf@gnu.org> <87wnr2lnsj.fsf@dick> <83h7i6cj3z.fsf@gnu.org> <87bl8e2aya.fsf@dick> <8335tpdcq9.fsf@gnu.org> <8735tpivfp.fsf@igel.home> X-Spam-Score: -2.3 (--) 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: Andreas Schwab > Cc: dick.r.chiang@gmail.com, 36609@debbugs.gnu.org > Date: Thu, 10 Jun 2021 17:35:54 +0200 > > On Jun 10 2021, Eli Zaretskii wrote: > > > The idea is that a variable that is modified in a single machine > > instruction will always have the value assigned by the last thread > > which set that. > > You cannot have that without explicit atomic operations. We can do that if it turns out to be an issue. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: dick.r.chiang@gmail.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Jun 2021 21:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: Eli Zaretskii Cc: 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162336098315098 (code B ref 36609); Thu, 10 Jun 2021 21:37:01 +0000 Received: (at 36609) by debbugs.gnu.org; 10 Jun 2021 21:36:23 +0000 Received: from localhost ([127.0.0.1]:37797 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrSLf-0003vS-3s for submit@debbugs.gnu.org; Thu, 10 Jun 2021 17:36:23 -0400 Received: from mail-qt1-f173.google.com ([209.85.160.173]:37887) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrSLc-0003vE-W5 for 36609@debbugs.gnu.org; Thu, 10 Jun 2021 17:36:22 -0400 Received: by mail-qt1-f173.google.com with SMTP id z4so1064534qts.4 for <36609@debbugs.gnu.org>; Thu, 10 Jun 2021 14:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=0ZH89Vj7j6odIvyduAJG68+HtDSia+Pi5R1a42OHtaI=; b=ZUwRhxJMGzkvdHjd5XP22ZM3kAYS4SctoAfkrg1p58rgt50ywhRv0KnEAoqI7kfrBl YjVFz43OpxQY+VUkqGg+A4y8+TXlsWGwf3tQNoMdhLLzxDoPRDl/THw6WclP1tToJG2u Y9ZTgK5nj+bdWbiVbA5YKtD2zUhXE+rPXluN6EZVlb66W8ZE7EHZM7/zB4+XGGgfuRSN fC31GXdEd6tPxIBirzaYZXl/ORBU1dfQMaC0NDd/jLNUKiy0uAnx/5rsmnLUFsiTS1/l KTxnVsoB5C/fHvKW3zwUr/XjWygA9kTFtOLw4NreC+/1vsZOeuVlWBP3KcJAuuOkmxBV 1dVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=0ZH89Vj7j6odIvyduAJG68+HtDSia+Pi5R1a42OHtaI=; b=I4lgSJEkfTPlJmDKu9nhomkmjrbTwYh2zUvNvszn/Y1oz9r3G5ZRIsmt8VkTBRTX7S pXSxiVcMlrZGgm1Ded3D6ot+wHwj9MMlUE83w4KmNZa39L4X4Uq4sdykiPqnY+V3Hpia aGiw0yhFSoe8lN5ctm4SOoki34OAEm7oJAg57oypHTmrYrU/WWs+aQaEiNRSPzGi4f6K SYI6Qr8VtsPSfIl1gRJxvQlnMXv3ZZjO+iRVdjaXgCbol6y4oxaT1Yw4sZVFCz0Kc7Nd 35P5OnlDyOkUG/MoFWwXbXnNFB7mPZ1Zn53STju9FGOkQW+sjqpR3yy17IOL+nIdtHbl vCSQ== X-Gm-Message-State: AOAM533iZHuXHzVFZ1yva5kW/VtafzwnzwCd8iVquxscDy9gcmWN3p3B yjaSOGyKji7XPUZmmactwjM= X-Google-Smtp-Source: ABdhPJzi2xgljXTCJvP2pHu3r8/h1IXtGLY5FdJz70IkN8WAXEq0rAwymQ+F9nvf/VvFonA4NaMGiw== X-Received: by 2002:ac8:7357:: with SMTP id q23mr936321qtp.226.1623360974986; Thu, 10 Jun 2021 14:36:14 -0700 (PDT) Received: from localhost (pool-71-190-212-171.nycmny.fios.verizon.net. [71.190.212.171]) by smtp.gmail.com with ESMTPSA id m19sm2937512qtp.93.2021.06.10.14.36.13 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 10 Jun 2021 14:36:14 -0700 (PDT) From: dick.r.chiang@gmail.com References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> <83k0n6hjym.fsf@gnu.org> <87wnr2lnsj.fsf@dick> <83h7i6cj3z.fsf@gnu.org> <87bl8e2aya.fsf@dick> <8335tpdcq9.fsf@gnu.org> <87y2bhepl2.fsf@dick> <83y2bhbw14.fsf@gnu.org> Date: Thu, 10 Jun 2021 17:36:13 -0400 In-Reply-To: <83y2bhbw14.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 10 Jun 2021 18:04:55 +0300") Message-ID: <87czstmmgi.fsf@dick> User-Agent: Gnus/5.14 (Gnus v5.14pre) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) 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 (-) EZ> Is it, really? Yes. While I can't claim to be any more knowledgeable, the naivete of someone protesting thread atomicity based on word-size is stunningly apparent. EZ> And you can show a GDB backtrace with values of the variable that supports EZ> that? Alas I cannot. My gdb skills are less impressive in the presence of threads, and heisenbugs of this nature tend to mysteriously disappear when gdb's leisurely pace gives caches ample time to flush. I mentioned earlier I could not reproduce my MRE failure when I merely inserted print statements. My patch isn't quite as studied as Pip Cet's (my patch merely skirts locking the glib unless you're main-thread-p), but it does fix OP and, unlike the current state of the code, doesn't admit glaring theoretical flaws, even though you seem to think those flaws could never materialize in practice despite evidence (gdb-less as it is) to the contrary. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Jun 2021 06:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: dick.r.chiang@gmail.com Cc: 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162339122429598 (code B ref 36609); Fri, 11 Jun 2021 06:01:01 +0000 Received: (at 36609) by debbugs.gnu.org; 11 Jun 2021 06:00:24 +0000 Received: from localhost ([127.0.0.1]:38007 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lraDQ-0007hK-LW for submit@debbugs.gnu.org; Fri, 11 Jun 2021 02:00:24 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40040) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lraDO-0007h7-OK for 36609@debbugs.gnu.org; Fri, 11 Jun 2021 02:00:23 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49978) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lraDJ-0001j6-Es; Fri, 11 Jun 2021 02:00:17 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2927 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 1lraDJ-0004w4-0J; Fri, 11 Jun 2021 02:00:17 -0400 Date: Fri, 11 Jun 2021 09:00:07 +0300 Message-Id: <83zgvx9c0o.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87czstmmgi.fsf@dick> (dick.r.chiang@gmail.com) References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> <83k0n6hjym.fsf@gnu.org> <87wnr2lnsj.fsf@dick> <83h7i6cj3z.fsf@gnu.org> <87bl8e2aya.fsf@dick> <8335tpdcq9.fsf@gnu.org> <87y2bhepl2.fsf@dick> <83y2bhbw14.fsf@gnu.org> <87czstmmgi.fsf@dick> X-Spam-Score: -2.3 (--) 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: dick.r.chiang@gmail.com > Cc: 36609@debbugs.gnu.org > Date: Thu, 10 Jun 2021 17:36:13 -0400 > > EZ> Is it, really? > > Yes. While I can't claim to be any more knowledgeable, the naivete of someone > protesting thread atomicity based on word-size is stunningly apparent. I'm okay with replacing the simple increments and decrements of that variable with atomic ones, using the likes of __atomic_fetch_add intrinsics of GCC, if that solves the problem. Did you try that? From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Jun 2021 17:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: dick.r.chiang@gmail.com Cc: 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162412519314204 (code B ref 36609); Sat, 19 Jun 2021 17:54:01 +0000 Received: (at 36609) by debbugs.gnu.org; 19 Jun 2021 17:53:13 +0000 Received: from localhost ([127.0.0.1]:60768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1luf9d-0003h1-Mb for submit@debbugs.gnu.org; Sat, 19 Jun 2021 13:53:13 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34594) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1luf9b-0003gn-Sn for 36609@debbugs.gnu.org; Sat, 19 Jun 2021 13:53:12 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44384) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1luf9V-0004aq-Ma; Sat, 19 Jun 2021 13:53:06 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2085 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 1luf9V-00020Z-AO; Sat, 19 Jun 2021 13:53:05 -0400 Date: Sat, 19 Jun 2021 20:53:15 +0300 Message-Id: <83y2b5vj04.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <83zgvx9c0o.fsf@gnu.org> (message from Eli Zaretskii on Fri, 11 Jun 2021 09:00:07 +0300) References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> <83k0n6hjym.fsf@gnu.org> <87wnr2lnsj.fsf@dick> <83h7i6cj3z.fsf@gnu.org> <87bl8e2aya.fsf@dick> <8335tpdcq9.fsf@gnu.org> <87y2bhepl2.fsf@dick> <83y2bhbw14.fsf@gnu.org> <87czstmmgi.fsf@dick> <83zgvx9c0o.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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 (---) > Date: Fri, 11 Jun 2021 09:00:07 +0300 > From: Eli Zaretskii > Cc: 36609@debbugs.gnu.org > > I'm okay with replacing the simple increments and decrements of that > variable with atomic ones, using the likes of __atomic_fetch_add > intrinsics of GCC, if that solves the problem. Did you try that? Ping! Did you try that, and if so, did using the atomics solve the original problem? Thanks. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: dick.r.chiang@gmail.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Jun 2021 19:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: Eli Zaretskii Cc: 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162413006721565 (code B ref 36609); Sat, 19 Jun 2021 19:15:02 +0000 Received: (at 36609) by debbugs.gnu.org; 19 Jun 2021 19:14:27 +0000 Received: from localhost ([127.0.0.1]:60830 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lugQF-0005bk-Iu for submit@debbugs.gnu.org; Sat, 19 Jun 2021 15:14:27 -0400 Received: from mail-qt1-f173.google.com ([209.85.160.173]:46754) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lugQE-0005bX-CB for 36609@debbugs.gnu.org; Sat, 19 Jun 2021 15:14:26 -0400 Received: by mail-qt1-f173.google.com with SMTP id w26so4935536qto.13 for <36609@debbugs.gnu.org>; Sat, 19 Jun 2021 12:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=E4HfgGnyfJi8L8STKd0/XGbzR5GoJv+Mv8dv2Km8zwg=; b=gRNeOU16GpZP0v+4dzPPtcg2YpP8j8ePhij+G3T2WmYeGVuZjuEMc+1lx+3BqKobXN DBYcLzNK4eVxpTwG2+4THjwguubfEqQLFnNQfNEU6mAB3YlLqnJB/x8rn4dgAdIZYx3k TP7hbsJH67EwbjoJWrebYUAmws8U6E0TN55OXol+4FqhjTUllBHSEENzlnXqyZPqVNFx WKiI64IDUI0x2HBv88dfVtDrzZ76n9TRHh+wNjACT7iBBI6iDoxKL0Ngsicm0k+8Z9J6 DnTMk3V/d4ulHBamY9E4MPYorbeK3gkdEIgK0LRdVR+kZEHNhbcNeyZqt76ejtzpUnZw J5rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=E4HfgGnyfJi8L8STKd0/XGbzR5GoJv+Mv8dv2Km8zwg=; b=lFc/Djl4L7V1Tz8XQHXlqDF+jw2nEOowSfkSMCvlUw9VivMWy8tT6AAonadol/Gc/g OtKgzZBKHrsjvZX1WKZfdQZkPvTjsGQPiDJBgTU1hr23dvM6NjMBq9bdQCa9FL/iFv6q RqFe6bpxovFkzWpP89foKXCd5luknis5QKJ3MnoovC0tJ0JX/afSwFTTwrinvJztfGSu HaflgB5shSCWZ2Qsnt2tMG2oeKaaYsylK0HdFXz4vR6KBmwCddpqmaOT1FenR8HUv17g eNxk6m9Kdjw5VUzJ5G5mn9bPR0Vd71Lbht1Bs+90FXHNMVyjv4feNmKBu9Ch8TbG2h3U ks9w== X-Gm-Message-State: AOAM533JRzW4dtkiJFZKID8Mh8o1p6isytYqiza05yRwdaYLqAOUsFBw sQSE1haAdzu/x8yYZJUUbwA= X-Google-Smtp-Source: ABdhPJy9l0AtPw1ltITISQRr6TndMBYUQ55JtaS0Ynwj+49iM/PW90enESQRtt09s+4e4uRDDxUX4g== X-Received: by 2002:ac8:7f42:: with SMTP id g2mr15846235qtk.280.1624130060836; Sat, 19 Jun 2021 12:14:20 -0700 (PDT) Received: from localhost (pool-71-190-212-171.nycmny.fios.verizon.net. [71.190.212.171]) by smtp.gmail.com with ESMTPSA id x8sm6649975qkh.130.2021.06.19.12.14.20 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sat, 19 Jun 2021 12:14:20 -0700 (PDT) From: dick.r.chiang@gmail.com References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> <83k0n6hjym.fsf@gnu.org> <87wnr2lnsj.fsf@dick> <83h7i6cj3z.fsf@gnu.org> <87bl8e2aya.fsf@dick> <8335tpdcq9.fsf@gnu.org> <87y2bhepl2.fsf@dick> <83y2bhbw14.fsf@gnu.org> <87czstmmgi.fsf@dick> <83zgvx9c0o.fsf@gnu.org> <83y2b5vj04.fsf@gnu.org> Date: Sat, 19 Jun 2021 15:14:19 -0400 In-Reply-To: <83y2b5vj04.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 19 Jun 2021 20:53:15 +0300") Message-ID: <87sg1dwttg.fsf@dick> User-Agent: Gnus/5.14 (Gnus v5.14pre) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) 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 (-) I enter a plea of lacking the programming know-how for atomics. I stand by everything I've said thus far: an obfuscated MRE led to a misdiagnosis, led to an unnecessary and highly thread-unsafe fix, which can be remedied by the vulgar "end-run" patch I submitted, and which I test every day with parallel-thread Gnus. Unfortunately in this and every urological contest of wills I seem to have with project maintainers, I, by construction, must always lose. >>>>> Eli Zaretskii writes: >> Date: Fri, 11 Jun 2021 09:00:07 +0300 >> From: Eli Zaretskii >> Cc: 36609@debbugs.gnu.org >> >> I'm okay with replacing the simple increments and decrements of that >> variable with atomic ones, using the likes of __atomic_fetch_add >> intrinsics of GCC, if that solves the problem. Did you try that? > Ping! > Did you try that, and if so, did using the atomics solve the original > problem? > Thanks. From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Jun 2021 19:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: dick.r.chiang@gmail.com Cc: 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162413032321965 (code B ref 36609); Sat, 19 Jun 2021 19:19:01 +0000 Received: (at 36609) by debbugs.gnu.org; 19 Jun 2021 19:18:43 +0000 Received: from localhost ([127.0.0.1]:60835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lugUN-0005iD-4m for submit@debbugs.gnu.org; Sat, 19 Jun 2021 15:18:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44338) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lugUL-0005i1-8e for 36609@debbugs.gnu.org; Sat, 19 Jun 2021 15:18:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46494) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lugUF-0000AT-Rr; Sat, 19 Jun 2021 15:18:35 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3371 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 1lugUF-00039g-BK; Sat, 19 Jun 2021 15:18:35 -0400 Date: Sat, 19 Jun 2021 22:18:43 +0300 Message-Id: <83tultvf1o.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87sg1dwttg.fsf@dick> (dick.r.chiang@gmail.com) References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> <83k0n6hjym.fsf@gnu.org> <87wnr2lnsj.fsf@dick> <83h7i6cj3z.fsf@gnu.org> <87bl8e2aya.fsf@dick> <8335tpdcq9.fsf@gnu.org> <87y2bhepl2.fsf@dick> <83y2bhbw14.fsf@gnu.org> <87czstmmgi.fsf@dick> <83zgvx9c0o.fsf@gnu.org> <83y2b5vj04.fsf@gnu.org> <87sg1dwttg.fsf@dick> X-Spam-Score: -2.3 (--) 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: dick.r.chiang@gmail.com > Cc: 36609@debbugs.gnu.org > Date: Sat, 19 Jun 2021 15:14:19 -0400 > > I enter a plea of lacking the programming know-how for atomics. If I suggest a patch, would you be willing to give it a try? From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: dick.r.chiang@gmail.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Jun 2021 21:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: Eli Zaretskii Cc: 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162413716117166 (code B ref 36609); Sat, 19 Jun 2021 21:13:01 +0000 Received: (at 36609) by debbugs.gnu.org; 19 Jun 2021 21:12:41 +0000 Received: from localhost ([127.0.0.1]:60897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1luiGe-0004So-Ux for submit@debbugs.gnu.org; Sat, 19 Jun 2021 17:12:41 -0400 Received: from mail-qt1-f176.google.com ([209.85.160.176]:43727) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1luiGd-0004Sb-5t for 36609@debbugs.gnu.org; Sat, 19 Jun 2021 17:12:39 -0400 Received: by mail-qt1-f176.google.com with SMTP id l2so7607535qtq.10 for <36609@debbugs.gnu.org>; Sat, 19 Jun 2021 14:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=r5EG1iD3lpXRhTSgVjO6CcjGgqL+xbWbAEeSM+nbyEQ=; b=YG8IuLmprslX91ZtJykpl5Eu7KrW9W1gi5Kc865ZAvsqivTeYyK2mTppQ8t1A3LM77 BFZoAN14ojsC3GWah9bISnApwtKHre6HIkUf2HOyrN/Yk9lfEYrJYe4S6Bw1m0knDYhE QOYiMoOuQzpZ6XeYqrnYN1Fqhn5Al+G35AqEji/QStmHXzozq1uKRA22TXRZ5mLiJqvQ nS0YJkOF1k2O4UnoyGeSJ0GA/IkRDR0N67U8bGVoFrxd/26PxvWUKFs/ctJR3MZW+czU Y+gem/lxeKf3aSv8eaL1Q0luijW3+C+4prYqMoVfhIUk7e5uzCDrtxOBsw5K7uzSQBcw PMQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=r5EG1iD3lpXRhTSgVjO6CcjGgqL+xbWbAEeSM+nbyEQ=; b=d/m22xRYAKtj12NeU2gy4eO3VFyiwiwJ9HkVurjRCNfCQd3DIac3TcF3qvwM6nBEHt 6WOMUA7/HPwvYlqVBKCMd/AX4ed8cGcCmXxUCvpkY9tmIQHcDotHVW4rDXK32aitEn8Z cnc34kWWcKNlSnnp8iA23BTIeQrlXHZ0Qx3V7xlBPZXGYY13arFlpKm2X6+bOksCpCRz yVowuvs2vPOgd8G2ZVFoa/NirapNFZQlP8yazCzH1PtS5uYlgfwFZ0Fw7S/8cQ6xNwtJ +6oK9qdFr0117OmyqzxO6ZATAetenuTBIAQfoNIxLciJBzESR5WWIbrPgMWgJWI7NKTI chGQ== X-Gm-Message-State: AOAM533mkly101JaDVUwKG6duIIIcTGgrbaN2sLemVrsOBJiPePttzzb 2cZIuq3dNryxlvyxo12HxTg= X-Google-Smtp-Source: ABdhPJxVYu+3Lsobnxsgh+IApSg4fiwf5jdXg191eqE9SUORokM/7Bokwl+R7s0DRUSqY9bVRjHBqQ== X-Received: by 2002:ac8:1483:: with SMTP id l3mr16581320qtj.142.1624137153665; Sat, 19 Jun 2021 14:12:33 -0700 (PDT) Received: from localhost (pool-71-190-212-171.nycmny.fios.verizon.net. [71.190.212.171]) by smtp.gmail.com with ESMTPSA id b7sm7586749qti.21.2021.06.19.14.12.32 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sat, 19 Jun 2021 14:12:33 -0700 (PDT) From: dick.r.chiang@gmail.com References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> <83k0n6hjym.fsf@gnu.org> <87wnr2lnsj.fsf@dick> <83h7i6cj3z.fsf@gnu.org> <87bl8e2aya.fsf@dick> <8335tpdcq9.fsf@gnu.org> <87y2bhepl2.fsf@dick> <83y2bhbw14.fsf@gnu.org> <87czstmmgi.fsf@dick> <83zgvx9c0o.fsf@gnu.org> <83y2b5vj04.fsf@gnu.org> <87sg1dwttg.fsf@dick> <83tultvf1o.fsf@gnu.org> Date: Sat, 19 Jun 2021 17:12:32 -0400 In-Reply-To: <83tultvf1o.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 19 Jun 2021 22:18:43 +0300") Message-ID: <87o8c1wocf.fsf@dick> User-Agent: Gnus/5.14 (Gnus v5.14pre) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) 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 (-) "Suggest" or "Provide"? If the former, well, my recalcitrance should be your answer. If the latter, sure, although if you've written the patch, then running my MREs would be epsilon more effort. >>>>> Eli Zaretskii writes: >> From: dick.r.chiang@gmail.com >> Cc: 36609@debbugs.gnu.org >> Date: Sat, 19 Jun 2021 15:14:19 -0400 >> >> I enter a plea of lacking the programming know-how for atomics. > If I suggest a patch, would you be willing to give it a try? From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Jun 2021 11:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: dick.r.chiang@gmail.com Cc: 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.16241891676011 (code B ref 36609); Sun, 20 Jun 2021 11:40:02 +0000 Received: (at 36609) by debbugs.gnu.org; 20 Jun 2021 11:39:27 +0000 Received: from localhost ([127.0.0.1]:33182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1luvnT-0001Yt-Cr for submit@debbugs.gnu.org; Sun, 20 Jun 2021 07:39:27 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56402) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1luvnS-0001Yh-EG for 36609@debbugs.gnu.org; Sun, 20 Jun 2021 07:39:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36962) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1luvnN-0003uf-4c; Sun, 20 Jun 2021 07:39:21 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4156 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 1luvnM-0000fV-LW; Sun, 20 Jun 2021 07:39:20 -0400 Date: Sun, 20 Jun 2021 14:39:31 +0300 Message-Id: <837diovk7g.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87o8c1wocf.fsf@dick> (dick.r.chiang@gmail.com) References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> <83k0n6hjym.fsf@gnu.org> <87wnr2lnsj.fsf@dick> <83h7i6cj3z.fsf@gnu.org> <87bl8e2aya.fsf@dick> <8335tpdcq9.fsf@gnu.org> <87y2bhepl2.fsf@dick> <83y2bhbw14.fsf@gnu.org> <87czstmmgi.fsf@dick> <83zgvx9c0o.fsf@gnu.org> <83y2b5vj04.fsf@gnu.org> <87sg1dwttg.fsf@dick> <83tultvf1o.fsf@gnu.org> <87o8c1wocf.fsf@dick> X-Spam-Score: -2.3 (--) 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: dick.r.chiang@gmail.com > Cc: 36609@debbugs.gnu.org > Date: Sat, 19 Jun 2021 17:12:32 -0400 > > "Suggest" or "Provide"? > > If the former, well, my recalcitrance should be your answer. > > If the latter, sure Thanks, please try the patch below. > although if you've written the patch, then running my MREs would be > epsilon more effort. You have a use case and wrote code with which you are familiar, so you are in a better position to test it. Moreover, I don't have access to a system where these problems could happen, so it's far from epsilon effort for me. diff --git a/src/xgselect.c b/src/xgselect.c index 0d91d55bad..9a90670b0f 100644 --- a/src/xgselect.c +++ b/src/xgselect.c @@ -34,12 +34,27 @@ static GMainContext *glib_main_context; void release_select_lock (void) { +#if GNUC_PREREQ (4, 7, 0) + if (__atomic_sub_fetch (&threads_holding_glib_lock, 1, __ATOMIC_ACQ_REL)) + g_main_context_release (glib_main_context); +#else if (--threads_holding_glib_lock == 0) g_main_context_release (glib_main_context); +#endif } static void acquire_select_lock (GMainContext *context) { +#if GNUC_PREREQ (4, 7, 0) + if (__atomic_fetch_add (&threads_holding_glib_lock, 1, __ATOMIC_ACQ_REL) == 0) + { + glib_main_context = context; + while (!g_main_context_acquire (context)) + { + /* Spin. */ + } + } +#else if (threads_holding_glib_lock++ == 0) { glib_main_context = context; @@ -48,6 +63,7 @@ static void acquire_select_lock (GMainContext *context) /* Spin. */ } } +#endif } /* `xg_select' is a `pselect' replacement. Why do we need a separate function? From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: dick.r.chiang@gmail.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Jun 2021 14:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: Eli Zaretskii Cc: 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162419770720199 (code B ref 36609); Sun, 20 Jun 2021 14:02:02 +0000 Received: (at 36609) by debbugs.gnu.org; 20 Jun 2021 14:01:47 +0000 Received: from localhost ([127.0.0.1]:34743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1luy1D-0005Fj-AC for submit@debbugs.gnu.org; Sun, 20 Jun 2021 10:01:47 -0400 Received: from mail-qk1-f178.google.com ([209.85.222.178]:43634) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1luy1A-0005FW-VQ for 36609@debbugs.gnu.org; Sun, 20 Jun 2021 10:01:46 -0400 Received: by mail-qk1-f178.google.com with SMTP id j62so23632729qke.10 for <36609@debbugs.gnu.org>; Sun, 20 Jun 2021 07:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=d29ynUKRA/9ZTJSxQg09rXyfp+lCfQhpsWgvUa6CU5g=; b=PpjTtgkoY/z3lmc6Kv350nG2CWK1DmA53JzSnXce6Ss7emwDbw5yZNbnwGwxS6c00K KiaclqLnUa6DsBYfVI1N12feKcIgk8Rndqy11CmavCjXyzXqiNPZwVBjEEVPsgJz/1L8 X1Ba7o9Gpe7+L/4LLXsetjsjJdAMvcCprMqKM2yvfDTWvIJahHycSx2YnIy2OtWioxt5 uvdw8gZ0qvptw+ePQmgY1E3DcHksBVPYB0Mjiz+14Va2VXV2mpDlqEmr/YKvsczR2kyS CgrNX9KXvDakF55haSNjboXvClVbjfO2X5uokhjqDE/oW1Z1oud9yISKfYB4lOsN2AEU upfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=d29ynUKRA/9ZTJSxQg09rXyfp+lCfQhpsWgvUa6CU5g=; b=XdaojH3BUWqK7R2GUx4Su54UbDNQ0/1MYSUrhXuSjEZ+PhGJedqOYMad9tcrKPLe0g m/RE6JXtREGNPlDyPi1APyI9Ug1FXsFioGZ6+Sf8DoAp4eELZiQqUpw99oNXOPFjjzsr AkaF9JfGf+upAs8B7XnSpLONWJN571+DxMMUFyZ+r/FMREfiDCz7Tp2VYdE8qotXpD/4 b8uhvrIXVqPLca9967MYcnRkUi1s2l+vu+3JSzZBOIIOTbNPt5tbg6/fKldNUwK0SnAj UTf4Bilj+hnXpKpK1+ghJO5pT7HQTaJxHME6h/IM/QWziSxxfyJuUniMtL5vqiXU5O95 HryQ== X-Gm-Message-State: AOAM531afR5eldhrm6YFrW9qHQKeSmsRxi0Kuw9/VqdTK0XN7Dlfyt4G xCSKhJX8+UeqfgpphsLsj+M= X-Google-Smtp-Source: ABdhPJwf52HOC3YNWLRTq6BSfdXyPyBkjYSYIbnFUEJXAgUFQfNv7xWmWjnbjrBVBRX+J9QGLS1L8Q== X-Received: by 2002:a05:620a:29d3:: with SMTP id s19mr18237743qkp.434.1624197699164; Sun, 20 Jun 2021 07:01:39 -0700 (PDT) Received: from localhost (pool-71-190-212-171.nycmny.fios.verizon.net. [71.190.212.171]) by smtp.gmail.com with ESMTPSA id 18sm4798443qkk.103.2021.06.20.07.01.38 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sun, 20 Jun 2021 07:01:38 -0700 (PDT) From: dick.r.chiang@gmail.com References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> <83k0n6hjym.fsf@gnu.org> <87wnr2lnsj.fsf@dick> <83h7i6cj3z.fsf@gnu.org> <87bl8e2aya.fsf@dick> <8335tpdcq9.fsf@gnu.org> <87y2bhepl2.fsf@dick> <83y2bhbw14.fsf@gnu.org> <87czstmmgi.fsf@dick> <83zgvx9c0o.fsf@gnu.org> <83y2b5vj04.fsf@gnu.org> <87sg1dwttg.fsf@dick> <83tultvf1o.fsf@gnu.org> <87o8c1wocf.fsf@dick> <837diovk7g.fsf@gnu.org> Date: Sun, 20 Jun 2021 10:01:37 -0400 In-Reply-To: <837diovk7g.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 20 Jun 2021 14:39:31 +0300") Message-ID: <87fsxcws72.fsf@dick> User-Agent: Gnus/5.14 (Gnus v5.14pre) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) 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 (-) Yes! If you just add a negation to the __atomic_sub_fetch call, this passes all the MREs. It's not clear how you want to deal with the #else GNUC_PREREQ (4, 7, 0). >>>>> "EZ" == Eli Zaretskii writes: >> From: dick.r.chiang@gmail.com >> Cc: 36609@debbugs.gnu.org >> Date: Sat, 19 Jun 2021 17:12:32 -0400 >> >> "Suggest" or "Provide"? >> >> If the former, well, my recalcitrance should be your answer. >> >> If the latter, sure EZ> Thanks, please try the patch below. >> although if you've written the patch, then running my MREs would be epsilon >> more effort. EZ> You have a use case and wrote code with which you are familiar, so you are EZ> in a better position to test it. Moreover, I don't have access to a EZ> system where these problems could happen, so it's far from epsilon effort EZ> for me. EZ> diff --git a/src/xgselect.c b/src/xgselect.c EZ> index 0d91d55bad..9a90670b0f 100644 EZ> --- a/src/xgselect.c EZ> +++ b/src/xgselect.c EZ> @@ -34,12 +34,27 @@ static GMainContext *glib_main_context; EZ> void release_select_lock (void) EZ> { EZ> +#if GNUC_PREREQ (4, 7, 0) EZ> + if (__atomic_sub_fetch (&threads_holding_glib_lock, 1, __ATOMIC_ACQ_REL)) EZ> + g_main_context_release (glib_main_context); EZ> +#else EZ> if (--threads_holding_glib_lock == 0) EZ> g_main_context_release (glib_main_context); EZ> +#endif EZ> } EZ> static void acquire_select_lock (GMainContext *context) EZ> { EZ> +#if GNUC_PREREQ (4, 7, 0) EZ> + if (__atomic_fetch_add (&threads_holding_glib_lock, 1, __ATOMIC_ACQ_REL) == 0) EZ> + { EZ> + glib_main_context = context; EZ> + while (!g_main_context_acquire (context)) EZ> + { EZ> + /* Spin. */ EZ> + } EZ> + } EZ> +#else EZ> if (threads_holding_glib_lock++ == 0) EZ> { EZ> glib_main_context = context; EZ> @@ -48,6 +63,7 @@ static void acquire_select_lock (GMainContext *context) EZ> /* Spin. */ EZ> } EZ> } EZ> +#endif EZ> } EZ> /* `xg_select' is a `pselect' replacement. Why do we need a separate EZ> function? From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Jun 2021 15:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: dick.r.chiang@gmail.com Cc: 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162420441731245 (code B ref 36609); Sun, 20 Jun 2021 15:54:01 +0000 Received: (at 36609) by debbugs.gnu.org; 20 Jun 2021 15:53:37 +0000 Received: from localhost ([127.0.0.1]:34833 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1luzlR-00087t-BR for submit@debbugs.gnu.org; Sun, 20 Jun 2021 11:53:37 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57190) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1luzlP-00087d-Dm for 36609@debbugs.gnu.org; Sun, 20 Jun 2021 11:53:35 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42412) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1luzlK-0007R9-4b; Sun, 20 Jun 2021 11:53:30 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4149 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 1luzlJ-0000sC-MQ; Sun, 20 Jun 2021 11:53:30 -0400 Date: Sun, 20 Jun 2021 18:53:40 +0300 Message-Id: <834kdsv8fv.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87fsxcws72.fsf@dick> (dick.r.chiang@gmail.com) References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> <83k0n6hjym.fsf@gnu.org> <87wnr2lnsj.fsf@dick> <83h7i6cj3z.fsf@gnu.org> <87bl8e2aya.fsf@dick> <8335tpdcq9.fsf@gnu.org> <87y2bhepl2.fsf@dick> <83y2bhbw14.fsf@gnu.org> <87czstmmgi.fsf@dick> <83zgvx9c0o.fsf@gnu.org> <83y2b5vj04.fsf@gnu.org> <87sg1dwttg.fsf@dick> <83tultvf1o.fsf@gnu.org> <87o8c1wocf.fsf@dick> <837diovk7g.fsf@gnu.org> <87fsxcws72.fsf@dick> X-Spam-Score: -2.3 (--) 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: dick.r.chiang@gmail.com > Cc: 36609@debbugs.gnu.org > Date: Sun, 20 Jun 2021 10:01:37 -0400 > > Yes! If you just add a negation to the __atomic_sub_fetch call You mean, use the patch below instead? > this passes all the MREs. Thanks, will install soon. > It's not clear how you want to deal with the #else GNUC_PREREQ (4, 7, 0). By hoping no one uses this and expects threads to be stable enough under GTK. diff --git a/src/xgselect.c b/src/xgselect.c index 0d91d55bad..92b118b955 100644 --- a/src/xgselect.c +++ b/src/xgselect.c @@ -34,12 +34,27 @@ static GMainContext *glib_main_context; void release_select_lock (void) { +#if GNUC_PREREQ (4, 7, 0) + if (__atomic_sub_fetch (&threads_holding_glib_lock, 1, __ATOMIC_ACQ_REL) == 0) + g_main_context_release (glib_main_context); +#else if (--threads_holding_glib_lock == 0) g_main_context_release (glib_main_context); +#endif } static void acquire_select_lock (GMainContext *context) { +#if GNUC_PREREQ (4, 7, 0) + if (__atomic_fetch_add (&threads_holding_glib_lock, 1, __ATOMIC_ACQ_REL) == 0) + { + glib_main_context = context; + while (!g_main_context_acquire (context)) + { + /* Spin. */ + } + } +#else if (threads_holding_glib_lock++ == 0) { glib_main_context = context; @@ -48,6 +63,7 @@ static void acquire_select_lock (GMainContext *context) /* Spin. */ } } +#endif } /* `xg_select' is a `pselect' replacement. Why do we need a separate function? From unknown Tue Aug 19 12:51:02 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Jun 2021 13:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed To: dick.r.chiang@gmail.com Cc: 36609@debbugs.gnu.org Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.162462927318400 (code B ref 36609); Fri, 25 Jun 2021 13:55:02 +0000 Received: (at 36609) by debbugs.gnu.org; 25 Jun 2021 13:54:33 +0000 Received: from localhost ([127.0.0.1]:45166 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lwmHx-0004mi-0Q for submit@debbugs.gnu.org; Fri, 25 Jun 2021 09:54:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57768) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lwmHv-0004mW-PG for 36609@debbugs.gnu.org; Fri, 25 Jun 2021 09:54:32 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46538) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lwmHq-0007yz-G8; Fri, 25 Jun 2021 09:54:26 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4768 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 1lwmHq-0004cn-3r; Fri, 25 Jun 2021 09:54:26 -0400 Date: Fri, 25 Jun 2021 16:54:15 +0300 Message-Id: <834kdmrqwo.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <834kdsv8fv.fsf@gnu.org> (message from Eli Zaretskii on Sun, 20 Jun 2021 18:53:40 +0300) References: <87muhks3b5.fsf@hochschule-trier.de> <87fsxv8182.fsf@dick> <83wnr7gdd8.fsf@gnu.org> <875yyqg66k.fsf@dick> <83k0n6hjym.fsf@gnu.org> <87wnr2lnsj.fsf@dick> <83h7i6cj3z.fsf@gnu.org> <87bl8e2aya.fsf@dick> <8335tpdcq9.fsf@gnu.org> <87y2bhepl2.fsf@dick> <83y2bhbw14.fsf@gnu.org> <87czstmmgi.fsf@dick> <83zgvx9c0o.fsf@gnu.org> <83y2b5vj04.fsf@gnu.org> <87sg1dwttg.fsf@dick> <83tultvf1o.fsf@gnu.org> <87o8c1wocf.fsf@dick> <837diovk7g.fsf@gnu.org> <87fsxcws72.fsf@dick> <834kdsv8fv.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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 (---) > Date: Sun, 20 Jun 2021 18:53:40 +0300 > From: Eli Zaretskii > Cc: 36609@debbugs.gnu.org > > > From: dick.r.chiang@gmail.com > > Cc: 36609@debbugs.gnu.org > > Date: Sun, 20 Jun 2021 10:01:37 -0400 > > > > Yes! If you just add a negation to the __atomic_sub_fetch call > > You mean, use the patch below instead? > > > this passes all the MREs. > > Thanks, will install soon. Now done. From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 25 10:33:35 2021 Received: (at control) by debbugs.gnu.org; 25 Jun 2021 14:33:35 +0000 Received: from localhost ([127.0.0.1]:46550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lwmtj-00021T-2M for submit@debbugs.gnu.org; Fri, 25 Jun 2021 10:33:35 -0400 Received: from mail-qt1-f178.google.com ([209.85.160.178]:39906) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lwmth-00021E-Ap for control@debbugs.gnu.org; Fri, 25 Jun 2021 10:33:34 -0400 Received: by mail-qt1-f178.google.com with SMTP id f13so1452651qtb.6 for ; Fri, 25 Jun 2021 07:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:date:to:from:subject; bh=dqHLiGCJzYMyP8sxXuUgicODpTvyOgObKm8jtzhRwVU=; b=emuQHYgqm75okPXmPVGvhoXL0bPLHYrsnTT/JdZ7FH4ViQVCdU23+gpYOH+EjGQCEk NmlOIKZcDtrTDKw70XD8Pt0bgn3yHC5GZr6qy819n03xRBkV+GJSE6o+XIwsYc34PP36 dzVBx3Pxh5YAKyNLEcUCmWL+Ix+ux7ndnOOn5odtuZ71ucC3iG3gsOyId86PflPidwxG E9tIKY7vHpqsRiuvR2Sx4TjrB1tT/JxdE/PW6/Q4KaE/zkx5S5KRj/oleY4b5cQEvxV3 lCXlBk1PwKNkwM3/9DIPvAFctcrB6xdCejwwn7GJ2AEtGxyRbSUXCqHSfTYpbaQXTn8y 49Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:to:from:subject; bh=dqHLiGCJzYMyP8sxXuUgicODpTvyOgObKm8jtzhRwVU=; b=uEDih0WQYOEH/F67LtoVlyuDbKyt+zrQ9Ms7pNuYB6ahriN3psRdFGXDRbVxH07qtH 9GvwL0GOApChGa1CNdidH37JoHCurzihM9MRkdXcrFKYGv3GLGXz7D8QJskCXwszKKFL OEonCKMccSKZPRZ0rvODrXcGBQKHMhOehM6aG6T7mkIOTh7o6G/qHrOQPs0lOkG4IVKb XNRrWmnaiF2r2BScqZHaEamUUnSBZN3BzIF4EB/twsrCOY7mQ5bLs0ijgr7jpTfXFlnF qN/G/DJxUN1tDpdGLNJc/KIZo9eW4WtPfT3hZOfoNqa476NRjbtAcFbljJfMtJDLAcA5 u7Pg== X-Gm-Message-State: AOAM532UxKVcczgHCGEWfzoLWe73SRcYI8rUeqj6XLQoBm3RHsUBkVFE P96SoLOBv3d6ecWfNSvhxO6GwuQpyiM= X-Google-Smtp-Source: ABdhPJySjqGmF2J49k2a3bcoijq09P5PJmZLK7SgfiMAhSDaOD3lVAmYq4wAyJGKd/EkVJmChXUMyw== X-Received: by 2002:ac8:774c:: with SMTP id g12mr9815361qtu.39.1624631607444; Fri, 25 Jun 2021 07:33:27 -0700 (PDT) Received: from localhost (pool-71-190-212-171.nycmny.fios.verizon.net. [71.190.212.171]) by smtp.gmail.com with ESMTPSA id z2sm4966430qkc.111.2021.06.25.07.33.26 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 25 Jun 2021 07:33:27 -0700 (PDT) Message-ID: <60d5e937.1c69fb81.ac8da.0824@mx.google.com> Date: Fri, 25 Jun 2021 10:33:26 -0400 To: control@debbugs.gnu.org From: dick Subject: control message for bug #36609 X-Spam-Score: 0.0 (/) 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: -1.0 (-) close 36609 28.1 quit