From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 24 12:18:53 2016 Received: (at submit) by debbugs.gnu.org; 24 Dec 2016 17:18:53 +0000 Received: from localhost ([127.0.0.1]:53966 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cKpy9-0002i5-43 for submit@debbugs.gnu.org; Sat, 24 Dec 2016 12:18:53 -0500 Received: from eggs.gnu.org ([208.118.235.92]:50434) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cKkDb-0007Cp-L5 for submit@debbugs.gnu.org; Sat, 24 Dec 2016 06:10:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cKkDU-0005dk-Ih for submit@debbugs.gnu.org; Sat, 24 Dec 2016 06:10:22 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:34350) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cKkDU-0005dd-Ea for submit@debbugs.gnu.org; Sat, 24 Dec 2016 06:10:20 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cKkDS-0008RH-E9 for bug-gnu-emacs@gnu.org; Sat, 24 Dec 2016 06:10:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cKkDN-0005cC-9H for bug-gnu-emacs@gnu.org; Sat, 24 Dec 2016 06:10:18 -0500 Received: from [195.159.176.226] (port=33707 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cKkDM-0005bo-VG for bug-gnu-emacs@gnu.org; Sat, 24 Dec 2016 06:10:13 -0500 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cKkDD-0007ep-Cs for bug-gnu-emacs@gnu.org; Sat, 24 Dec 2016 12:10:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: charles@aurox.ch (Charles A. Roelli) Subject: make-thread crashes in OS X 10.6 Date: Sat, 24 Dec 2016 12:06:45 +0100 Lines: 182 Message-ID: Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:nyQbQKgrOEKgAH44gMk6fvK28u4= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Sat, 24 Dec 2016 12:18:52 -0500 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: -5.0 (-----) Running Emacs -Q on the latest commit (e36a3882), M-: (make-thread (lambda () "string")) appears to hang Emacs immediately. Here's the output of "bt" and "thread apply all bt": (gdb) bt #0 0x00000001000cd2b6 in stack_overflow [inlined] () at /Code/emacs-build-threads/src/sysdep.c:1767 #1 0x00000001000cd2b6 in handle_sigsegv (sig=1884515520, siginfo=0x70, arg=0x100621fe8) at sysdep.c:1800 #2 #3 0x000000010012d7dc in unbind_to (count=Cannot access memory at address 0x0 ) at eval.c:3499 #4 0x00000001001af2c4 in ns_select (nfds=1606412240, readfds=0x7fff5fbfeb80, writefds=0x7fff5fbfeb00, exceptfds=0x7fff5fbfe7d0, timeout=0x7fff5fbfe7d0, sigmask=0x7fff5fbfe7d0) at nsterm.m:4210 #5 0x000000010018d210 in really_call_select (arg=0x7fff5fbfe840) at thread.c:520 #6 0x000000010010ca06 in flush_stack_call_func (func=0, arg=0x5fbfeae800000000) at alloc.c:5137 #7 0x000000010018d1a7 in thread_select (func=0x5fbfeae800000000, max_fds=0, rfds=0x7fff5fbfe828, wfds=0x0, efds=0x7fff5fbfeae8, timeout=0x0, sigmask=0x0) at thread.c:543 #8 0x00000001001752ad in wait_reading_process_output (time_limit=140734799801728, nsecs=0, read_kbd=1606413696, wait_for_cell=140734799801728, wait_proc=0x7fff5fbfed80, just_wait_proc=0, do_display=true) at process.c:5344 #9 0x000000010000471a in sit_for (timeout=30, display_option=0, reading=false) at dispnew.c:5763 #10 0x00000001000bf6f2 in read_char (commandflag=1606414816, map=140734799802848, prev_event=4294967295, used_mouse_menu=0x7fff5fbff1e0, end_time=0x7fff5fbff1e0) at keyboard.c:2725 #11 0x00000001000c26ee in read_key_sequence () at keyboard.c:2599 #12 0x00000001000c4afd in command_loop_1 () at keyboard.c:1373 #13 0x000000010012e2a4 in internal_condition_case (bfun=0x1000c3690 , handlers=499667000, hfun=0x7fff5fbff500) at eval.c:1334 #14 0x00000001000c4d50 in command_loop_2 (ignore=499667000) at keyboard.c:1115 #15 0x000000010012e32f in internal_catch (tag=499667000, func=0x1000c4d20 , arg=499667000) at eval.c:1100 #16 0x00000001000c4ec6 in command_loop [inlined] () at /Code/emacs-build-threads/src/keyboard.c:1094 #17 0x00000001000c4ec6 in recursive_edit_1 () at keyboard.c:1800 #18 0x00000001000b60df in Frecursive_edit () at keyboard.c:771 #19 0x00000001000b2993 in main (argc=4002, argv=0x7fff5fbff780) at emacs.c:1691 Program received signal SIGSTOP, Stopped (signal). 0x00007fff838f8430 in malloc_gdb_po_unsafe () Unsafe to run code: malloc zone lock is held for some zone.. Canceling call as the malloc lock is held so it isn't safe to call the runtime. Issue the command: set objc-non-blocking-mode off to override this check if you are sure your call doesn't use the malloc libraries or the ObjC runtime. (gdb) set objc-non-blocking-mode off (gdb) continue Continuing. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000040 0x00000001000cd2b6 in stack_overflow [inlined] () at /Code/emacs-build-threads/src/sysdep.c:1767 1767 char *bot = stack_bottom; (gdb) thread apply all bt Thread 4 (process 17249): #0 0x00007fff8385f932 in select$DARWIN_EXTSN () #1 0x000000010019fa79 in -[EmacsApp fd_handler:] (self=0x8, _cmd=0x102380ad0, unused=0x0) at nsterm.m:5512 #2 0x00007fff89967114 in __NSThread__main__ () #3 0x00007fff83854fd6 in _pthread_start () #4 0x00007fff83854e89 in thread_start () Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000040 [Switching to process 17249 thread 0x903] 0x00000001000cd2b6 in stack_overflow [inlined] () at /Code/emacs-build-threads/src/sysdep.c:1767 1767 char *bot = stack_bottom; The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on" Evaluation of the expression containing the function (backtrace_top) will be abandoned. Thread 3 (process 17249): #0 0x00007fff8385f932 in select$DARWIN_EXTSN () #1 0x0000000100ad3983 in g_poll (fds=0x101a37ce0, nfds=28839360, timeout=0) at gpoll.c:385 #2 0x0000000100ac6dfd in g_main_context_iterate () at gmain.c:3198 #3 0x0000000100ac6ee2 in g_main_context_iteration (context=0x6, may_block=1) at gmain.c:3869 #4 0x0000000100ac5e71 in glib_worker_main (data=0x6) at gmain.c:5622 #5 0x0000000100aeb75a in g_thread_proxy (data=0x6) at gthread.c:764 #6 0x00007fff83854fd6 in _pthread_start () #7 0x00007fff83854e89 in thread_start () Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000040 [Switching to process 17249 thread 0x903] 0x00000001000cd2b6 in stack_overflow [inlined] () at /Code/emacs-build-threads/src/sysdep.c:1767 1767 char *bot = stack_bottom; The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on" Evaluation of the expression containing the function (backtrace_top) will be abandoned. Thread 2 (process 17249): #0 0x00007fff8383544b in pthread_workqueue_additem_np () #1 0x00007fff83834d0a in _dispatch_queue_wakeup_global () #2 0x00007fff83834c28 in _dispatch_wakeup () #3 0x00007fff8394fd3f in _dispatch_queue_push_list_slow () #4 0x00007fff83834c9c in _dispatch_wakeup () #5 0x00007fff8394fd3f in _dispatch_queue_push_list_slow () #6 0x00007fff83834c9c in _dispatch_wakeup () #7 0x00007fff83836ebe in _dispatch_run_timers () #8 0x00007fff83836aa2 in _dispatch_mgr_invoke () #9 0x00007fff838367b4 in _dispatch_queue_invoke () #10 0x00007fff838362de in _dispatch_worker_thread2 () #11 0x00007fff83835c08 in _pthread_wqthread () #12 0x00007fff83835aa5 in start_wqthread () Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000070 backtrace_top () at eval.c:202 202 while (backtrace_p (pdl) && pdl->kind != SPECPDL_BACKTRACE) The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on" Evaluation of the expression containing the function (backtrace_top) will be abandoned. Thread 1 (process 17249): #0 0x00000001000cd2b6 in stack_overflow [inlined] () at /Code/emacs-build-threads/src/sysdep.c:1767 #1 0x00000001000cd2b6 in handle_sigsegv (sig=1884515520, siginfo=0x70, arg=0x100621fe8) at sysdep.c:1800 #2 #3 0x000000010012d7dc in unbind_to (count=Cannot access memory at address 0x0 ) at eval.c:3499 #4 0x00000001001af2c4 in ns_select (nfds=1606412240, readfds=0x7fff5fbfeb80, writefds=0x7fff5fbfeb00, exceptfds=0x7fff5fbfe7d0, timeout=0x7fff5fbfe7d0, sigmask=0x7fff5fbfe7d0) at nsterm.m:4210 #5 0x000000010018d210 in really_call_select (arg=0x7fff5fbfe840) at thread.c:520 #6 0x000000010010ca06 in flush_stack_call_func (func=0, arg=0x5fbfeae800000000) at alloc.c:5137 #7 0x000000010018d1a7 in thread_select (func=0x5fbfeae800000000, max_fds=0, rfds=0x7fff5fbfe828, wfds=0x0, efds=0x7fff5fbfeae8, timeout=0x0, sigmask=0x0) at thread.c:543 #8 0x00000001001752ad in wait_reading_process_output (time_limit=140734799801728, nsecs=0, read_kbd=1606413696, wait_for_cell=140734799801728, wait_proc=0x7fff5fbfed80, just_wait_proc=0, do_display=true) at process.c:5344 #9 0x000000010000471a in sit_for (timeout=30, display_option=0, reading=false) at dispnew.c:5763 #10 0x00000001000bf6f2 in read_char (commandflag=1606414816, map=140734799802848, prev_event=4294967295, used_mouse_menu=0x7fff5fbff1e0, end_time=0x7fff5fbff1e0) at keyboard.c:2725 #11 0x00000001000c26ee in read_key_sequence () at keyboard.c:2599 #12 0x00000001000c4afd in command_loop_1 () at keyboard.c:1373 #13 0x000000010012e2a4 in internal_condition_case (bfun=0x1000c3690 , handlers=499667000, hfun=0x7fff5fbff500) at eval.c:1334 #14 0x00000001000c4d50 in command_loop_2 (ignore=499667000) at keyboard.c:1115 #15 0x000000010012e32f in internal_catch (tag=499667000, func=0x1000c4d20 , arg=499667000) at eval.c:1100 #16 0x00000001000c4ec6 in command_loop [inlined] () at /Code/emacs-build-threads/src/keyboard.c:1094 #17 0x00000001000c4ec6 in recursive_edit_1 () at keyboard.c:1800 #18 0x00000001000b60df in Frecursive_edit () at keyboard.c:771 #19 0x00000001000b2993 in main (argc=4002, argv=0x7fff5fbff780) at emacs.c:1691 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000070 backtrace_top () at eval.c:202 202 while (backtrace_p (pdl) && pdl->kind != SPECPDL_BACKTRACE) The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on" Evaluation of the expression containing the function (backtrace_top) will be abandoned. (gdb) bt #0 backtrace_top () at eval.c:202 #1 #2 0x00000001000cd2b6 in stack_overflow [inlined] () at /Code/emacs-build-threads/src/sysdep.c:1767 #3 0x00000001000cd2b6 in handle_sigsegv (sig=1884515520, siginfo=0x70, arg=0x100621fe8) at sysdep.c:202 #4 #5 0x000000010012d7dc in unbind_to (count=Cannot access memory at address 0x0 ) at eval.c:3499 #6 0x00000001001af2c4 in ns_select (nfds=1606412240, readfds=0x7fff5fbfeb80, writefds=0x7fff5fbfeb00, exceptfds=0x7fff5fbfe7d0, timeout=0x7fff5fbfe7d0, sigmask=0x7fff5fbfe7d0) at nsterm.m:4210 #7 0x000000010018d210 in really_call_select (arg=0x7fff5fbfe840) at thread.c:520 #8 0x000000010010ca06 in flush_stack_call_func (func=0, arg=0x5fbfeae800000000) at alloc.c:5137 #9 0x000000010018d1a7 in thread_select (func=0x5fbfeae800000000, max_fds=0, rfds=0x7fff5fbfe828, wfds=0x0, efds=0x7fff5fbfeae8, timeout=0x0, sigmask=0x0) at thread.c:543 #10 0x00000001001752ad in wait_reading_process_output (time_limit=140734799801728, nsecs=0, read_kbd=1606413696, wait_for_cell=140734799801728, wait_proc=0x7fff5fbfed80, just_wait_proc=0, do_display=true) at process.c:5344 #11 0x000000010000471a in sit_for (timeout=30, display_option=0, reading=false) at dispnew.c:5763 #12 0x00000001000bf6f2 in read_char (commandflag=1606414816, map=140734799802848, prev_event=4294967295, used_mouse_menu=0x7fff5fbff1e0, end_time=0x7fff5fbff1e0) at keyboard.c:2725 #13 0x00000001000c26ee in read_key_sequence () at keyboard.c:2599 #14 0x00000001000c4afd in command_loop_1 () at keyboard.c:1373 #15 0x000000010012e2a4 in internal_condition_case (bfun=0x1000c3690 , handlers=499667000, hfun=0x7fff5fbff500) at eval.c:1334 #16 0x00000001000c4d50 in command_loop_2 (ignore=499667000) at keyboard.c:1115 #17 0x000000010012e32f in internal_catch (tag=499667000, func=0x1000c4d20 , arg=499667000) at eval.c:1100 #18 0x00000001000c4ec6 in command_loop [inlined] () at /Code/emacs-build-threads/src/keyboard.c:1094 #19 0x00000001000c4ec6 in recursive_edit_1 () at keyboard.c:202 #20 0x00000001000b60df in Frecursive_edit () at keyboard.c:771 #21 0x00000001000b2993 in main (argc=4002, argv=0x7fff5fbff780) at emacs.c:1691 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000070 [Switching to process 17249 thread 0x1703] backtrace_top () at eval.c:202 202 while (backtrace_p (pdl) && pdl->kind != SPECPDL_BACKTRACE) The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on" Evaluation of the expression containing the function (backtrace_top) will be abandoned. ========= ===END=== ========= Thanks, Charles From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 24 12:51:58 2016 Received: (at 25265) by debbugs.gnu.org; 24 Dec 2016 17:51:58 +0000 Received: from localhost ([127.0.0.1]:53987 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cKqUA-0003VZ-Ln for submit@debbugs.gnu.org; Sat, 24 Dec 2016 12:51:58 -0500 Received: from eggs.gnu.org ([208.118.235.92]:54069) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cKqU9-0003VN-4Z for 25265@debbugs.gnu.org; Sat, 24 Dec 2016 12:51:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cKqTz-0001Z4-TC for 25265@debbugs.gnu.org; Sat, 24 Dec 2016 12:51:51 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51007) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cKqTz-0001Yy-PU; Sat, 24 Dec 2016 12:51:47 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4200 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cKqTx-0005QT-0m; Sat, 24 Dec 2016 12:51:47 -0500 Date: Sat, 24 Dec 2016 19:51:13 +0200 Message-Id: <83r34xxlke.fsf@gnu.org> From: Eli Zaretskii To: charles@aurox.ch (Charles A. Roelli) In-reply-to: (charles@aurox.ch) Subject: Re: bug#25265: make-thread crashes in OS X 10.6 References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.1 (--------) X-Debbugs-Envelope-To: 25265 Cc: 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.1 (--------) > From: charles@aurox.ch (Charles A. Roelli) > Date: Sat, 24 Dec 2016 12:06:45 +0100 > > Running Emacs -Q on the latest commit (e36a3882), > > M-: (make-thread (lambda () "string")) > > appears to hang Emacs immediately. I cannot reproduce this, neither on GNU/Linux nor on MS-Windows. So I guess this is NS-specific. I see that ns_select calls block/unblock_input, which makes it unsafe when more than one thread is running. It's quite possible that this is the reason. I hope some NS expert could take a look at this and fix this. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 25 10:53:02 2016 Received: (at 25265) by debbugs.gnu.org; 25 Dec 2016 15:53:02 +0000 Received: from localhost ([127.0.0.1]:54871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLB6c-0007Ue-Gc for submit@debbugs.gnu.org; Sun, 25 Dec 2016 10:53:02 -0500 Received: from eggs.gnu.org ([208.118.235.92]:37466) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLB6b-0007U9-LR for 25265@debbugs.gnu.org; Sun, 25 Dec 2016 10:53:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cLB6T-0001QX-AQ for 25265@debbugs.gnu.org; Sun, 25 Dec 2016 10:52:56 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60151) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cLB6T-0001QR-7K; Sun, 25 Dec 2016 10:52:53 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1429 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cLB6S-00024Q-GV; Sun, 25 Dec 2016 10:52:53 -0500 Date: Sun, 25 Dec 2016 17:52:37 +0200 Message-Id: <83d1ggxayi.fsf@gnu.org> From: Eli Zaretskii To: charles@aurox.ch In-reply-to: <83r34xxlke.fsf@gnu.org> (message from Eli Zaretskii on Sat, 24 Dec 2016 19:51:13 +0200) Subject: Re: bug#25265: make-thread crashes in OS X 10.6 References: <83r34xxlke.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.1 (--------) X-Debbugs-Envelope-To: 25265 Cc: 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.1 (--------) > Date: Sat, 24 Dec 2016 19:51:13 +0200 > From: Eli Zaretskii > Cc: 25265@debbugs.gnu.org > > I see that ns_select calls block/unblock_input, which makes it unsafe > when more than one thread is running. It's quite possible that this > is the reason. > > I hope some NS expert could take a look at this and fix this. One idea is to write an implementation of block_input and unblock_input that uses atomic increment and decrement functions, then use those only in ns_select. Could someone with access to NS please try that? From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 26 08:09:28 2016 Received: (at 25265) by debbugs.gnu.org; 26 Dec 2016 13:09:28 +0000 Received: from localhost ([127.0.0.1]:55399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLV1r-0000fK-Q8 for submit@debbugs.gnu.org; Mon, 26 Dec 2016 08:09:28 -0500 Received: from mail-wj0-f170.google.com ([209.85.210.170]:35234) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLV1p-0000f7-QY for 25265@debbugs.gnu.org; Mon, 26 Dec 2016 08:09:26 -0500 Received: by mail-wj0-f170.google.com with SMTP id v7so300198297wjy.2 for <25265@debbugs.gnu.org>; Mon, 26 Dec 2016 05:09:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=CqZtIgCxyx3jLu8kjXhGs4WSFQzF08XR1p40lFZjyOc=; b=X1MzzOfpPC582XExTwiZQsItlqx2abgwxoWTRaKvpVyFLm1IgsUEcRDmagtsZevbfQ hP9QJqHgAKtbTq52LvrJoGiCoz8WN46iVqnx0pqjjrsNG/Hxob0c/xkkEetq3lnOcETy OJa+/4rIbwMSSVTiI/z6+4I8ytDxDJfziJwjNlCFZcvNavBmifAST8uAgY0ATLPWFTPh /CRFHJjDheXeJE0mI+3h5mN+Q112nSQXb2d5uxvdQISXQ6iGz8nqp3Vn4hc8RYmDDLVz 4HFIbOY6xNVEmGavy9QZ+Aqv125nAhwpKOjYz9hxCLMqFXVwaCmvrKkrELKQD3nJai80 hgMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=CqZtIgCxyx3jLu8kjXhGs4WSFQzF08XR1p40lFZjyOc=; b=lV1lK2Lfq31YM99x0vnE0Cn+0teIaAZFOtwPiQFqehT4vlpaw1rB8W+qJHFbJZMS7b 8ZFVGyQlH4jr3UkDDdeAKnMBiZzxO+r0djvUMXmkTj4c6CBGu60wN85hKLGethoycdTf dOfN+kyVYWy6hTHRCLNTTMYi4aGmNTWeksOg56IK+hsJLquzi0iRC+RAU3sxY7nOe07H dlHsfU6Z9Kv0PkNIr0jLQ5Hzv+TwyTp6bzXFQQ6qZ1cETCaGqcsR65vlWQkXKORktFE0 tbunE1/De6cYqhpLs1Ykl8FKPVLSHit49HyYuC6KGM3ctnN5aG32CfCmFP7snCTGG6Sz QutA== X-Gm-Message-State: AIkVDXIvhqXwCmlO8hWIBrWM1yP3dZfyvAtjuJp8Wy5BRK6cJI/M/iCvyFQAB0i0DGEOkg== X-Received: by 10.194.80.162 with SMTP id s2mr23054513wjx.52.1482757760216; Mon, 26 Dec 2016 05:09:20 -0800 (PST) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-413d-7770-bc2d-ff97.holly.idiocy.org. [2001:8b0:3f8:8129:413d:7770:bc2d:ff97]) by smtp.gmail.com with ESMTPSA id x140sm51359517wme.19.2016.12.26.05.09.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Dec 2016 05:09:19 -0800 (PST) Date: Mon, 26 Dec 2016 13:09:17 +0000 From: Alan Third To: Eli Zaretskii Subject: Re: bug#25265: make-thread crashes in OS X 10.6 Message-ID: <20161226130917.GA36471@breton.holly.idiocy.org> References: <83r34xxlke.fsf@gnu.org> <83d1ggxayi.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83d1ggxayi.fsf@gnu.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 25265 Cc: charles@aurox.ch, 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) On Sun, Dec 25, 2016 at 05:52:37PM +0200, Eli Zaretskii wrote: > > Date: Sat, 24 Dec 2016 19:51:13 +0200 > > From: Eli Zaretskii > > Cc: 25265@debbugs.gnu.org > > > > I see that ns_select calls block/unblock_input, which makes it unsafe > > when more than one thread is running. It's quite possible that this > > is the reason. > > > > I hope some NS expert could take a look at this and fix this. > > One idea is to write an implementation of block_input and > unblock_input that uses atomic increment and decrement functions, then > use those only in ns_select. > > Could someone with access to NS please try that? I’ve just tried the below patch and it doesn’t make any difference: it still hangs immediately. Back in October Ken Raeburn listed some things that need done in ns_select which are probably relevant: https://lists.gnu.org/archive/html/emacs-devel/2016-10/msg00525.html 2 files changed, 23 insertions(+) src/blockinput.h | 8 ++++++++ src/keyboard.c | 15 +++++++++++++++ modified src/blockinput.h @@ -49,10 +49,18 @@ extern volatile int interrupt_input_blocked; /* Begin critical section. */ +#ifdef NS_IMPL_COCOA +#include +#endif + INLINE void block_input (void) { +#ifdef NS_IMPL_COCOA + OSAtomicIncrement32(&interrupt_input_blocked); +#else interrupt_input_blocked++; +#endif } extern void unblock_input (void); modified src/keyboard.c @@ -54,6 +54,10 @@ along with GNU Emacs. If not, see . */ #include #endif /* not MSDOS */ +#ifdef NS_IMPL_COCOA +#include +#endif + #if defined USABLE_FIONREAD && defined USG5_4 # include #endif @@ -7183,7 +7187,18 @@ unblock_input_to (int level) void unblock_input (void) { +#ifdef NS_IMPL_COCOA + OSAtomicDecrement32(&interrupt_input_blocked); + if (interrupt_input_blocked == 0) + { + if (pending_signals && !fatal_error_in_progress) + process_pending_signals (); + } + else if (interrupt_input_blocked < 0) + emacs_abort (); +#else unblock_input_to (interrupt_input_blocked - 1); +#endif } /* Undo any number of BLOCK_INPUT calls, -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 26 10:52:56 2016 Received: (at 25265) by debbugs.gnu.org; 26 Dec 2016 15:52:56 +0000 Received: from localhost ([127.0.0.1]:55837 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLXa4-0004qP-3f for submit@debbugs.gnu.org; Mon, 26 Dec 2016 10:52:56 -0500 Received: from eggs.gnu.org ([208.118.235.92]:43621) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLXa2-0004qA-20 for 25265@debbugs.gnu.org; Mon, 26 Dec 2016 10:52:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cLXZs-0001cn-LO for 25265@debbugs.gnu.org; Mon, 26 Dec 2016 10:52:48 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41728) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cLXZs-0001cj-IE; Mon, 26 Dec 2016 10:52:44 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3195 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cLXZr-0006Ne-NU; Mon, 26 Dec 2016 10:52:44 -0500 Date: Mon, 26 Dec 2016 17:52:30 +0200 Message-Id: <8337hay9fl.fsf@gnu.org> From: Eli Zaretskii To: Alan Third In-reply-to: <20161226130917.GA36471@breton.holly.idiocy.org> (message from Alan Third on Mon, 26 Dec 2016 13:09:17 +0000) Subject: Re: bug#25265: make-thread crashes in OS X 10.6 References: <83r34xxlke.fsf@gnu.org> <83d1ggxayi.fsf@gnu.org> <20161226130917.GA36471@breton.holly.idiocy.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.1 (--------) X-Debbugs-Envelope-To: 25265 Cc: charles@aurox.ch, 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.1 (--------) > Date: Mon, 26 Dec 2016 13:09:17 +0000 > From: Alan Third > Cc: charles@aurox.ch, 25265@debbugs.gnu.org > > I’ve just tried the below patch and it doesn’t make any difference: it > still hangs immediately. Can you try and figure out why it hangs? > Back in October Ken Raeburn listed some things that need done in > ns_select which are probably relevant: > > https://lists.gnu.org/archive/html/emacs-devel/2016-10/msg00525.html Hmm... none of the changes Ken mentioned were in the concurrency branch when I merged it. Perhaps Ken didn't push the changes back then. The problems in xg_select were solved in a different way, I believe. The problems in ns_select are the issue at hand here. Wrt static variables used by ns_select: either they should become members of struct thread_state, or the calls to release_global_lock and acquire_global_lock should be moved into ns_select (which was what Ken was proposing, AFAIU). I'm not sure which possibility is better, nor whether this is all that needs to be done, because I don't understand well enough the semantics of some parts of ns_select, in particular where it says [NSApp run]; Can this part and its surrounding code be made thread-safe? The call to record_unwind_protect in particular confuses me: that seems to hint the code wants to be interruptible here, which might require stuff like maybe_reacquire_global_lock I added to keyboard.c, to avoid problems when Emacs gets SIGINT on a TTY frame. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 26 15:56:42 2016 Received: (at 25265) by debbugs.gnu.org; 26 Dec 2016 20:56:42 +0000 Received: from localhost ([127.0.0.1]:56047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLcK2-0007xP-9L for submit@debbugs.gnu.org; Mon, 26 Dec 2016 15:56:42 -0500 Received: from mail-wj0-f180.google.com ([209.85.210.180]:34465) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLcK0-0007xC-Ld for 25265@debbugs.gnu.org; Mon, 26 Dec 2016 15:56:41 -0500 Received: by mail-wj0-f180.google.com with SMTP id sd9so120756836wjb.1 for <25265@debbugs.gnu.org>; Mon, 26 Dec 2016 12:56:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=4rWjVWx4G9BRxKpGo6DbNLItlIRW79jh4jbLheHNefc=; b=dM2fn2LFyj8sDWCk7XMfehcSK84PgTqnKWSTb6ZT5DCBxQMpIBSAvw648bfrN9L0f1 8097Elf80D6IpUKLA4IvBZ8ErBJN2NlbW4zOEp01SPmDJnxwIdUCSsrj9RJjZIcdvmaW i4yXfVHCGPi90f3EMt4wc3Lfn2HC++5xzZZmZIwDhxqvmKmMV64hMtTtutnSZHb7Ru9r Z6w/yFaO0kmNhB4LlpGmXaDUYCm55A7jGkoDiF89XKioVlRX7E3GU9ii0ZnAFvsQ6DuR TbhCZjl6Xlzz7GfkA5oqB+Uto34919FcpNlK1Jz2G4QreQQeffZ4LQAOQSKuh2tXKzbw 7nvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=4rWjVWx4G9BRxKpGo6DbNLItlIRW79jh4jbLheHNefc=; b=nn+QOW1E7thRIACOqsd5gawZ8qyQ/YN/FE4FdQBNzTe7tteJmzRd+/dPZ8psxiGRYz 8scECV1nXi17p55HpcivkTRugeG4gso47LaEPY+AQTSYw14u1XYuBWJkKGhTtX+pTb4y MWRJabwFfZK3q+wPFwF2KIekQIRo5L/Q0s5+EBkwS/ocP/4eXBnA9nHz38Dt6kAhvMuY XpNr1bQNeeN8qvvptEpMg5gtRfj4Hi1wtQ87uUiIgM9Q1aPLMCV3sLp8E1E7Au14p+Tb j98T9zVJO6MDw846inTqc0R52M1D9xLmL60XN9q/yarnvxcc12widsEePC1qjRet+uVy YOxA== X-Gm-Message-State: AIkVDXLvoRxvBBNIsUzI+0PPEKPTqKCT8k/DRZYmAbUwnI+6WOctRSd8FIJzN0QbBfc1Kw== X-Received: by 10.194.87.230 with SMTP id bb6mr29104860wjb.163.1482785794902; Mon, 26 Dec 2016 12:56:34 -0800 (PST) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-413d-7770-bc2d-ff97.holly.idiocy.org. [2001:8b0:3f8:8129:413d:7770:bc2d:ff97]) by smtp.gmail.com with ESMTPSA id i15sm56249625wjs.16.2016.12.26.12.56.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Dec 2016 12:56:34 -0800 (PST) Date: Mon, 26 Dec 2016 20:56:32 +0000 From: Alan Third To: Eli Zaretskii Subject: Re: bug#25265: make-thread crashes in OS X 10.6 Message-ID: <20161226205632.GA36805@breton.holly.idiocy.org> References: <83r34xxlke.fsf@gnu.org> <83d1ggxayi.fsf@gnu.org> <20161226130917.GA36471@breton.holly.idiocy.org> <8337hay9fl.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8337hay9fl.fsf@gnu.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 25265 Cc: charles@aurox.ch, 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) On Mon, Dec 26, 2016 at 05:52:30PM +0200, Eli Zaretskii wrote: > > Date: Mon, 26 Dec 2016 13:09:17 +0000 > > From: Alan Third > > Cc: charles@aurox.ch, 25265@debbugs.gnu.org > > > > I’ve just tried the below patch and it doesn’t make any difference: it > > still hangs immediately. > > Can you try and figure out why it hangs? I’m not having any luck with this. My entirely uneducated guess is that the main thread can’t access the contents of current_thread. It crashes on this line: while (specpdl_ptr != specpdl + count) with EXC_BAD_ACCESS. Only three things are being accessed: count, which is a function argument, and specpdl and specpdl_ptr are #defines to variables within current_thread. I can’t access anything within current_thread using lldb, but I can see current_thread itself. I don’t know if that signifies anything. I’ll put the complete backtrace at the bottom of this email. > > Back in October Ken Raeburn listed some things that need done in > > ns_select which are probably relevant: > > > > https://lists.gnu.org/archive/html/emacs-devel/2016-10/msg00525.html > > Hmm... none of the changes Ken mentioned were in the concurrency > branch when I merged it. Perhaps Ken didn't push the changes back > then. > > The problems in xg_select were solved in a different way, I believe. > The problems in ns_select are the issue at hand here. > > Wrt static variables used by ns_select: either they should become > members of struct thread_state, or the calls to release_global_lock > and acquire_global_lock should be moved into ns_select (which was what > Ken was proposing, AFAIU). I'm not sure which possibility is better, > nor whether this is all that needs to be done, because I don't > understand well enough the semantics of some parts of ns_select, in > particular where it says > > [NSApp run]; > > Can this part and its surrounding code be made thread-safe? I think this particular method call has to be done *only* from the main thread. I imagine that could be a problem. > The call to record_unwind_protect in particular confuses me: that > seems to hint the code wants to be interruptible here, which might > require stuff like maybe_reacquire_global_lock I added to > keyboard.c, to avoid problems when Emacs gets SIGINT on a TTY frame. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 27 02:30:50 2016 Received: (at 25265) by debbugs.gnu.org; 27 Dec 2016 07:30:50 +0000 Received: from localhost ([127.0.0.1]:56264 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLmDi-00062T-IQ for submit@debbugs.gnu.org; Tue, 27 Dec 2016 02:30:50 -0500 Received: from eggs.gnu.org ([208.118.235.92]:49366) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLmDh-00062G-G6 for 25265@debbugs.gnu.org; Tue, 27 Dec 2016 02:30:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cLmDZ-0001l0-6L for 25265@debbugs.gnu.org; Tue, 27 Dec 2016 02:30:44 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49461) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cLmDZ-0001ku-1Q; Tue, 27 Dec 2016 02:30:41 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1650 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cLmDX-0001fM-V5; Tue, 27 Dec 2016 02:30:40 -0500 Date: Tue, 27 Dec 2016 09:30:28 +0200 Message-Id: <83k2alx20b.fsf@gnu.org> From: Eli Zaretskii To: Alan Third In-reply-to: <20161226205632.GA36805@breton.holly.idiocy.org> (message from Alan Third on Mon, 26 Dec 2016 20:56:32 +0000) Subject: Re: bug#25265: make-thread crashes in OS X 10.6 References: <83r34xxlke.fsf@gnu.org> <83d1ggxayi.fsf@gnu.org> <20161226130917.GA36471@breton.holly.idiocy.org> <8337hay9fl.fsf@gnu.org> <20161226205632.GA36805@breton.holly.idiocy.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.1 (--------) X-Debbugs-Envelope-To: 25265 Cc: charles@aurox.ch, 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.1 (--------) > Date: Mon, 26 Dec 2016 20:56:32 +0000 > From: Alan Third > Cc: charles@aurox.ch, 25265@debbugs.gnu.org > > > Can you try and figure out why it hangs? > > I’m not having any luck with this. My entirely uneducated guess is > that the main thread can’t access the contents of current_thread. It > crashes on this line: > > while (specpdl_ptr != specpdl + count) > > with EXC_BAD_ACCESS. Only three things are being accessed: count, > which is a function argument, and specpdl and specpdl_ptr are > #defines to variables within current_thread. The loop above is in unbind_to, right? > I can’t access anything within current_thread using lldb, but I can > see current_thread itself. I don’t know if that signifies anything. I have bad experience with using lldb (not on OS X, though), so I don't trust it. Can you use GDB instead? Failing that, is it possible to just fprintf these values to stderr? It is strange that this is where it hangs, since these are thread-specific variables. Maybe the problem is that apploopnr is a static variable, and some other thread stomps on it? > I’ll put the complete backtrace at the bottom of this email. I don't see any backtraces attached. > > [NSApp run]; > > > > Can this part and its surrounding code be made thread-safe? > > I think this particular method call has to be done *only* from the > main thread. I imagine that could be a problem. It could be a problem, yes. But what does this do, exactly, and why does it need to be called as part of ns_select? Also, why does ns_select sometimes call pselect instead -- is that for non-interactive or non-GUI sessions or something? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 27 05:44:35 2016 Received: (at 25265) by debbugs.gnu.org; 27 Dec 2016 10:44:35 +0000 Received: from localhost ([127.0.0.1]:56308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLpFD-00027G-G7 for submit@debbugs.gnu.org; Tue, 27 Dec 2016 05:44:35 -0500 Received: from mail-wj0-f180.google.com ([209.85.210.180]:33700) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLpFB-00026z-4M for 25265@debbugs.gnu.org; Tue, 27 Dec 2016 05:44:33 -0500 Received: by mail-wj0-f180.google.com with SMTP id tq7so78378368wjb.0 for <25265@debbugs.gnu.org>; Tue, 27 Dec 2016 02:44:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=4NSgQEAPu9wmKmW0YslZ8IuSdycXwLTcocYsQ0CowSM=; b=h4vnXZNwThSVhNtV17ZfYIzPbdPVjCk1+W8EDIUYkDdLHxMUxtZmM6IodHXei/cGkI /LAf43/8d1y8kikBk/+cn21KwYoQow7iSn1xziFPLe0vQKShWNHkmvzBiouITOGcnqm+ rtNG/CO4VcrnmeTSPn+Ky2RIxgwUipfwe1ukbBfHOJuz9I/WxxTv+3fN7M1demvD3heE G+z1ogF/HXPd6PM9yll3iwvsLkBn3qvU6CbwuYZuOVCOTllLp4l6fvlx7u+GdjlUnfXQ v4D+HFeattAOxaBE2x5G7h90yfXaHsxeFuYVfIeD0OjDJyRA9HxHYg3YjIbupvNT5+2a KQRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=4NSgQEAPu9wmKmW0YslZ8IuSdycXwLTcocYsQ0CowSM=; b=DYkvFrNToYI71Vp4GKw8ejfT8ykgWM4x7gQqsR7J7q3atpDPBky0E0oJGrWiDj1a56 04fzHD66BHMtgTr75Zkwu2uGk703xz10jnrtMUxzAXkhK25bvOut2l/6DAa0fcVDGfuU 6IBsHfRJgN1YKW9+GNxEJiVfq9ukuTPytXpfVqmAbFZur0HaG1q1GKzYiWuLpCyQnOoI daVz3eKFZDsnvK6cegLq47XayE0WJF3cbzgOfkzaProPN+eb4nMqNRlXw/2cL00r6j1Z 1f5Q56qU8VaGvDUxipQhKkPygGN0SNDrtZRXpEjgMKLZ7ZzA8yaIU2EmVnsGtYO/2NUw PT5w== X-Gm-Message-State: AIkVDXLxk+Io5zZmI9xu66DT5xa8rjqZOLjDbJ0oSV0tycBxFJrttfnteC1/CP59XlWYMg== X-Received: by 10.194.174.229 with SMTP id bv5mr28570389wjc.21.1482835467370; Tue, 27 Dec 2016 02:44:27 -0800 (PST) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-413d-7770-bc2d-ff97.holly.idiocy.org. [2001:8b0:3f8:8129:413d:7770:bc2d:ff97]) by smtp.gmail.com with ESMTPSA id z9sm6271857wjf.17.2016.12.27.02.44.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Dec 2016 02:44:26 -0800 (PST) Date: Tue, 27 Dec 2016 10:44:24 +0000 From: Alan Third To: Eli Zaretskii Subject: Re: bug#25265: make-thread crashes in OS X 10.6 Message-ID: <20161227104424.GA45039@breton.holly.idiocy.org> References: <83r34xxlke.fsf@gnu.org> <83d1ggxayi.fsf@gnu.org> <20161226130917.GA36471@breton.holly.idiocy.org> <8337hay9fl.fsf@gnu.org> <20161226205632.GA36805@breton.holly.idiocy.org> <83k2alx20b.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83k2alx20b.fsf@gnu.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 25265 Cc: charles@aurox.ch, 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) On Tue, Dec 27, 2016 at 09:30:28AM +0200, Eli Zaretskii wrote: > > Date: Mon, 26 Dec 2016 20:56:32 +0000 > > From: Alan Third > > Cc: charles@aurox.ch, 25265@debbugs.gnu.org > > > > I’m not having any luck with this. My entirely uneducated guess is > > that the main thread can’t access the contents of current_thread. It > > crashes on this line: > > > > while (specpdl_ptr != specpdl + count) > > > > with EXC_BAD_ACCESS. Only three things are being accessed: count, > > which is a function argument, and specpdl and specpdl_ptr are > > #defines to variables within current_thread. > > The loop above is in unbind_to, right? Yes. > > I can’t access anything within current_thread using lldb, but I can > > see current_thread itself. I don’t know if that signifies anything. > > I have bad experience with using lldb (not on OS X, though), so I > don't trust it. Can you use GDB instead? Failing that, is it > possible to just fprintf these values to stderr? OK, I’ve ended up just using printf and it looks like in this thread current_thread is null. GDB says it’s null too. Here’s what I put in just before the while loop: printf("AT: %d\n", current_thread); fflush(stdout); And here’s the output from GDB. You can see where current_thread switches from non‐null to null, just before Emacs hangs: AT: 7842432 AT: 43712208 AT: 43712208 AT: 0 Thread 2 received signal SIGSEGV, Segmentation fault. 0x0000000100200920 in unbind_to (count=0, value=0) at eval.c:3502 3502 while (specpdl_ptr != specpdl + count) (gdb) p current_thread $1 = (struct thread_state *) 0x0 > > I’ll put the complete backtrace at the bottom of this email. > > I don't see any backtraces attached. I’ve actually put it in this time. Sorry about that. > > > [NSApp run]; > > > > > > Can this part and its surrounding code be made thread-safe? > > > > I think this particular method call has to be done *only* from the > > main thread. I imagine that could be a problem. > > It could be a problem, yes. But what does this do, exactly, and why > does it need to be called as part of ns_select? It runs an event loop that picks up all GUI events and then dispatches them. It’s part of NextStep. It’s unclear to me why it’s run in ns_select, but presumably it’s because it needs to be run somewhere and whoever wrote it thought that was a good place. If we need to, I expect we could move it to its own thread. That seems to be a known pattern in the GNUStep/Cocoa world. > Also, why does ns_select sometimes call pselect instead -- is that for > non-interactive or non-GUI sessions or something? It looks that way. It uses it if NSApp isn’t defined, which will happen if Emacs isn’t being run as a GUI application. I’m pretty sure that Emacs doesn’t even use ns_select when it’s run in the terminal, though. It also uses it when timeouts are set to zero. I don’t know what that’s about. The backtrace: Thread 2 received signal SIGSEGV, Segmentation fault. 0x0000000100200933 in unbind_to (count=4, value=0) at eval.c:3499 3499 while (specpdl_ptr != specpdl + count) (gdb) thread apply all bt Thread 13 (Thread 0x1a33 of process 45034): #0 0x00007fffb03594e2 in ?? () #1 0x00007fffb0441791 in ?? () #2 0x0000000000000000 in ?? () Thread 12 (Thread 0x190f of process 45034): #0 0x00007fffb04411e0 in ?? () #1 0x0000000000000000 in ?? () Thread 11 (Thread 0x113f of process 45034): #0 0x00007fffb03594e2 in ?? () #1 0x00007fffb0441791 in ?? () #2 0x0000000000000000 in ?? () Thread 10 (Thread 0x1d03 of process 45034): #0 0x00007fffb035138a in ?? () #1 0x00007fffb03507d7 in ?? () #2 0x0000000000000000 in ?? () Thread 6 (Thread 0x1507 of process 45034): #0 0x00007fffb04411e0 in ?? () #1 0x000000000ee6b280 in ?? () ---Type to continue, or q to quit--- #2 0x000000003b99b0ae in ?? () #3 0x00007000029d1aa0 in ?? () #4 0x00007000029d1a9c in ?? () #5 0x00007000029d17b0 in ?? () #6 0x00007000029d1a30 in ?? () #7 0xe9bfbe3cda25000b in ?? () #8 0x0000000000000000 in ?? () Thread 5 (Thread 0x1407 of process 45034): #0 0x00007fffb0358f4a in ?? () #1 0x0000000100b0cc0e in ?? () #2 0x0000000000000000 in ?? () Thread 4 (Thread 0x120b of process 45034): #0 0x00007fffb0358f4a in ?? () #1 0x00000001002cca9a in -[EmacsApp fd_handler:] (self=0x1016217e0, _cmd=0x100371b45, unused=0x0) at nsterm.m:5512 #2 0x00007fff9c6f6c6d in ?? () #3 0x0000000000000000 in ?? () Thread 2 (Thread 0x1707 of process 45034): #0 0x0000000100200933 in unbind_to (count=4, value=0) at eval.c:3499 #1 0x00000001002c6962 in ns_select (nfds=0, readfds=0x7fff5fbfe5a8, ---Type to continue, or q to quit--- writefds=0x7fff5fbfe528, exceptfds=0x0, timeout=0x7fff5fbfe500, sigmask=0x0) at nsterm.m:4210 #2 0x00000001002a4e3f in really_call_select (arg=0x7fff5fbfdee8) at thread.c:520 #3 0x00000001001d5295 in flush_stack_call_func ( func=0x1002a4dc0 , arg=0x7fff5fbfdee8) at alloc.c:5137 #4 0x00000001002a4da6 in thread_select (func=0x1002c62d0 , max_fds=0, rfds=0x7fff5fbfe5a8, wfds=0x7fff5fbfe528, efds=0x0, timeout=0x7fff5fbfe500, sigmask=0x0) at thread.c:543 #5 0x0000000100274571 in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=0, wait_proc=0x0, just_wait_proc=0) at process.c:5344 #6 0x00000001000092b4 in sit_for (timeout=122, reading=true, display_option=1) at dispnew.c:5763 #7 0x0000000100140c5e in read_char (commandflag=1, map=4337270851, prev_event=0, used_mouse_menu=0x7fff5fbff037, end_time=0x0) at keyboard.c:2729 #8 0x000000010013c0f0 in read_key_sequence (keybuf=0x7fff5fbff360, bufsize=30, prompt=0, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9154 #9 0x000000010013ac32 in command_loop_1 () at keyboard.c:1377 #10 0x000000010020455f in internal_condition_case ( ---Type to continue, or q to quit--- bfun=0x10013a690 , handlers=17232, hfun=0x1001505c0 ) at eval.c:1334 #11 0x00000001001504bc in command_loop_2 (ignore=0) at keyboard.c:1119 #12 0x0000000100203cf8 in internal_catch (tag=43536, func=0x100150490 , arg=0) at eval.c:1100 #13 0x0000000100139be8 in command_loop () at keyboard.c:1098 #14 0x0000000100139a50 in recursive_edit_1 () at keyboard.c:704 #15 0x0000000100139d88 in Frecursive_edit () at keyboard.c:775 #16 0x0000000100137a7d in main (argc=2, argv=0x7fff5fbff9a0) at emacs.c:1690 (gdb) p current_thread.m_specpdl Cannot access memory at address 0x70 (gdb) p current_thread->m_specpdl Cannot access memory at address 0x70 (gdb) -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 27 06:13:32 2016 Received: (at 25265) by debbugs.gnu.org; 27 Dec 2016 11:13:32 +0000 Received: from localhost ([127.0.0.1]:56322 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLphE-0002qI-9o for submit@debbugs.gnu.org; Tue, 27 Dec 2016 06:13:32 -0500 Received: from eggs.gnu.org ([208.118.235.92]:33494) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLphD-0002q5-6X for 25265@debbugs.gnu.org; Tue, 27 Dec 2016 06:13:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cLph3-0004tT-Rn for 25265@debbugs.gnu.org; Tue, 27 Dec 2016 06:13:26 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51254) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cLph3-0004tJ-Of; Tue, 27 Dec 2016 06:13:21 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2348 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cLph2-0007K4-Jt; Tue, 27 Dec 2016 06:13:21 -0500 Date: Tue, 27 Dec 2016 13:13:11 +0200 Message-Id: <83bmvxwrp4.fsf@gnu.org> From: Eli Zaretskii To: Alan Third In-reply-to: <20161227104424.GA45039@breton.holly.idiocy.org> (message from Alan Third on Tue, 27 Dec 2016 10:44:24 +0000) Subject: Re: bug#25265: make-thread crashes in OS X 10.6 References: <83r34xxlke.fsf@gnu.org> <83d1ggxayi.fsf@gnu.org> <20161226130917.GA36471@breton.holly.idiocy.org> <8337hay9fl.fsf@gnu.org> <20161226205632.GA36805@breton.holly.idiocy.org> <83k2alx20b.fsf@gnu.org> <20161227104424.GA45039@breton.holly.idiocy.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.1 (--------) X-Debbugs-Envelope-To: 25265 Cc: charles@aurox.ch, 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.1 (--------) > Date: Tue, 27 Dec 2016 10:44:24 +0000 > From: Alan Third > Cc: charles@aurox.ch, 25265@debbugs.gnu.org > > OK, I’ve ended up just using printf and it looks like in this thread > current_thread is null. This happens in only one place: run_thread, after a thread exits. And yes, it's a bad idea to rely on current_thread being non-NULL in code that is run when other threads could be running. More generally, this means calling unbind_to, i.e. unwinding the Lisp stack, is not going to work in this context at all, because that in effect runs Lisp when more than one thread could run their code. > > > > [NSApp run]; > > > > > > > > Can this part and its surrounding code be made thread-safe? > > > > > > I think this particular method call has to be done *only* from the > > > main thread. I imagine that could be a problem. > > > > It could be a problem, yes. But what does this do, exactly, and why > > does it need to be called as part of ns_select? > > It runs an event loop that picks up all GUI events and then dispatches > them. It’s part of NextStep. It’s unclear to me why it’s run in > ns_select, but presumably it’s because it needs to be run somewhere > and whoever wrote it thought that was a good place. > > If we need to, I expect we could move it to its own thread. That seems > to be a known pattern in the GNUStep/Cocoa world. That's probably the only reasonable way. But why does it use record_unwind_protect and unbind_to in the first place? What happens if the user presses C-g while the event loop runs? > I’m pretty sure that Emacs doesn’t even use ns_select when it’s run > in the terminal, though. Actually, I think it has to use ns_select, because subprocesses are still supported on a text terminal, and reading their output calls ns_select. Likewise network connections. From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 28 14:36:44 2016 Received: (at 25265) by debbugs.gnu.org; 28 Dec 2016 19:36:44 +0000 Received: from localhost ([127.0.0.1]:58297 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMK1k-0001eB-07 for submit@debbugs.gnu.org; Wed, 28 Dec 2016 14:36:44 -0500 Received: from mail-wj0-f182.google.com ([209.85.210.182]:34196) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMK1h-0001dt-Rn for 25265@debbugs.gnu.org; Wed, 28 Dec 2016 14:36:42 -0500 Received: by mail-wj0-f182.google.com with SMTP id sd9so158860828wjb.1 for <25265@debbugs.gnu.org>; Wed, 28 Dec 2016 11:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=pXDYVukJ4Rr/32TPdfKykHevLUZe9MJMaZnfPJ4M2DE=; b=BtYHCby6I4YrO9cyO47EowwMhHXlGVvB+BeFoN8wxc0F3xGzsvn/VToEx+INEbXtx7 amOjAd+7V2KZTxwGY95CYof5gD9w6uWU81krBIIfjgr6h3qNWjPbsEhCBmik3RNsGcDp Mqd5oJdQsYSds0GLqG204UE7R848Gn3hS90ZRFg0TC3X8SaLgD9wAv6PQ20b1G9B992j 2zQ3kvj22GEMCcGt2cdaph9+RgBM8beaNsUawk3y7Cerq4zBQGqfI4xBXm7mIBDI540Q mJP3kFck8CtAl4oLx0GN7WZbxnYA96MvxoFW42YtIFPGJICant/Nj3qwpkCOQXlBIPbT h/Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=pXDYVukJ4Rr/32TPdfKykHevLUZe9MJMaZnfPJ4M2DE=; b=hjEl8vNCFcgRc+Klnq4c5Yu/5btsVHwqxjy51jPIAYq8FWvQnvg8lZVizGWcfuq1X5 AEhfpikO9S/sUjI7bpZqoiY7jfZo/aRhRBYL9pZQZtQgevz9OatJsYN8CjQCksvYFM7y 7AzhgzrNgo99gtBYIStkghAvUHiyyP4R43r/7eo/wUOSI0OK0hhaNwF3X/+ICpWGjtlr i3PjAZdVgO1qVEacCNjISuSycilDa/HkdRxqzpRGUE1whMxnzcWn+W39eKIe9qF3ZZwZ 1DHQwKltD0QNL2WLhJ7BnvuJrCj53zzw7mNO5cHSBOcQnGioj3FRSfwnIwFdsygPNGBM zSAA== X-Gm-Message-State: AIkVDXKzpo+5M7mwC15H72ky8gnqYzRPHqoFVt29vc34Mt1g1cY6phL43k21vDeA6Lz16w== X-Received: by 10.194.59.98 with SMTP id y2mr33320523wjq.166.1482953796008; Wed, 28 Dec 2016 11:36:36 -0800 (PST) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-e98a-1e50-f566-df0e.holly.idiocy.org. [2001:8b0:3f8:8129:e98a:1e50:f566:df0e]) by smtp.gmail.com with ESMTPSA id 197sm62055217wmy.16.2016.12.28.11.36.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Dec 2016 11:36:35 -0800 (PST) Date: Wed, 28 Dec 2016 19:36:33 +0000 From: Alan Third To: Eli Zaretskii Subject: Re: bug#25265: make-thread crashes in OS X 10.6 Message-ID: <20161228193633.GA47290@breton.holly.idiocy.org> References: <83r34xxlke.fsf@gnu.org> <83d1ggxayi.fsf@gnu.org> <20161226130917.GA36471@breton.holly.idiocy.org> <8337hay9fl.fsf@gnu.org> <20161226205632.GA36805@breton.holly.idiocy.org> <83k2alx20b.fsf@gnu.org> <20161227104424.GA45039@breton.holly.idiocy.org> <83bmvxwrp4.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83bmvxwrp4.fsf@gnu.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 25265 Cc: charles@aurox.ch, 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) On Tue, Dec 27, 2016 at 01:13:11PM +0200, Eli Zaretskii wrote: > > Date: Tue, 27 Dec 2016 10:44:24 +0000 > > From: Alan Third > > Cc: charles@aurox.ch, 25265@debbugs.gnu.org > > > > > > [NSApp run]; > > > > > > > > > > Can this part and its surrounding code be made thread-safe? > > > > > > > > I think this particular method call has to be done *only* from the > > > > main thread. I imagine that could be a problem. > > > > > > It could be a problem, yes. But what does this do, exactly, and why > > > does it need to be called as part of ns_select? > > > > It runs an event loop that picks up all GUI events and then dispatches > > them. It’s part of NextStep. It’s unclear to me why it’s run in > > ns_select, but presumably it’s because it needs to be run somewhere > > and whoever wrote it thought that was a good place. > > > > If we need to, I expect we could move it to its own thread. That seems > > to be a known pattern in the GNUStep/Cocoa world. > > That's probably the only reasonable way. But why does it use > record_unwind_protect and unbind_to in the first place? What happens > if the user presses C-g while the event loop runs? It was added in change 08f27aa39c498d34418c7420b33bf2db913827c3 which relates to bug 18345. Previously it was simply apploopnr--, but sometimes users would find themselves in a situation where that line was never run (hitting C‐g while the event loop runs?) so the next time ns_select (or ns_read_socket) ran it aborted. I take it unbind_to fixes that particular problem. Is there a safer way of ensuring that apploopnr is decremented? I’m slowly beginning to understand what’s going on in ns_select. It seems the idea is that it should detect both input on file descriptors (using pselect in the background), and NS events coming from [NSApp run]. The following is for my own future reference, if nothing else. There is another thread that runs in a loop (fd_handler), and when it’s signalled from ns_select, it runs pselect. At the same time ns_select sets up a timer, then it calls [NSApp run]. If either the pselect thread, or the timer run out before any input is detected, they send a user defined event to the NSApp event loop so it ends. Similarly if the pselect thread detects input it sends an event to the NSApp loop, which then ends. If there’s NS input, it’s processed by the NSApp loop, which then ends. Whatever happens, the NSApp loop eventually returns control back to ns_select, which works out what happened by examining the last NS event and returns the relevant value. I have my doubts this is thread safe. The communication between ns_select and fd_handler is done by setting static variables and then running: c = 'g'; emacs_write_sig (selfds[1], &c, 1); I don’t really know what that does. Sends something on an fd? Then it writes back to the same global variables for ns_select to pick up. Now I’ve written it down it seems a lot less complicated... -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 12:13:10 2016 Received: (at 25265) by debbugs.gnu.org; 29 Dec 2016 17:13:10 +0000 Received: from localhost ([127.0.0.1]:59311 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMeGM-0007SO-17 for submit@debbugs.gnu.org; Thu, 29 Dec 2016 12:13:10 -0500 Received: from eggs.gnu.org ([208.118.235.92]:43922) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMeGK-0007SB-I1 for 25265@debbugs.gnu.org; Thu, 29 Dec 2016 12:13:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cMeGC-0004jc-2G for 25265@debbugs.gnu.org; Thu, 29 Dec 2016 12:13:03 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55784) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMeGB-0004jY-Ue; Thu, 29 Dec 2016 12:12:59 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1318 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cMeGB-0002sy-5V; Thu, 29 Dec 2016 12:12:59 -0500 Date: Thu, 29 Dec 2016 19:12:54 +0200 Message-Id: <83vau2u0a1.fsf@gnu.org> From: Eli Zaretskii To: Alan Third In-reply-to: <20161228193633.GA47290@breton.holly.idiocy.org> (message from Alan Third on Wed, 28 Dec 2016 19:36:33 +0000) Subject: Re: bug#25265: make-thread crashes in OS X 10.6 References: <83r34xxlke.fsf@gnu.org> <83d1ggxayi.fsf@gnu.org> <20161226130917.GA36471@breton.holly.idiocy.org> <8337hay9fl.fsf@gnu.org> <20161226205632.GA36805@breton.holly.idiocy.org> <83k2alx20b.fsf@gnu.org> <20161227104424.GA45039@breton.holly.idiocy.org> <83bmvxwrp4.fsf@gnu.org> <20161228193633.GA47290@breton.holly.idiocy.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.2 (--------) X-Debbugs-Envelope-To: 25265 Cc: charles@aurox.ch, 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.2 (--------) > Date: Wed, 28 Dec 2016 19:36:33 +0000 > From: Alan Third > Cc: charles@aurox.ch, 25265@debbugs.gnu.org > > > That's probably the only reasonable way. But why does it use > > record_unwind_protect and unbind_to in the first place? What happens > > if the user presses C-g while the event loop runs? > > It was added in change 08f27aa39c498d34418c7420b33bf2db913827c3 which > relates to bug 18345. Previously it was simply apploopnr--, but > sometimes users would find themselves in a situation where that line > was never run (hitting C‐g while the event loop runs?) so the next > time ns_select (or ns_read_socket) ran it aborted. I take it unbind_to > fixes that particular problem. > > Is there a safer way of ensuring that apploopnr is decremented? There could be, but I see that ns_select and ns_read_socket use it for some kind of synchronization between them, which I don't really understand, so I cannot answer that question. > I’m slowly beginning to understand what’s going on in ns_select. It > seems the idea is that it should detect both input on file descriptors > (using pselect in the background), and NS events coming from [NSApp > run]. What do "NS events" include? Do they include, for example, keyboard input? Also, does C-g cause a signal or some other async event on NS, which could potentially interrupt the [NSApp run] stuff? Or could SIGIO do that (does NS use SIGIO for input?)? If nothing could interrupt/QUIT [NSApp run], then I don't really understand why we have unwind_protect there. The bug in question cites some undisclosed Lisp for reproducing the problem, so I wonder how could that cause [NSApp run] to be interrupted and longjmp to higher level. > There is another thread that runs in a loop (fd_handler), and when > it’s signalled from ns_select, it runs pselect. At the same time > ns_select sets up a timer, then it calls [NSApp run]. (I think ns_select only sets up a timer when there are no descriptors to watch, to avoid waking up the fd_handler thread in that case.) So this means there are 2 jobs to be done here: the pselect call and the [NSApp run] call. > If either the pselect thread, or the timer run out before any input is > detected, they send a user defined event to the NSApp event loop so it > ends. > > Similarly if the pselect thread detects input it sends an event to the > NSApp loop, which then ends. > > If there’s NS input, it’s processed by the NSApp loop Processed how? Shouldn't Emacs be involved in this processing? IOW, these events should be read by Emacs, via the read_socket_hook. > Whatever happens, the NSApp loop eventually returns control back to > ns_select, which works out what happened by examining the last NS > event and returns the relevant value. > > I have my doubts this is thread safe. It isn't. Unless each Emacs application thread will have its own fd_handler thread. One possible solution might be to let only one thread, say the main thread, to call [NSApp run]. The other threads, when they get into ns_select, will behave as if Emacs runs in non-GUI mode, and will only call pselect. Not sure what this will mean from the POV of all threads being equal (since the delicate dance between ns_select and ns_read_socket is still unclear to me), but at least it might avoid crashes and hangs. Can you try something like that? > The communication between ns_select and fd_handler is done by > setting static variables and then running: > > c = 'g'; > emacs_write_sig (selfds[1], &c, 1); > > I don’t really know what that does. Sends something on an fd? Yes. I guess 'g' stands for GO and 's' stands for SUSPEND. These are commands to the fd_handler thread, or so it seems. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 30 13:45:39 2016 Received: (at 25265) by debbugs.gnu.org; 30 Dec 2016 18:45:39 +0000 Received: from localhost ([127.0.0.1]:60600 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cN2BP-0007Ln-43 for submit@debbugs.gnu.org; Fri, 30 Dec 2016 13:45:39 -0500 Received: from mail-wj0-f174.google.com ([209.85.210.174]:35042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cN2BN-0007Lb-R1 for 25265@debbugs.gnu.org; Fri, 30 Dec 2016 13:45:38 -0500 Received: by mail-wj0-f174.google.com with SMTP id v7so383753895wjy.2 for <25265@debbugs.gnu.org>; Fri, 30 Dec 2016 10:45:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=38lEhmpaW76fQSaNtjtAqb9/aKmBpiPowxE7FAB+Ufw=; b=UxvRUyxmD2M1jKOoRick9AaGT1nZ4wVr2ym0aAtiYxPQh48JwhBw3WWoEIZeNsH8Pq p/w4yoUFYqm79jbRLePMbLA/xs6Obz/uJh7oy0hFGymU2MdWbfAoMlHWPahQRf9dw8DC LGg/KptMjeI6nYcWb00IlMwBPfFo9J0U+wp08xfyX9Bq6gRTQ2KPu3++yvYQtlp1BoOm vlgzAJfGWzFv7NalCrS/IomvV0VPUbSpT8wm33OkwU/UfVJlhhLJ37V0WDez5sbfXyin Ds/gl3itU9BWIZUHA8BB18GWszwRhyniuGtMcMuz56hMKfpKHqnmLEyJFtgOOldi+sFC mljw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=38lEhmpaW76fQSaNtjtAqb9/aKmBpiPowxE7FAB+Ufw=; b=nRs1j9ASBGZa0iMomOv/edXpwW6z4UAnFaxMndMsR2+6F0b96vAgNe5eEcs9ze0CBs q4mnwXHtahFpQSC3iQTpBF0Kp4llkU67ND5MDYIvPZidfbsH+GUAfHTvvbEj/ZWdTyYu aqbfBdCibPbxZQisyHaCwaPFDy9nh8X8Xmz6ctmlDdqJF68Rx/2KuDFdwdgK6WaFjk9Q yHcU+pESq2ndv7AeHle5+O47qrbaS1MnCQwrQCn8SF/+vueAtPwg+QdWOOaLAtO8Y5Gv FHDuqaRAAVG1SgIFLvQB+4gd+yWLZbtMOuG9betndRngyUWpfQZRSGoF4nFgWcRPwov4 MpnA== X-Gm-Message-State: AIkVDXJzCQrK8Ro3Xt3yxaPOdIi5rL9tXdMwpjiPb5tKaGFs6Wl7ifj471/5nYuB36qgAw== X-Received: by 10.194.151.132 with SMTP id uq4mr38494773wjb.229.1483123532004; Fri, 30 Dec 2016 10:45:32 -0800 (PST) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-fcf8-7042-dd5f-6680.holly.idiocy.org. [2001:8b0:3f8:8129:fcf8:7042:dd5f:6680]) by smtp.gmail.com with ESMTPSA id e6sm74857461wjw.33.2016.12.30.10.45.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Dec 2016 10:45:31 -0800 (PST) Date: Fri, 30 Dec 2016 18:45:32 +0000 From: Alan Third To: Eli Zaretskii Subject: Re: bug#25265: make-thread crashes in OS X 10.6 Message-ID: <20161230184532.GA3754@breton.holly.idiocy.org> References: <83r34xxlke.fsf@gnu.org> <83d1ggxayi.fsf@gnu.org> <20161226130917.GA36471@breton.holly.idiocy.org> <8337hay9fl.fsf@gnu.org> <20161226205632.GA36805@breton.holly.idiocy.org> <83k2alx20b.fsf@gnu.org> <20161227104424.GA45039@breton.holly.idiocy.org> <83bmvxwrp4.fsf@gnu.org> <20161228193633.GA47290@breton.holly.idiocy.org> <83vau2u0a1.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83vau2u0a1.fsf@gnu.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 25265 Cc: charles@aurox.ch, 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) On Thu, Dec 29, 2016 at 07:12:54PM +0200, Eli Zaretskii wrote: > > Date: Wed, 28 Dec 2016 19:36:33 +0000 > > From: Alan Third > > Cc: charles@aurox.ch, 25265@debbugs.gnu.org > > > > I’m slowly beginning to understand what’s going on in ns_select. It > > seems the idea is that it should detect both input on file descriptors > > (using pselect in the background), and NS events coming from [NSApp > > run]. > > What do "NS events" include? Do they include, for example, keyboard > input? As far as I can tell it’s mouse and keyboard input, as well as messages from the ‘window manager’, telling it to close the frame, etc. > > There is another thread that runs in a loop (fd_handler), and when > > it’s signalled from ns_select, it runs pselect. At the same time > > ns_select sets up a timer, then it calls [NSApp run]. > > (I think ns_select only sets up a timer when there are no descriptors > to watch, to avoid waking up the fd_handler thread in that case.) > > So this means there are 2 jobs to be done here: the pselect call and > the [NSApp run] call. Correct on both counts. > > If there’s NS input, it’s processed by the NSApp loop > > Processed how? Shouldn't Emacs be involved in this processing? IOW, > these events should be read by Emacs, via the read_socket_hook. Ah! Is this the missing piece of the puzzle? When the [NSApp run] loop receives an event, say keyboard input, it creates an emacs_event and then raises SIGIO (via hold_event). SIGIO causes ns_read_socket to be run, which ALSO tries to run [NSApp run]. Am I right in thinking that raising SIGIO will cause ns_read_socket to be potentially run immediately? Asynchronously? I’ve just commented out the section of ns_read_socket that calls [NSApp run] and I can’t see any difference in behaviour. I suspect that someone’s doubled up on it when they didn’t need to. > One possible solution might be to let only one thread, say the main > thread, to call [NSApp run]. The other threads, when they get into > ns_select, will behave as if Emacs runs in non-GUI mode, and will only > call pselect. Not sure what this will mean from the POV of all > threads being equal (since the delicate dance between ns_select and > ns_read_socket is still unclear to me), but at least it might avoid > crashes and hangs. Can you try something like that? Yes, I will. Am I right in thinking that if we remove all the NSApp junk from ns_select it will literally just be calling pselect with the same arguments? So, my plan of action: Run [NSApp run] in it’s own thread with no flow control (unless it’s important that emacs events are only created at specific times?) Replace ns_select with pselect. Thanks for helping with this, I don’t think I’d be able to work it out on my own. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 30 16:09:07 2016 Received: (at 25265) by debbugs.gnu.org; 30 Dec 2016 21:09:07 +0000 Received: from localhost ([127.0.0.1]:60642 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cN4QE-0002H2-PB for submit@debbugs.gnu.org; Fri, 30 Dec 2016 16:09:07 -0500 Received: from eggs.gnu.org ([208.118.235.92]:52650) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cN4QD-0002GY-27 for 25265@debbugs.gnu.org; Fri, 30 Dec 2016 16:09:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cN4Q3-0004RT-Pk for 25265@debbugs.gnu.org; Fri, 30 Dec 2016 16:08:59 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cN4Q3-0004RP-M6; Fri, 30 Dec 2016 16:08:55 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3366 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cN4Q2-0005HN-Ua; Fri, 30 Dec 2016 16:08:55 -0500 Date: Fri, 30 Dec 2016 23:08:54 +0200 Message-Id: <83pok9ruop.fsf@gnu.org> From: Eli Zaretskii To: Alan Third In-reply-to: <20161230184532.GA3754@breton.holly.idiocy.org> (message from Alan Third on Fri, 30 Dec 2016 18:45:32 +0000) Subject: Re: bug#25265: make-thread crashes in OS X 10.6 References: <83r34xxlke.fsf@gnu.org> <83d1ggxayi.fsf@gnu.org> <20161226130917.GA36471@breton.holly.idiocy.org> <8337hay9fl.fsf@gnu.org> <20161226205632.GA36805@breton.holly.idiocy.org> <83k2alx20b.fsf@gnu.org> <20161227104424.GA45039@breton.holly.idiocy.org> <83bmvxwrp4.fsf@gnu.org> <20161228193633.GA47290@breton.holly.idiocy.org> <83vau2u0a1.fsf@gnu.org> <20161230184532.GA3754@breton.holly.idiocy.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.2 (--------) X-Debbugs-Envelope-To: 25265 Cc: charles@aurox.ch, 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.2 (--------) > Date: Fri, 30 Dec 2016 18:45:32 +0000 > From: Alan Third > Cc: charles@aurox.ch, 25265@debbugs.gnu.org > > > > If there’s NS input, it’s processed by the NSApp loop > > > > Processed how? Shouldn't Emacs be involved in this processing? IOW, > > these events should be read by Emacs, via the read_socket_hook. > > Ah! Is this the missing piece of the puzzle? When the [NSApp run] loop > receives an event, say keyboard input, it creates an emacs_event and > then raises SIGIO (via hold_event). SIGIO causes ns_read_socket to be > run, which ALSO tries to run [NSApp run]. > > Am I right in thinking that raising SIGIO will cause ns_read_socket to > be potentially run immediately? Asynchronously? I very much hope not. We don't run any non-trivial code from a signal handler. I'd expect SIGIO just to set a flag, and then the resulting input be processed when we call unblock_input next time, and the blocking level gets to zero. Then we run process_pending_signals, which calls handle_async_input, and that's where ns_read_socket will be called by gobble_input. > I’ve just commented out the section of ns_read_socket that calls > [NSApp run] and I can’t see any difference in behaviour. I suspect > that someone’s doubled up on it when they didn’t need to. I cannot help you here. Maybe it's needed for Emacs to be more responsive? If you run "git log -L" on ns_read_socket, does the history tell anything about why this call was added? Perhaps some discussion or bug report? > > One possible solution might be to let only one thread, say the main > > thread, to call [NSApp run]. The other threads, when they get into > > ns_select, will behave as if Emacs runs in non-GUI mode, and will only > > call pselect. Not sure what this will mean from the POV of all > > threads being equal (since the delicate dance between ns_select and > > ns_read_socket is still unclear to me), but at least it might avoid > > crashes and hangs. Can you try something like that? > > Yes, I will. Am I right in thinking that if we remove all the NSApp > junk from ns_select it will literally just be calling pselect with > the same arguments? It looks like that, yes. > So, my plan of action: > > Run [NSApp run] in it’s own thread with no flow control (unless it’s > important that emacs events are only created at specific times?) How will that thread communicate the events to Emacs? > Thanks for helping with this, I don’t think I’d be able to work it out > on my own. Thank you for digging into the problem. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 30 17:05:55 2016 Received: (at 25265) by debbugs.gnu.org; 30 Dec 2016 22:05:55 +0000 Received: from localhost ([127.0.0.1]:60649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cN5JD-0003a0-At for submit@debbugs.gnu.org; Fri, 30 Dec 2016 17:05:55 -0500 Received: from mail-wm0-f52.google.com ([74.125.82.52]:34957) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cN5JB-0003Zm-5v for 25265@debbugs.gnu.org; Fri, 30 Dec 2016 17:05:53 -0500 Received: by mail-wm0-f52.google.com with SMTP id a197so329318750wmd.0 for <25265@debbugs.gnu.org>; Fri, 30 Dec 2016 14:05:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=ZQr6BoficrHDcLBD/lOt7v9UAS+lZld3UpdLmdvfYrs=; b=lh8uhCfYrSRPeD8DnX1JXAFWQHc0toEuNmy3cnSNkN9z7Cvhd33heMNub9fLgZaWjw cqe1MGFTNyQUayjkolXK2OYmzq/uA3iFH4nA6xi6BdtsMg3rw4ARlzBrftEvQvTUtb53 tTqTiVlUFYezv13M6uJ0eepllLyu8a+8KN6Ini9aa3A2/QWlZjD877//tGFaWues884I wcuQRQM4ahmLIoPqVvsfjO1fmmIT40KrhSXFSobVMRtsYWcY6d9fh4n8ORGzS2Wiiz0e TSVzOR9vaT+MDR4Q04M8loAKojyYn3KqrDTa/mUCErXjZt+DiEsj4/ebSA3owKZYSgJh NxhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=ZQr6BoficrHDcLBD/lOt7v9UAS+lZld3UpdLmdvfYrs=; b=EuMVIAeiGzMKSH3pflMgqVOaRdK/IddAPOF/R7Kv0X4NIcOLlrLZN+TuULT4sDEKPP og6eg72JBC8JXd3a29zddEgjWFnyuYTEv9cFpkWAeoGxF1zaWpnW1UGr5eVm3tcWuntU qFpNcXBY1GCEqMrBwwLsgKBO2A8aNbQ+yp6Wu3VAebNA2myLKIIzTIKUUvqq2VVx5Z/B dtoEAb2Kcr+G5kKRgsP4ZUdAcv7dOWHUHv9RsSkFvadcn0xmnsHIdujyJRXYpOt2GX+R ImWRFhghqb4CrbsIFL3rG2xIeilOC5+E9wnrxZieIfah4TK5TeqzM6pR6WQepSTiWtYH tWZA== X-Gm-Message-State: AIkVDXJe6MIbKW+cJK4k34LrGqiWMupAia3dx+i23tPAyKcnlfRZQOnD0nQkPks/xg+buw== X-Received: by 10.28.214.133 with SMTP id n127mr47150610wmg.28.1483135547390; Fri, 30 Dec 2016 14:05:47 -0800 (PST) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-fcf8-7042-dd5f-6680.holly.idiocy.org. [2001:8b0:3f8:8129:fcf8:7042:dd5f:6680]) by smtp.gmail.com with ESMTPSA id cj1sm4677399wjd.46.2016.12.30.14.05.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Dec 2016 14:05:46 -0800 (PST) Date: Fri, 30 Dec 2016 22:05:44 +0000 From: Alan Third To: Eli Zaretskii Subject: Re: bug#25265: make-thread crashes in OS X 10.6 Message-ID: <20161230220544.GA4775@breton.holly.idiocy.org> References: <20161226130917.GA36471@breton.holly.idiocy.org> <8337hay9fl.fsf@gnu.org> <20161226205632.GA36805@breton.holly.idiocy.org> <83k2alx20b.fsf@gnu.org> <20161227104424.GA45039@breton.holly.idiocy.org> <83bmvxwrp4.fsf@gnu.org> <20161228193633.GA47290@breton.holly.idiocy.org> <83vau2u0a1.fsf@gnu.org> <20161230184532.GA3754@breton.holly.idiocy.org> <83pok9ruop.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83pok9ruop.fsf@gnu.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 25265 Cc: charles@aurox.ch, 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) On Fri, Dec 30, 2016 at 11:08:54PM +0200, Eli Zaretskii wrote: > > Date: Fri, 30 Dec 2016 18:45:32 +0000 > > From: Alan Third > > Cc: charles@aurox.ch, 25265@debbugs.gnu.org > > > > Ah! Is this the missing piece of the puzzle? When the [NSApp run] loop > > receives an event, say keyboard input, it creates an emacs_event and > > then raises SIGIO (via hold_event). SIGIO causes ns_read_socket to be > > run, which ALSO tries to run [NSApp run]. > > > > Am I right in thinking that raising SIGIO will cause ns_read_socket to > > be potentially run immediately? Asynchronously? > > I very much hope not. We don't run any non-trivial code from a signal > handler. I'd expect SIGIO just to set a flag, and then the resulting > input be processed when we call unblock_input next time, and the > blocking level gets to zero. Then we run process_pending_signals, > which calls handle_async_input, and that's where ns_read_socket will > be called by gobble_input. OK. I am, again, none the wiser. > > I’ve just commented out the section of ns_read_socket that calls > > [NSApp run] and I can’t see any difference in behaviour. I suspect > > that someone’s doubled up on it when they didn’t need to. > > I cannot help you here. Maybe it's needed for Emacs to be more > responsive? If you run "git log -L" on ns_read_socket, does the > history tell anything about why this call was added? Perhaps some > discussion or bug report? It’s been there since the NS port was integrated, it seems. > > So, my plan of action: > > > > Run [NSApp run] in it’s own thread with no flow control (unless it’s > > important that emacs events are only created at specific times?) > > How will that thread communicate the events to Emacs? I’m hoping using the same method as it does now. It creates emacs events from the NS events, and then fires SIGIO. I have run into a problem almost right away, though. I don’t know how to go about creating this thread. The NSApp loop needs to run in the ‘main’ thread on macOS. I understand the main thread is always the original thread, so if I want to use it for the NSApp loop, I need to move Emacs’ normal operation into a child thread. I don’t have any experience with pthreads and can’t see any obvious way of doing it (and I think, from my experiments, it breaks unexec or something). Is it possible, or can you think of a better way of handling this? Thanks! -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 31 04:20:44 2016 Received: (at 25265) by debbugs.gnu.org; 31 Dec 2016 09:20:44 +0000 Received: from localhost ([127.0.0.1]:60847 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNFqG-0004Ff-AQ for submit@debbugs.gnu.org; Sat, 31 Dec 2016 04:20:44 -0500 Received: from eggs.gnu.org ([208.118.235.92]:51427) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNFqF-0004FS-A4 for 25265@debbugs.gnu.org; Sat, 31 Dec 2016 04:20:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNFq6-000457-Lw for 25265@debbugs.gnu.org; Sat, 31 Dec 2016 04:20:37 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44640) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNFq6-00044y-Bq; Sat, 31 Dec 2016 04:20:34 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3929 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cNFq5-0008LJ-GQ; Sat, 31 Dec 2016 04:20:34 -0500 Date: Sat, 31 Dec 2016 11:20:34 +0200 Message-Id: <83vau0h2u5.fsf@gnu.org> From: Eli Zaretskii To: Alan Third In-reply-to: <20161230220544.GA4775@breton.holly.idiocy.org> (message from Alan Third on Fri, 30 Dec 2016 22:05:44 +0000) Subject: Re: bug#25265: make-thread crashes in OS X 10.6 References: <20161226130917.GA36471@breton.holly.idiocy.org> <8337hay9fl.fsf@gnu.org> <20161226205632.GA36805@breton.holly.idiocy.org> <83k2alx20b.fsf@gnu.org> <20161227104424.GA45039@breton.holly.idiocy.org> <83bmvxwrp4.fsf@gnu.org> <20161228193633.GA47290@breton.holly.idiocy.org> <83vau2u0a1.fsf@gnu.org> <20161230184532.GA3754@breton.holly.idiocy.org> <83pok9ruop.fsf@gnu.org> <20161230220544.GA4775@breton.holly.idiocy.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.2 (--------) X-Debbugs-Envelope-To: 25265 Cc: charles@aurox.ch, 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.2 (--------) > Date: Fri, 30 Dec 2016 22:05:44 +0000 > From: Alan Third > Cc: charles@aurox.ch, 25265@debbugs.gnu.org > > > > Am I right in thinking that raising SIGIO will cause ns_read_socket to > > > be potentially run immediately? Asynchronously? > > > > I very much hope not. We don't run any non-trivial code from a signal > > handler. I'd expect SIGIO just to set a flag, and then the resulting > > input be processed when we call unblock_input next time, and the > > blocking level gets to zero. Then we run process_pending_signals, > > which calls handle_async_input, and that's where ns_read_socket will > > be called by gobble_input. > > OK. I am, again, none the wiser. Don't give up ;-) > > > So, my plan of action: > > > > > > Run [NSApp run] in it’s own thread with no flow control (unless it’s > > > important that emacs events are only created at specific times?) > > > > How will that thread communicate the events to Emacs? > > I’m hoping using the same method as it does now. It creates emacs > events from the NS events, and then fires SIGIO. > > I have run into a problem almost right away, though. I don’t know how > to go about creating this thread. > > The NSApp loop needs to run in the ‘main’ thread on macOS. I > understand the main thread is always the original thread, so if I want > to use it for the NSApp loop, I need to move Emacs’ normal operation > into a child thread. How about a more modest goal instead? The code in ns_select can detect when it is run by the main thread: we have a function, main_thread_p, for that. (For it to work, you need to pass current_thread to it, so we will have to make sure the first part of ns_select, up to the pselect call, is run with the global lock owned by a single thread. The easiest way of achieving that is to do for ns_select the same change I did yesterday for xg_select: call ns_select directly in process.c:wait_reading_process_output, then change ns_select to call thread_select instead of pselect.) When ns_select detects it's run by a non-main thread, it will only call thread_select and return its result. Otherwise, it will call thread_select with a very small timeout and with NULL descriptor sets (to let other threads an opportunity to run, and when that returns, do the [NSApp run] dance with the surrounding code. Note that the latter runs after the main thread has re-acquired the global lock, so no other Lisp threads could be active at that point. Would that work? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 31 11:09:41 2016 Received: (at 25265) by debbugs.gnu.org; 31 Dec 2016 16:09:41 +0000 Received: from localhost ([127.0.0.1]:33387 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNME0-0007Bi-PJ for submit@debbugs.gnu.org; Sat, 31 Dec 2016 11:09:41 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:34614) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNMDz-0007BS-3s for 25265@debbugs.gnu.org; Sat, 31 Dec 2016 11:09:39 -0500 Received: by mail-wm0-f68.google.com with SMTP id c85so37460332wmi.1 for <25265@debbugs.gnu.org>; Sat, 31 Dec 2016 08:09:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=GKRueCPN26bVrJxqpxUYhp44F3jkJPpWhtJBEhLISVA=; b=AEGwktJ8lFRrua/z/uhDMIlY7EDKOXmO0GgnvxXsGV2ORmoj4WzmpJgANDmswuoNfo 5oRDRb76GAqo3dqfw4JXGYEVtMWntDFdVJAs/jepQEBV4m31/KVtPOHwLEpcYiqzMIBB /tOoj3h17qIvGGQ/R7Np3ty2CfGvNZsSlv9uwaekKyzcDnQhqTZ6Un62ccKZOjOShnus fUzXJXuuCydx5U6yuZSvp2TrEk95Rap2N8z9RT1F2kacII87cgeUwTd2YECIuhWRxJ8q 46r6lqn4Tu+P5iBgTNXbVHyhng9ZGiZXpugF8buO95wtPHjQiL0cJMwdP1i6FhlZ/TW+ FWuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=GKRueCPN26bVrJxqpxUYhp44F3jkJPpWhtJBEhLISVA=; b=UW1d1EIgw42qxCnS22r2YodoBCNHtu+D0JtWxgh9g2V7qdoawth1d0Ei+OH1OsIjvD bBaCwcwr4duKuwFVW7c+Hh7xP45tamo55lnu0zzRgu9+k+KqNmjreR3AQhZifwT4KEFD NcJyKT5SK1UMPc6sclOaBqYQ3iqpq0h7AJ4TX5puXTsub1mAeUrYC+L8S+G8FNvvaaPO 997eNLsAMv3a1bg8bTc254Kco5WMwQlsENI8wgaDNJZoi+GWTcc+KOMfOD9mdrFARxuo cjlkZL1b8ho+0GP5Wndbz6SXecZduHQSg5NeKbTQ5GnfYIMop/sEtyGFFO90xaA4AV4i pRAQ== X-Gm-Message-State: AIkVDXIK0QObGa0DTfjMJVdZRaL2qkM9D3mmorDeuhVys6ToZSyOEHK3oolfCSkAnfFXrA== X-Received: by 10.28.52.201 with SMTP id b192mr42371969wma.118.1483200573029; Sat, 31 Dec 2016 08:09:33 -0800 (PST) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-fcf8-7042-dd5f-6680.holly.idiocy.org. [2001:8b0:3f8:8129:fcf8:7042:dd5f:6680]) by smtp.gmail.com with ESMTPSA id cl6sm78941883wjc.10.2016.12.31.08.09.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Dec 2016 08:09:32 -0800 (PST) Date: Sat, 31 Dec 2016 16:09:30 +0000 From: Alan Third To: Eli Zaretskii Subject: [PATCH] Rework NS event handling (bug#25265) Message-ID: <20161231160930.GA29122@breton.holly.idiocy.org> References: <83vau0h2u5.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83vau0h2u5.fsf@gnu.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 25265 Cc: charles@aurox.ch, 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) * src/nsterm.m (unwind_apploopnr): Remove. (ns_read_socket): Remove references to apploopnr. Make processing the NS event loop conditional on being in the main thread. (ns_select): Remove references to apploopnr. Remove all fd_handler related stuff. Check if there are events waiting on the NS event queue rather than running the event loop. Remove unused variables and code. (fd_handler): Remove. (ns_term_init): Remove creation of fd_handler thread. (hold_event, EmacsApp:sendEvent, EmacsView:mouseMoved, EmacsView:windowDidExpose): Remove send_appdefined. (ns_send_appdefined): Always check the event queue for applicationDefined events rather than relying on send_appdefined var. * src/nsterm.h: Remove reference to fd_handler method. --- src/nsterm.h | 1 - src/nsterm.m | 380 +++++++++++------------------------------------------------ 2 files changed, 68 insertions(+), 313 deletions(-) diff --git a/src/nsterm.h b/src/nsterm.h index 35c6e1a..dc222a7 100644 --- a/src/nsterm.h +++ b/src/nsterm.h @@ -392,7 +392,6 @@ char const * nstrace_fullscreen_type_name (int); - (void)sendEvent: (NSEvent *)theEvent; - (void)showPreferencesWindow: (id)sender; - (BOOL) openFile: (NSString *)fileName; -- (void)fd_handler: (id)unused; - (void)timeout_handler: (NSTimer *)timedEntry; - (BOOL)fulfillService: (NSString *)name withArg: (NSString *)arg; #ifdef NS_IMPL_GNUSTEP diff --git a/src/nsterm.m b/src/nsterm.m index 7e6ec85..98fd8ab 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -279,18 +279,10 @@ - (NSColor *)colorUsingDefaultColorSpace /*static int debug_lock = 0; */ /* event loop */ -static BOOL send_appdefined = YES; #define NO_APPDEFINED_DATA (-8) static int last_appdefined_event_data = NO_APPDEFINED_DATA; static NSTimer *timed_entry = 0; static NSTimer *scroll_repeat_entry = nil; -static fd_set select_readfds, select_writefds; -enum { SELECT_HAVE_READ = 1, SELECT_HAVE_WRITE = 2, SELECT_HAVE_TMO = 4 }; -static int select_nfds = 0, select_valid = 0; -static struct timespec select_timeout = { 0, 0 }; -static int selfds[2] = { -1, -1 }; -static pthread_mutex_t select_mutex; -static int apploopnr = 0; static NSAutoreleasePool *outerpool; static struct input_event *emacs_event = NULL; static struct input_event *q_event_ptr = NULL; @@ -457,7 +449,6 @@ - (NSColor *)colorUsingDefaultColorSpace hold_event_q.q[hold_event_q.nr++] = *event; /* Make sure ns_read_socket is called, i.e. we have input. */ raise (SIGIO); - send_appdefined = YES; } static Lisp_Object @@ -3872,31 +3863,17 @@ overwriting cursor (usually when cursor on a tab) */ return; } - /* Only post this event if we haven't already posted one. This will end - the [NXApp run] main loop after having processed all events queued at - this moment. */ - -#ifdef NS_IMPL_COCOA - if (! send_appdefined) - { - /* OS X 10.10.1 swallows the AppDefined event we are sending ourselves - in certain situations (rapid incoming events). - So check if we have one, if not add one. */ - NSEvent *appev = [NSApp nextEventMatchingMask:NSEventMaskApplicationDefined - untilDate:[NSDate distantPast] - inMode:NSDefaultRunLoopMode - dequeue:NO]; - if (! appev) send_appdefined = YES; - } -#endif - - if (send_appdefined) + /* Only post this event if we haven't already posted one. This will + end the [NXApp run] main loop after having processed all events + queued at this moment. */ + NSEvent *appev = [NSApp nextEventMatchingMask:NSEventMaskApplicationDefined + untilDate:[NSDate distantPast] + inMode:NSDefaultRunLoopMode + dequeue:NO]; + if (! appev) { NSEvent *nxev; - /* We only need one NX_APPDEFINED event to stop NXApp from running. */ - send_appdefined = NO; - /* Don't need wakeup timer any more */ if (timed_entry) { @@ -4011,14 +3988,6 @@ in certain situations (rapid incoming events). } #endif /* NS_IMPL_COCOA */ -static void -unwind_apploopnr (Lisp_Object not_used) -{ - --apploopnr; - n_emacs_events_pending = 0; - ns_finish_events (); - q_event_ptr = NULL; -} static int ns_read_socket (struct terminal *terminal, struct input_event *hold_quit) @@ -4029,13 +3998,10 @@ in certain situations (rapid incoming events). -------------------------------------------------------------------------- */ { struct input_event ev; - int nevents; + int nevents = 0; NSTRACE_WHEN (NSTRACE_GROUP_EVENTS, "ns_read_socket"); - if (apploopnr > 0) - return -1; /* Already within event loop. */ - #ifdef HAVE_NATIVE_FS check_native_fs (); #endif @@ -4052,54 +4018,49 @@ in certain situations (rapid incoming events). return i; } - block_input (); - n_emacs_events_pending = 0; - ns_init_events (&ev); - q_event_ptr = hold_quit; - - /* we manage autorelease pools by allocate/reallocate each time around - the loop; strict nesting is occasionally violated but seems not to - matter.. earlier methods using full nesting caused major memory leaks */ - [outerpool release]; - outerpool = [[NSAutoreleasePool alloc] init]; - - /* If have pending open-file requests, attend to the next one of those. */ - if (ns_pending_files && [ns_pending_files count] != 0 - && [(EmacsApp *)NSApp openFile: [ns_pending_files objectAtIndex: 0]]) + if ([NSThread isMainThread]) { - [ns_pending_files removeObjectAtIndex: 0]; - } - /* Deal with pending service requests. */ - else if (ns_pending_service_names && [ns_pending_service_names count] != 0 - && [(EmacsApp *) - NSApp fulfillService: [ns_pending_service_names objectAtIndex: 0] - withArg: [ns_pending_service_args objectAtIndex: 0]]) - { - [ns_pending_service_names removeObjectAtIndex: 0]; - [ns_pending_service_args removeObjectAtIndex: 0]; - } - else - { - ptrdiff_t specpdl_count = SPECPDL_INDEX (); - /* Run and wait for events. We must always send one NX_APPDEFINED event - to ourself, otherwise [NXApp run] will never exit. */ - send_appdefined = YES; - ns_send_appdefined (-1); - - if (++apploopnr != 1) + block_input (); + n_emacs_events_pending = 0; + ns_init_events (&ev); + q_event_ptr = hold_quit; + + /* we manage autorelease pools by allocate/reallocate each time around + the loop; strict nesting is occasionally violated but seems not to + matter.. earlier methods using full nesting caused major memory leaks */ + [outerpool release]; + outerpool = [[NSAutoreleasePool alloc] init]; + + /* If have pending open-file requests, attend to the next one of those. */ + if (ns_pending_files && [ns_pending_files count] != 0 + && [(EmacsApp *)NSApp openFile: [ns_pending_files objectAtIndex: 0]]) { - emacs_abort (); + [ns_pending_files removeObjectAtIndex: 0]; } - record_unwind_protect (unwind_apploopnr, Qt); - [NSApp run]; - unbind_to (specpdl_count, Qnil); /* calls unwind_apploopnr */ - } + /* Deal with pending service requests. */ + else if (ns_pending_service_names && [ns_pending_service_names count] != 0 + && [(EmacsApp *) + NSApp fulfillService: [ns_pending_service_names objectAtIndex: 0] + withArg: [ns_pending_service_args objectAtIndex: 0]]) + { + [ns_pending_service_names removeObjectAtIndex: 0]; + [ns_pending_service_args removeObjectAtIndex: 0]; + } + else + { + /* Run and wait for events. We must always send one NX_APPDEFINED event + to ourself, otherwise [NXApp run] will never exit. */ + ns_send_appdefined (-1); - nevents = n_emacs_events_pending; - n_emacs_events_pending = 0; - ns_finish_events (); - q_event_ptr = NULL; - unblock_input (); + [NSApp run]; + } + + nevents = n_emacs_events_pending; + n_emacs_events_pending = 0; + ns_finish_events (); + q_event_ptr = NULL; + unblock_input (); + } return nevents; } @@ -4114,15 +4075,11 @@ in certain situations (rapid incoming events). -------------------------------------------------------------------------- */ { int result; - int t, k, nr = 0; - struct input_event event; - char c; + NSDate *timeout_date = nil; + NSEvent *ns_event; NSTRACE_WHEN (NSTRACE_GROUP_EVENTS, "ns_select"); - if (apploopnr > 0) - return -1; /* Already within event loop. */ - #ifdef HAVE_NATIVE_FS check_native_fs (); #endif @@ -4135,121 +4092,34 @@ in certain situations (rapid incoming events). return -1; } - for (k = 0; k < nfds+1; k++) - { - if (readfds && FD_ISSET(k, readfds)) ++nr; - if (writefds && FD_ISSET(k, writefds)) ++nr; - } - if (NSApp == nil + || ![NSThread isMainThread] || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0)) - return pselect (nfds, readfds, writefds, exceptfds, timeout, sigmask); + return pselect(nfds, readfds, writefds, + exceptfds, timeout, sigmask); + + result = pselect(nfds, readfds, writefds, exceptfds, + &(struct timespec){.tv_sec = 0, .tv_nsec = 100}, + sigmask); [outerpool release]; outerpool = [[NSAutoreleasePool alloc] init]; - - send_appdefined = YES; - if (nr > 0) - { - pthread_mutex_lock (&select_mutex); - select_nfds = nfds; - select_valid = 0; - if (readfds) - { - select_readfds = *readfds; - select_valid += SELECT_HAVE_READ; - } - if (writefds) - { - select_writefds = *writefds; - select_valid += SELECT_HAVE_WRITE; - } - - if (timeout) - { - select_timeout = *timeout; - select_valid += SELECT_HAVE_TMO; - } - - pthread_mutex_unlock (&select_mutex); - - /* Inform fd_handler that select should be called */ - c = 'g'; - emacs_write_sig (selfds[1], &c, 1); - } - else if (nr == 0 && timeout) + if (timeout) { - /* No file descriptor, just a timeout, no need to wake fd_handler */ double time = timespectod (*timeout); - timed_entry = [[NSTimer scheduledTimerWithTimeInterval: time - target: NSApp - selector: - @selector (timeout_handler:) - userInfo: 0 - repeats: NO] - retain]; - } - else /* No timeout and no file descriptors, can this happen? */ - { - /* Send appdefined so we exit from the loop */ - ns_send_appdefined (-1); - } - - block_input (); - ns_init_events (&event); - if (++apploopnr != 1) - { - emacs_abort (); - } - - { - ptrdiff_t specpdl_count = SPECPDL_INDEX (); - record_unwind_protect (unwind_apploopnr, Qt); - [NSApp run]; - unbind_to (specpdl_count, Qnil); /* calls unwind_apploopnr */ - } - - ns_finish_events (); - if (nr > 0 && readfds) - { - c = 's'; - emacs_write_sig (selfds[1], &c, 1); + timeout_date = [NSDate dateWithTimeIntervalSinceNow:time]; } - unblock_input (); - t = last_appdefined_event_data; + /* Listen for a new NSEvent. */ + ns_event = [NSApp nextEventMatchingMask:NSEventMaskAny + untilDate:timeout_date + inMode:NSDefaultRunLoopMode + dequeue:NO]; - if (t != NO_APPDEFINED_DATA) + if (ns_event != nil) { - last_appdefined_event_data = NO_APPDEFINED_DATA; - - if (t == -2) - { - /* The NX_APPDEFINED event we received was a timeout. */ - result = 0; - } - else if (t == -1) - { - /* The NX_APPDEFINED event we received was the result of - at least one real input event arriving. */ - errno = EINTR; - result = -1; - } - else - { - /* Received back from select () in fd_handler; copy the results */ - pthread_mutex_lock (&select_mutex); - if (readfds) *readfds = select_readfds; - if (writefds) *writefds = select_writefds; - pthread_mutex_unlock (&select_mutex); - result = t; - } - } - else - { - errno = EINTR; - result = -1; + raise (SIGIO); } return result; @@ -4765,21 +4635,6 @@ static Lisp_Object ns_string_to_lispmod (const char *s) baud_rate = 38400; Fset_input_interrupt_mode (Qnil); - if (selfds[0] == -1) - { - if (emacs_pipe (selfds) != 0) - { - fprintf (stderr, "Failed to create pipe: %s\n", - emacs_strerror (errno)); - emacs_abort (); - } - - fcntl (selfds[0], F_SETFL, O_NONBLOCK|fcntl (selfds[0], F_GETFL)); - FD_ZERO (&select_readfds); - FD_ZERO (&select_writefds); - pthread_mutex_init (&select_mutex, NULL); - } - ns_pending_files = [[NSMutableArray alloc] init]; ns_pending_service_names = [[NSMutableArray alloc] init]; ns_pending_service_args = [[NSMutableArray alloc] init]; @@ -4792,11 +4647,6 @@ Needs to be here because ns_initialize_display_info () uses AppKit classes. return NULL; [NSApp setDelegate: NSApp]; - /* Start the select thread. */ - [NSThread detachNewThreadSelector:@selector (fd_handler:) - toTarget:NSApp - withObject:nil]; - /* debugging: log all notifications */ /* [[NSNotificationCenter defaultCenter] addObserver: NSApp selector: @selector (logNotification:) @@ -5178,10 +5028,6 @@ - (void)sendEvent: (NSEvent *)theEvent last_appdefined_event_data = [theEvent data1]; [self stop: self]; } - else - { - send_appdefined = YES; - } } @@ -5484,95 +5330,6 @@ - (void)sendFromMainThread:(id)unused ns_send_appdefined (nextappdefined); } -- (void)fd_handler:(id)unused -/* -------------------------------------------------------------------------- - Check data waiting on file descriptors and terminate if so - -------------------------------------------------------------------------- */ -{ - int result; - int waiting = 1, nfds; - char c; - - fd_set readfds, writefds, *wfds; - struct timespec timeout, *tmo; - NSAutoreleasePool *pool = nil; - - /* NSTRACE ("fd_handler"); */ - - for (;;) - { - [pool release]; - pool = [[NSAutoreleasePool alloc] init]; - - if (waiting) - { - fd_set fds; - FD_ZERO (&fds); - FD_SET (selfds[0], &fds); - result = select (selfds[0]+1, &fds, NULL, NULL, NULL); - if (result > 0 && read (selfds[0], &c, 1) == 1 && c == 'g') - waiting = 0; - } - else - { - pthread_mutex_lock (&select_mutex); - nfds = select_nfds; - - if (select_valid & SELECT_HAVE_READ) - readfds = select_readfds; - else - FD_ZERO (&readfds); - - if (select_valid & SELECT_HAVE_WRITE) - { - writefds = select_writefds; - wfds = &writefds; - } - else - wfds = NULL; - if (select_valid & SELECT_HAVE_TMO) - { - timeout = select_timeout; - tmo = &timeout; - } - else - tmo = NULL; - - pthread_mutex_unlock (&select_mutex); - - FD_SET (selfds[0], &readfds); - if (selfds[0] >= nfds) nfds = selfds[0]+1; - - result = pselect (nfds, &readfds, wfds, NULL, tmo, NULL); - - if (result == 0) - ns_send_appdefined (-2); - else if (result > 0) - { - if (FD_ISSET (selfds[0], &readfds)) - { - if (read (selfds[0], &c, 1) == 1 && c == 's') - waiting = 1; - } - else - { - pthread_mutex_lock (&select_mutex); - if (select_valid & SELECT_HAVE_READ) - select_readfds = readfds; - if (select_valid & SELECT_HAVE_WRITE) - select_writefds = writefds; - if (select_valid & SELECT_HAVE_TMO) - select_timeout = timeout; - pthread_mutex_unlock (&select_mutex); - - ns_send_appdefined (result); - } - } - waiting = 1; - } - } -} - /* ========================================================================== @@ -6361,7 +6118,7 @@ - (void)mouseMoved: (NSEvent *)e help_echo_object, help_echo_pos); } - if (emacsframe->mouse_moved && send_appdefined) + if (emacsframe->mouse_moved) ns_send_appdefined (-1); } @@ -7058,8 +6815,7 @@ - (void)windowDidExpose: sender SET_FRAME_VISIBLE (emacsframe, 1); SET_FRAME_GARBAGED (emacsframe); - if (send_appdefined) - ns_send_appdefined (-1); + ns_send_appdefined (-1); } -- Here we go. This seems to work. It turns out there are trade‐offs between the GUI and network performance. If I remove NSApp:nextEventMatchingMask from ns_select, eww loads web pages *significantly* faster, but the scrollbars become effectively unusable. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 31 11:26:29 2016 Received: (at 25265) by debbugs.gnu.org; 31 Dec 2016 16:26:29 +0000 Received: from localhost ([127.0.0.1]:33399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNMUG-0007aU-Is for submit@debbugs.gnu.org; Sat, 31 Dec 2016 11:26:29 -0500 Received: from eggs.gnu.org ([208.118.235.92]:47616) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNMUE-0007aG-F2 for 25265@debbugs.gnu.org; Sat, 31 Dec 2016 11:26:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNMU5-0007bm-1j for 25265@debbugs.gnu.org; Sat, 31 Dec 2016 11:26:21 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47740) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNMU4-0007bS-Tn; Sat, 31 Dec 2016 11:26:16 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1262 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cNMU1-0008GP-PY; Sat, 31 Dec 2016 11:26:16 -0500 Date: Sat, 31 Dec 2016 18:25:58 +0200 Message-Id: <83lguwgj55.fsf@gnu.org> From: Eli Zaretskii To: Alan Third In-reply-to: <20161231160930.GA29122@breton.holly.idiocy.org> (message from Alan Third on Sat, 31 Dec 2016 16:09:30 +0000) Subject: Re: [PATCH] Rework NS event handling (bug#25265) References: <83vau0h2u5.fsf@gnu.org> <20161231160930.GA29122@breton.holly.idiocy.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.2 (--------) X-Debbugs-Envelope-To: 25265 Cc: charles@aurox.ch, 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.2 (--------) > Date: Sat, 31 Dec 2016 16:09:30 +0000 > From: Alan Third > Cc: charles@aurox.ch, 25265@debbugs.gnu.org > > Here we go. This seems to work. It turns out there are trade‐offs > between the GUI and network performance. If I remove > NSApp:nextEventMatchingMask from ns_select, eww loads web pages > *significantly* faster, but the scrollbars become effectively > unusable. Wow, thanks a lot! I cannot review the patch, as I don't really understand the details. So I suggest to push this and see if users report bugs. (I presume you have run all the tests, including those in test/src/thread-tests.el and those posted in the few recent discussions related to thread-related problems. If not, I very much recommend that you do that, to see if the new code passes these "entry-level" tests.) From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 31 11:46:11 2016 Received: (at 25265) by debbugs.gnu.org; 31 Dec 2016 16:46:12 +0000 Received: from localhost ([127.0.0.1]:33419 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNMnL-00084i-Mc for submit@debbugs.gnu.org; Sat, 31 Dec 2016 11:46:11 -0500 Received: from mail-wj0-f176.google.com ([209.85.210.176]:35871) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNMnK-00084W-9j for 25265@debbugs.gnu.org; Sat, 31 Dec 2016 11:46:10 -0500 Received: by mail-wj0-f176.google.com with SMTP id c11so192593384wjx.3 for <25265@debbugs.gnu.org>; Sat, 31 Dec 2016 08:46:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=bghEoNItVLviKBwmzNIlYfR2cOuumGMyv8IZneuPV0o=; b=FmTDFE5He2OhQo2ltV2fpNvrhiVNCdDNMle+CwTTQIKJnaw5CSwzo9Ak0gn1whl3Wm FicLwNXp5K54e6amuk1gTdyJz0R+W7gxBC27uNO1DaVL3dZZhEzuicg7oscyWzzhrQcD RshT+FjAa6h6RQJDfh+8JPCjaXYe1hPKX//MJV3faGvfn1tqnt3Kk48hAOLgtDeN3NPB qzWLDh2KhSOKEVebENFmtpZh3ccPyx5Bs0Bo7gCdrpUFOOtxPOqXzKoJSc5Z1kwjylZ9 +A1yWESoRbN66EoqWQwHy9cge6mGIKcqc3ElkuYHaSyeejb3LRMuprMfSsYaNP78FEPx a1Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=bghEoNItVLviKBwmzNIlYfR2cOuumGMyv8IZneuPV0o=; b=pZc/hved7A0uv1CaPTIOwcTOblYCVuSO4gHOQwWQrWXaJkv6GAejFfunQeVfTMXFVi REd7a0hlUgb8Eg+ba+6xs+ReGKPdgHyTfqXkz8fYolkSCtjmf9gA20bYg1jfOjs42HOD FIqId62VwVkM5uoGy4gs+aTmHUOsvEHsfUKGBfIk1FPA/FpUrDXriAS4A7plK7pdX1SY Qj2jKUbHyGsuV+nkKGAYv5+GwOllfqgciZQ89tcAbjdlcJjhNN0PLGcO+4fRy+eQC9tS jR9wxhOhEemB/iYaK2Fi5+ELI1MnAZCAxaX2AeN8bcAmROlRxrX7fAiN4uJ9xf0dtmrX PSTg== X-Gm-Message-State: AIkVDXJcohRHAZMRUwB5HbnRDw8w84jzHf5RX1Z8ohubLF6XRMynoeWnQNFxnKi83+q0kg== X-Received: by 10.195.12.99 with SMTP id ep3mr37024807wjd.222.1483202764426; Sat, 31 Dec 2016 08:46:04 -0800 (PST) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-fcf8-7042-dd5f-6680.holly.idiocy.org. [2001:8b0:3f8:8129:fcf8:7042:dd5f:6680]) by smtp.gmail.com with ESMTPSA id ke6sm79126045wjb.21.2016.12.31.08.46.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Dec 2016 08:46:03 -0800 (PST) Date: Sat, 31 Dec 2016 16:46:02 +0000 From: Alan Third To: Eli Zaretskii Subject: Re: [PATCH] Rework NS event handling (bug#25265) Message-ID: <20161231164602.GA29157@breton.holly.idiocy.org> References: <83vau0h2u5.fsf@gnu.org> <20161231160930.GA29122@breton.holly.idiocy.org> <83lguwgj55.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83lguwgj55.fsf@gnu.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 25265 Cc: charles@aurox.ch, 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.1 (-) On Sat, Dec 31, 2016 at 06:25:58PM +0200, Eli Zaretskii wrote: > > Date: Sat, 31 Dec 2016 16:09:30 +0000 > > From: Alan Third > > Cc: charles@aurox.ch, 25265@debbugs.gnu.org > > > > Here we go. This seems to work. It turns out there are trade‐offs > > between the GUI and network performance. If I remove > > NSApp:nextEventMatchingMask from ns_select, eww loads web pages > > *significantly* faster, but the scrollbars become effectively > > unusable. > > Wow, thanks a lot! > > I cannot review the patch, as I don't really understand the details. > So I suggest to push this and see if users report bugs. I forgot to say before, I think there may be slightly more lag then before when using the scroll bars. I don’t really use them so I don’t know if people will be bothered by it. With NSTrace turned on I can actually crash Emacs by waving the scroll bars about, but I can’t with NSTrace off. Everything else seems fast enough. If I push it I suppose we’ll find out soon enough if it’s acceptable. > (I presume you have run all the tests, including those in > test/src/thread-tests.el and those posted in the few recent > discussions related to thread-related problems. If not, I very much > recommend that you do that, to see if the new code passes these > "entry-level" tests.) I hadn’t, but I have now. Make check reports 3 unexpected results as usual, and the log for thread-tests.el shows 27/27 passed. I tried this from one of the other threads (I’ve not looked through them completely yet): (dotimes (x 10) (make-thread (lambda () (let ((n (random 10))) (with-current-buffer "z" (sleep-for n) (insert (format "Foo:%d\n" n))))))) and it seems to do what it’s supposed to do. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 01 10:04:12 2017 Received: (at 25265) by debbugs.gnu.org; 1 Jan 2017 15:04:12 +0000 Received: from localhost ([127.0.0.1]:38698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNhgC-0005kh-0K for submit@debbugs.gnu.org; Sun, 01 Jan 2017 10:04:12 -0500 Received: from mail-wj0-f169.google.com ([209.85.210.169]:33868) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNhgA-0005kT-NJ for 25265@debbugs.gnu.org; Sun, 01 Jan 2017 10:04:11 -0500 Received: by mail-wj0-f169.google.com with SMTP id sd9so224974198wjb.1 for <25265@debbugs.gnu.org>; Sun, 01 Jan 2017 07:04:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=OrSWavJqyX7WfDxHG08kkP+Biupuo4JnPB+Vaqest8M=; b=XMepzfVuJLVWKsh8afjJF1dDJXMYuG3cIQYOVSe1nt7s1pCv93x0R48SLoHbDpqxkl dZNkJmatYMXWv2K58OcE0+wfBy1hZlIMf8/fBfFhW8apyvou/ZsYXUYG55gp0LDhTtj2 TAAbLKhLwr3DCicQiV+e4BGCKCNeNFTw0mLXGzIUoHbWUSqmJH9kMDSlfWXemCO4u54i NCpzV1lpheA3JbmmudtyAiSQJvlywBN8jJveGPSfJlMHoenw+gzQijexxmoxv5sF7017 ZNqKxcNwPAfYAR+x+RjzC0Jvh7jlGPBR1ogyf1T7LKBqmTkXubDVXZ5jA57K7+pdSLYV +Jhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=OrSWavJqyX7WfDxHG08kkP+Biupuo4JnPB+Vaqest8M=; b=HuCIgjJ5FLnaDVkQUhPqx7Bs+JVqFZk91LlS1iw8PEu8P7/ghyvjb3wJUYpV59bri6 Oi1DmOcsAczKeSqifvcDUqK9mLFG1aB7aqEJ20Bnm8L9iPyXOhdcC17DcGRR48USFQ/3 2FXsn35UvHq3hgttpicfb8Le5EaOmDuc07EXacFPPiObHz5veP5X/Rq7vvkN0flm1WhR riaeu3SQDlDib98j17dQQ+P/5QhVjxohZhU9mdC7ki6KH0JMGv5dABBb4AMhiOThdiqs M9E7ThgNTsMHfGRD8TvHyosta7xxg0m5JWEv1uBPQeFYiV+CnfN1uE17VImYtpV0HNc7 85nw== X-Gm-Message-State: AIkVDXItIqR43JU2TkKsCiTWwxJpcXEc3JLK+vb5N2wcnrczytkctHnXNTfEFBNR/aGXyQ== X-Received: by 10.194.52.42 with SMTP id q10mr45282684wjo.50.1483283044766; Sun, 01 Jan 2017 07:04:04 -0800 (PST) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-e07c-b900-3b81-e87f.holly.idiocy.org. [2001:8b0:3f8:8129:e07c:b900:3b81:e87f]) by smtp.gmail.com with ESMTPSA id l74sm79734414wmg.2.2017.01.01.07.04.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Jan 2017 07:04:04 -0800 (PST) Date: Sun, 1 Jan 2017 15:03:52 +0000 From: Alan Third To: Eli Zaretskii Subject: Re: bug#25265: [PATCH] Rework NS event handling (bug#25265) Message-ID: <20170101150352.GA61550@breton.holly.idiocy.org> References: <83vau0h2u5.fsf@gnu.org> <20161231160930.GA29122@breton.holly.idiocy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20161231160930.GA29122@breton.holly.idiocy.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 25265 Cc: charles@aurox.ch, 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On Sat, Dec 31, 2016 at 04:09:30PM +0000, Alan Third wrote: > * src/nsterm.m (unwind_apploopnr): Remove. > (ns_read_socket): Remove references to apploopnr. Make processing the > NS event loop conditional on being in the main thread. > (ns_select): Remove references to apploopnr. Remove all fd_handler > related stuff. Check if there are events waiting on the NS event > queue rather than running the event loop. Remove unused variables and > code. > (fd_handler): Remove. > (ns_term_init): Remove creation of fd_handler thread. > (hold_event, EmacsApp:sendEvent, EmacsView:mouseMoved, > EmacsView:windowDidExpose): Remove send_appdefined. > (ns_send_appdefined): Always check the event queue for > applicationDefined events rather than relying on send_appdefined var. > * src/nsterm.h: Remove reference to fd_handler method. OK, I’m running into performance bugs with this almost straight away. It all looks OK until I start flyspell-mode. Then it appears that redisplay is only called every two or three keypresses. It looks like Emacs is still going fine, though, as messages to the modeline appear, even if the action isn’t immediately displayed in the buffer. For example, I open up an org file and start flyspell-mode, then I hit the down arrow which should take me to a heading but the cursor doesn’t move. Then I hit TAB, and I get a message in the modeline telling me that the section associated with the heading has been expanded, but the buffer is still displayed with the cursor on the previous line and the section not expanded. Finally I hit the down arrow again and the buffer updates to display the expanded section and the cursor where I’d expect it. emacsclient runs with a delay, which I guess corresponds to the timeout on the NS event queue check. I’m not at all sure how to fix these problems. One option I thought about is to wrap the fd’s in ns_select with NSFileHandle, which should then mean we could look for notifications on the NS event queue, and emulate select that way. Unfortunately as far as I can see NSFileHandle only provides an event for ‘data available for reading’, and it looks like we’d need to be able to spot write availability too. (See under Notifications: https://developer.apple.com/reference/foundation/nsfilehandle) -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 01 10:43:03 2017 Received: (at 25265) by debbugs.gnu.org; 1 Jan 2017 15:43:03 +0000 Received: from localhost ([127.0.0.1]:38710 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNiHn-0006ds-AY for submit@debbugs.gnu.org; Sun, 01 Jan 2017 10:43:03 -0500 Received: from eggs.gnu.org ([208.118.235.92]:41986) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNiHl-0006dO-Tk for 25265@debbugs.gnu.org; Sun, 01 Jan 2017 10:43:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNiHd-0003SP-H9 for 25265@debbugs.gnu.org; Sun, 01 Jan 2017 10:42:56 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58414) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNiHd-0003SL-Dt; Sun, 01 Jan 2017 10:42:53 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2685 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cNiHc-0002lv-Ju; Sun, 01 Jan 2017 10:42:53 -0500 Date: Sun, 01 Jan 2017 17:42:58 +0200 Message-Id: <834m1ihjlp.fsf@gnu.org> From: Eli Zaretskii To: Alan Third In-reply-to: <20170101150352.GA61550@breton.holly.idiocy.org> (message from Alan Third on Sun, 1 Jan 2017 15:03:52 +0000) Subject: Re: bug#25265: [PATCH] Rework NS event handling (bug#25265) References: <83vau0h2u5.fsf@gnu.org> <20161231160930.GA29122@breton.holly.idiocy.org> <20170101150352.GA61550@breton.holly.idiocy.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.2 (--------) X-Debbugs-Envelope-To: 25265 Cc: charles@aurox.ch, 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.2 (--------) > Date: Sun, 1 Jan 2017 15:03:52 +0000 > From: Alan Third > Cc: charles@aurox.ch, 25265@debbugs.gnu.org > > OK, I’m running into performance bugs with this almost straight away. > > It all looks OK until I start flyspell-mode. Then it appears that > redisplay is only called every two or three keypresses. It looks like > Emacs is still going fine, though, as messages to the modeline appear, > even if the action isn’t immediately displayed in the buffer. > > For example, I open up an org file and start flyspell-mode, then I hit > the down arrow which should take me to a heading but the cursor > doesn’t move. Then I hit TAB, and I get a message in the modeline > telling me that the section associated with the heading has been > expanded, but the buffer is still displayed with the cursor on the > previous line and the section not expanded. Finally I hit the down > arrow again and the buffer updates to display the expanded section and > the cursor where I’d expect it. > > emacsclient runs with a delay, which I guess corresponds to the > timeout on the NS event queue check. > > I’m not at all sure how to fix these problems. Do you understand the problems, though? The crucial question is why isn't redisplay being called as it was called before the changes? One way of answering that would be to run the previous version under a debugger, put a breakpoint in redisplay_internal, show a backtrace to see who called it, and continue. Then do the same in the new version, and see if you can spot any differences. Do you really need to type several keys to get redisplay? Or is it enough to type just one and wait for some time? IOW, if you type one key, then wait, does redisplay ever happen? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 06 15:03:06 2017 Received: (at 25265) by debbugs.gnu.org; 6 Mar 2017 20:03:06 +0000 Received: from localhost ([127.0.0.1]:43222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ckyqY-0001iv-L1 for submit@debbugs.gnu.org; Mon, 06 Mar 2017 15:03:06 -0500 Received: from mail-wr0-f196.google.com ([209.85.128.196]:35280) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ckyqV-0001iO-9U for 25265@debbugs.gnu.org; Mon, 06 Mar 2017 15:03:04 -0500 Received: by mail-wr0-f196.google.com with SMTP id u108so19140914wrb.2 for <25265@debbugs.gnu.org>; Mon, 06 Mar 2017 12:03:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=6SIQEnYbaq3akybXhdDvFtL6y7RJmqXpbSD0r5BrGZ4=; b=Ix8Ou+J7ZTUppr2xlcGPN1fYxXAaBfzKn0sMKuZxEAi0laMTu3+rhjIYEq8UVi3w8a xMuNz6sddHPAPUaqVpX4cEeJagQTWGRgUF8Cjj0TqvaMHKWYtv9HUmGHLWpdqPlxGCx2 MH6geJ2Ue6D7t/cSVwio8iB/ffXcCFpj4TJ+pY0GHti45w1uDZNs3WnW8H3DzpMhrTg4 CYut91odzOQOpsk54czA1lQIeoCkIe01SpgOomdnTiCu2SLc8PPHWP9f11slcKZUvBEV 50TPh8CVyyy541pqrmsqeRnUXDDWXJ4kNaLZBBLMLwsYutOZO2T+e5/k1N6Tf8rapcx6 Obag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=6SIQEnYbaq3akybXhdDvFtL6y7RJmqXpbSD0r5BrGZ4=; b=nBLr7DRM9IvotZBdEX4p+w88zyOzGwOXiIHu6EFlIsofVN9aBHWtN8aa+35yAcPBKh BakzjQsL5/fIgjH1Z7SzGRehvls6PBNpIzJakilUOP8luORPYuIVPi4gBgjfkcb6OjoP KcMTpWhXjZh9HLlJcn8OFAlBiNjI4sRcd77uYcxUDBTFWeGVG9W53APMVKI430A0nK40 6680gv/9a7k/jdJWJ7Um6mFf/GFlCiQoOR3sJ+Mqp9G6nh7T6Ptl8XdasRnqz0BSCANE 5JJnJIomd/VkYLHyN6JOpWMPR0Oz/hz93kJxodaCvqtSoZJ3tpqn56ilidvhojIzGTpr EU3A== X-Gm-Message-State: AMke39n22svNFpFbl+EGJ6oADdREkEB/uDnVuyWkOLHs0sLnvRvbARsHznDA6QhxcOL+Ew== X-Received: by 10.223.138.250 with SMTP id z55mr17386874wrz.130.1488830577239; Mon, 06 Mar 2017 12:02:57 -0800 (PST) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-5c3f-6a2c-9f51-ca7e.holly.idiocy.org. [2001:8b0:3f8:8129:5c3f:6a2c:9f51:ca7e]) by smtp.gmail.com with ESMTPSA id j26sm4706430wrb.69.2017.03.06.12.02.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 06 Mar 2017 12:02:56 -0800 (PST) From: Alan Third To: charles@aurox.ch (Charles A. Roelli) Subject: Re: bug#25265: make-thread crashes in OS X 10.6 References: Date: Mon, 06 Mar 2017 20:02:16 +0000 In-Reply-To: (Charles A. Roelli's message of "Sat, 24 Dec 2016 12:06:45 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 25265 Cc: 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) charles@aurox.ch (Charles A. Roelli) writes: > Running Emacs -Q on the latest commit (e36a3882), > > M-: (make-thread (lambda () "string")) > > appears to hang Emacs immediately. I've just pushed a new fix for this to master. If anyone is able to test it and let me know if they run into any problems, I would be grateful. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 08 15:17:59 2017 Received: (at 25265) by debbugs.gnu.org; 8 Mar 2017 20:17:59 +0000 Received: from localhost ([127.0.0.1]:46703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cli23-000551-Hz for submit@debbugs.gnu.org; Wed, 08 Mar 2017 15:17:59 -0500 Received: from sinyavsky.aurox.ch ([37.35.109.145]:60171) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cli22-00054n-CC for 25265@debbugs.gnu.org; Wed, 08 Mar 2017 15:17:58 -0500 Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) by sinyavsky.aurox.ch (Postfix) with ESMTP id 6110422397 for <25265@debbugs.gnu.org>; Wed, 8 Mar 2017 20:14:36 +0000 (UTC) Authentication-Results: sinyavsky.aurox.ch (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=aurox.ch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aurox.ch; h= content-type:content-type:mime-version:message-id:in-reply-to :date:date:references:subject:subject:to:from:from; s=dkim; t= 1489004074; x=1489868075; bh=buBAGZ6XsLStTVs95xGs2n0nFYJmb0jRP7r rzXAYwTc=; b=uCb6EXwTXi792wAtRegwUoM+JOmqpJZQ+3+wku0KQfQ5rTq75js 1LxbEet93Wv65GM3x9yTLpzfE+2LG46hTVKOeobn+jvn3O3P/+ZHnDxJtjzGTFZO 9PVRaka5XiVhRnp/T9PS0OQhksP73xP+taQIJcvfwH8wwOfyWWR5W16s= X-Virus-Scanned: Debian amavisd-new at test.virtualizor.com Received: from sinyavsky.aurox.ch ([127.0.0.1]) by sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EXLL5UlP3-MZ for <25265@debbugs.gnu.org>; Wed, 8 Mar 2017 20:14:34 +0000 (UTC) Received: from gray (54.4.4.85.dynamic.wline.res.cust.swisscom.ch [85.4.4.54]) by sinyavsky.aurox.ch (Postfix) with ESMTPSA id DAEBB2238B; Wed, 8 Mar 2017 20:14:33 +0000 (UTC) From: charles@aurox.ch (Charles A. Roelli) To: Alan Third Subject: Re: bug#25265: make-thread crashes in OS X 10.6 References: Date: Wed, 08 Mar 2017 21:17:48 +0100 In-Reply-To: (Alan Third's message of "Mon, 06 Mar 2017 20:02:16 +0000") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 25265 Cc: 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Mon, Mar 06 2017 at 08:02:16 pm, Alan Third wrote: > charles@aurox.ch (Charles A. Roelli) writes: > >> Running Emacs -Q on the latest commit (e36a3882), >> >> M-: (make-thread (lambda () "string")) >> >> appears to hang Emacs immediately. > > I've just pushed a new fix for this to master. If anyone is able to test > it and let me know if they run into any problems, I would be grateful. Fixes the bug for me! Thank you for working on this. I didn't notice any adverse changes in Emacs behavior with your patch, but I haven't yet been running it for too long. Will report back soon again. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 14 10:50:08 2017 Received: (at 25265) by debbugs.gnu.org; 14 Mar 2017 14:50:08 +0000 Received: from localhost ([127.0.0.1]:55787 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cnnm4-0001xL-9t for submit@debbugs.gnu.org; Tue, 14 Mar 2017 10:50:08 -0400 Received: from mail-wr0-f176.google.com ([209.85.128.176]:32795) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cnnm2-0001wk-FR for 25265@debbugs.gnu.org; Tue, 14 Mar 2017 10:50:07 -0400 Received: by mail-wr0-f176.google.com with SMTP id u48so125820056wrc.0 for <25265@debbugs.gnu.org>; Tue, 14 Mar 2017 07:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=bKu5J1ZpBaht2pf9/sCrgv16S8bhWXYREeaD566LWRE=; b=Hw8ZSYUSmxK4IFiZideiV6RrMADIAupw1c165yIIrQnL3bssNEFAKjPtfBcu0ABzQA SpxDiVNnBYjiHgNbFZWzPlKUUv5hTIYCgcKne0KCquUHHqJ+tWU7JM/v3rNB3LSP64z9 x4M/a2dTgZRGUPiI2z54Lel2CLFctJWbQ/JRXzLNGDwLC752A6LAPHuDZpyPbvDloBpW PNjfW52pThjH19G0yu6HfSfBFwD3Wgb/fOGU7kAmOml2ZOgU0e2AZ5T/nzUqc3KLsuKl ZAtVrKP+f46dvLzdAWNOQ45t4+mWxGZkE+cIEX0LBZDaYjjUlexUV2N/jAAsTbyERoJW mtxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=bKu5J1ZpBaht2pf9/sCrgv16S8bhWXYREeaD566LWRE=; b=DLfgtVMFVGbrDRMRkcUSH/wuGrhEBeKuRxr3Rf2SI2Nb9WcuokRT51HuPuopDy+X2u hEzLx9Gig7Q2rNtn5r5kLdCwW1ArGGY6dMLD4iB0j9iC5mmEPLVtX5+IpIt7RMs0rjzI VryRRiPC5ALu7iUOJua4vmJ7nLeb35cGXfWS4c+4gS19k49VfEet4rX4vVDDZ9Uxww+3 J/fxntEWqd/pnD5jaYDxiMDV+JdZsMAXVOA460E7qGpgzNGa4Ka2XfUOYqzJ52CIuKVv A5VYcCTsvAqYlzK465TlcBmbT31A26DP0VyvQSb7nJ3RskqKW93AxgxPhoFERRnLNi3e Jufw== X-Gm-Message-State: AMke39kP+Nbme7U1Ws7WbxsK4KzNdbfSAnavEvRLo8pBVJTxeDebNLNSiVZuG1XS/92WBQ== X-Received: by 10.223.153.168 with SMTP id y37mr32221634wrb.193.1489503000662; Tue, 14 Mar 2017 07:50:00 -0700 (PDT) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-4991-ec36-6c8c-8fcf.holly.idiocy.org. [2001:8b0:3f8:8129:4991:ec36:6c8c:8fcf]) by smtp.gmail.com with ESMTPSA id l21sm29408599wrl.59.2017.03.14.07.49.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 07:49:59 -0700 (PDT) Date: Tue, 14 Mar 2017 14:49:58 +0000 From: Alan Third To: "Charles A. Roelli" Subject: Re: bug#25265: make-thread crashes in OS X 10.6 Message-ID: <20170314144958.GA50408@breton.holly.idiocy.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 25265 Cc: 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) On Wed, Mar 08, 2017 at 09:17:48PM +0100, Charles A. Roelli wrote: > On Mon, Mar 06 2017 at 08:02:16 pm, Alan Third wrote: > > > charles@aurox.ch (Charles A. Roelli) writes: > > > >> Running Emacs -Q on the latest commit (e36a3882), > >> > >> M-: (make-thread (lambda () "string")) > >> > >> appears to hang Emacs immediately. > > > > I've just pushed a new fix for this to master. If anyone is able to test > > it and let me know if they run into any problems, I would be grateful. > > Fixes the bug for me! Thank you for working on this. I didn't notice > any adverse changes in Emacs behavior with your patch, but I haven't yet > been running it for too long. Will report back soon again. I’ve reverted the changes as it was causing Emacs to hang under certain circumstances. I’m all out of ideas for how to sort this concurrency thing. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Tue May 02 16:49:46 2017 Received: (at 25265) by debbugs.gnu.org; 2 May 2017 20:49:46 +0000 Received: from localhost ([127.0.0.1]:51586 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d5ejy-0002OL-5s for submit@debbugs.gnu.org; Tue, 02 May 2017 16:49:46 -0400 Received: from mail-wm0-f49.google.com ([74.125.82.49]:34501) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d5eju-0002O6-RE for 25265@debbugs.gnu.org; Tue, 02 May 2017 16:49:43 -0400 Received: by mail-wm0-f49.google.com with SMTP id r190so31025531wme.1 for <25265@debbugs.gnu.org>; Tue, 02 May 2017 13:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=3XmEjZTV7W/ic+vuZzIkwU2X2lL+DwbPYgIEUV61lqE=; b=ReBZYvkueBwlE3VBQzuWIKt42vK2QrNa0BXM0ZiWyQb4Jk0GYsLsClK1ophXHHjsGi T3SJlPswANHCyRI/WOoaNtzSdX11pQlj+t8yCASW2aeMN2k/0o882Gw7n21AaTywVfB0 lPY5IIO6gyI13bVk54S/hkCt8eAseZz4g7/5x5Lfnv9wBtno/V+H1MbszKBVPwHGjJq5 jIlVT49B59ugKcKS1ozIOEoz5+huKnkZz3Rrm20dcjrv6hHY3hbBXjPZyoIRUcZRa4pG W79Ky0Rf4hcdEkltgXltOoAGMO+Zx7YtjaqkzvevIikHWFBotvTFe6UE6K9jMtQPNDBq 1T1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=3XmEjZTV7W/ic+vuZzIkwU2X2lL+DwbPYgIEUV61lqE=; b=P+l+wcF4FcXrceE8S+1tQQKvZj34EIszCocXlRA32a4m8igINYM52jmdEHv8Eo8zUO 6ExELeGahCRknATQftYhnjKtVEo/tc1ad47aVdPJJN1wjxdj2Y67RkpsGYG02WR7P1y0 o4budZjfQkeSEWIn48O9lODq49x1DTPoR9xjNmQcFy9+TkFcQ6s7fK2cqijBMTP/kkt1 hyn0Dkrqpr9JQkVbcnUBRPDqOdYvPqeikiOURDYgWSs7ifPfH8EZ4GLlcxmWQ+lIWG4I oxRbUf6uhi+tMjhTtdeVLNS4susa/JzxdCMNVwFsvbf/G9eGPpXYQTTjkT/IlUkTFmiZ C8ww== X-Gm-Message-State: AN3rC/5xGIb2kCdG3uzjD6we53YBYoGQkLqAXcOMMFh15sobCp0CgaiV z6Uz42r9JFFm3g== X-Received: by 10.28.216.85 with SMTP id p82mr3193946wmg.91.1493758177030; Tue, 02 May 2017 13:49:37 -0700 (PDT) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-50f6-0664-c41f-3461.holly.idiocy.org. [2001:8b0:3f8:8129:50f6:664:c41f:3461]) by smtp.gmail.com with ESMTPSA id 39sm19724416wru.50.2017.05.02.13.49.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 13:49:35 -0700 (PDT) Date: Tue, 2 May 2017 21:49:35 +0100 From: Alan Third To: "Charles A. Roelli" Subject: Re: bug#25265: make-thread crashes in OS X 10.6 Message-ID: <20170502204935.GA79100@breton.holly.idiocy.org> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 25265 Cc: 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) --17pEHd4RhPHOinZp Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Sat, Dec 24, 2016 at 12:06:45PM +0100, Charles A. Roelli wrote: > Running Emacs -Q on the latest commit (e36a3882), > > M-: (make-thread (lambda () "string")) > > appears to hang Emacs immediately. I’ve been working on this on and off for a while now, and I just can’t fix it. I’ve attached two patches that together are the best I’ve managed to achieve, but unfortunately it randomly freezes up with 100% CPU usage. I’ve not yet managed to work out what it’s doing when it goes into the 100% CPU loop. I can only assume I’ve missed some crucial case in ns_select or something. The first patch stops the NS port from using SIGIO, as it seems to be the source of a number of problems. The second removes the NS event loop in ns_select as it requires block_input/unblock_input wrapped around it, but that’s what’s causing the crash in make-thread. Instead it just looks for whether there is a new NS event as I don’t think that requires blocking input. -- Alan Third --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Description: Remove SIGIO stuff Content-Disposition: attachment; filename="0001-Don-t-use-SIGIO-in-NS.patch" >From bff3dbfe43a24ee924edd777a7a876b627f94f11 Mon Sep 17 00:00:00 2001 From: Alan Third Date: Sat, 29 Apr 2017 23:35:16 +0100 Subject: [PATCH] Don't use SIGIO in NS * src/keyboard.c (handle_user_signal) [HAVE_NS]: Don't handle SIGIO. * src/keyboard.h (handle_input_available_signal) [HAVE_NS]: Make available to external code. * src/nsterm.m (hold_event, ns_Select): Call handle_input_available_signal directly. * src/sysdep.c (emacs_sigaction_init) [HAVE_NS]: Ignore SIGIO. --- src/keyboard.c | 3 ++- src/keyboard.h | 11 +++++++++++ src/nsterm.m | 4 ++-- src/sysdep.c | 2 +- 4 files changed, 16 insertions(+), 4 deletions(-) diff --git a/src/keyboard.c b/src/keyboard.c index c9fa2a9f5e..d22f7b08c6 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -7264,7 +7264,8 @@ handle_user_signal (int sig) } p->npending++; -#ifdef USABLE_SIGIO +#if defined (USABLE_SIGIO) && !defined (HAVE_NS) + /* Dont use the interrupt handler in NS. */ if (interrupt_input) handle_input_available_signal (sig); else diff --git a/src/keyboard.h b/src/keyboard.h index 2219c01135..29279bef86 100644 --- a/src/keyboard.h +++ b/src/keyboard.h @@ -495,6 +495,17 @@ extern void mark_kboards (void); extern const char *const lispy_function_keys[]; #endif +#ifdef HAVE_NS +/* The NS port only uses SIGIO internally, and even then only in two + places in the code, but it causes crashes if certain code is not + properly wrapped in block_input/unblock_input. + + Since it's only used internally, we should be able to disable it, + and call the SIGIO handler directly. + */ +extern void handle_input_available_signal (int sig); +#endif + extern char const DEV_TTY[]; INLINE_HEADER_END diff --git a/src/nsterm.m b/src/nsterm.m index c22c5a70ba..00b7a89472 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -472,7 +472,7 @@ - (NSColor *)colorUsingDefaultColorSpace hold_event_q.q[hold_event_q.nr++] = *event; /* Make sure ns_read_socket is called, i.e. we have input. */ - raise (SIGIO); + handle_input_available_signal (SIGIO); send_appdefined = YES; } @@ -4289,7 +4289,7 @@ in certain situations (rapid incoming events). if (hold_event_q.nr > 0) { /* We already have events pending. */ - raise (SIGIO); + handle_input_available_signal (SIGIO); errno = EINTR; return -1; } diff --git a/src/sysdep.c b/src/sysdep.c index 91b2a5cb94..70fdf92964 100644 --- a/src/sysdep.c +++ b/src/sysdep.c @@ -1606,7 +1606,7 @@ emacs_sigaction_init (struct sigaction *action, signal_handler_t handler) { sigaddset (&action->sa_mask, SIGINT); sigaddset (&action->sa_mask, SIGQUIT); -#ifdef USABLE_SIGIO +#if defined (USABLE_SIGIO) && !defined (HAVE_NS) sigaddset (&action->sa_mask, SIGIO); #endif } -- 2.12.0 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Description: Remove NS event loop from ns_select Content-Disposition: attachment; filename="0001-Remove-event-loop-from-ns_select.patch" >From f759adb30eaf12af474057ebbc98f5f76cc590bf Mon Sep 17 00:00:00 2001 From: Alan Third Date: Sun, 30 Apr 2017 10:04:16 +0100 Subject: [PATCH] Remove event loop from ns_select * src/nsterm.m (ns_select): Remove event processing loop and replace with simple test for a new event. (ns_send_appdefined): Remove redundant timer code. --- src/nsterm.m | 92 ++++++++++++++++++++++++++++-------------------------------- 1 file changed, 43 insertions(+), 49 deletions(-) diff --git a/src/nsterm.m b/src/nsterm.m index 00b7a89472..462ab176c9 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -282,7 +282,6 @@ - (NSColor *)colorUsingDefaultColorSpace static BOOL send_appdefined = YES; #define NO_APPDEFINED_DATA (-8) static int last_appdefined_event_data = NO_APPDEFINED_DATA; -static NSTimer *timed_entry = 0; static NSTimer *scroll_repeat_entry = nil; static fd_set select_readfds, select_writefds; enum { SELECT_HAVE_READ = 1, SELECT_HAVE_WRITE = 2, SELECT_HAVE_TMO = 4 }; @@ -4074,14 +4073,6 @@ in certain situations (rapid incoming events). /* We only need one NX_APPDEFINED event to stop NXApp from running. */ send_appdefined = NO; - /* Don't need wakeup timer any more */ - if (timed_entry) - { - [timed_entry invalidate]; - [timed_entry release]; - timed_entry = nil; - } - nxev = [NSEvent otherEventWithType: NSEventTypeApplicationDefined location: NSMakePoint (0, 0) modifierFlags: 0 @@ -4277,9 +4268,11 @@ in certain situations (rapid incoming events). { int result; int t, k, nr = 0; - struct input_event event; char c; + NSDate *timeout_date = nil; + NSEvent *ns_event; + NSTRACE_WHEN (NSTRACE_GROUP_EVENTS, "ns_select"); #ifdef HAVE_NATIVE_FS @@ -4337,70 +4330,71 @@ in certain situations (rapid incoming events). /* Inform fd_handler that select should be called */ c = 'g'; emacs_write_sig (selfds[1], &c, 1); + /* We rely on fd_handler timing out to cause + nextEventMatchingMask below to return, so set it's timeout to + an unreasonably long time. */ + timeout_date = [NSDate distantFuture]; } else if (nr == 0 && timeout) { - /* No file descriptor, just a timeout, no need to wake fd_handler */ + /* No file descriptor, just a timeout, no need to wake + fd_handler. Set nextEventMatchingMask timeout. */ double time = timespectod (*timeout); - timed_entry = [[NSTimer scheduledTimerWithTimeInterval: time - target: NSApp - selector: - @selector (timeout_handler:) - userInfo: 0 - repeats: NO] - retain]; - } - else /* No timeout and no file descriptors, can this happen? */ - { - /* Send appdefined so we exit from the loop */ - ns_send_appdefined (-1); + timeout_date = [NSDate dateWithTimeIntervalSinceNow: time]; } - block_input (); - ns_init_events (&event); - - [NSApp run]; + /* Listen for a new NSEvent. */ + ns_event = [NSApp nextEventMatchingMask: NSEventMaskAny + untilDate: timeout_date + inMode: NSDefaultRunLoopMode + dequeue: NO]; - ns_finish_events (); if (nr > 0 && readfds) { c = 's'; emacs_write_sig (selfds[1], &c, 1); } - unblock_input (); - - t = last_appdefined_event_data; - if (t != NO_APPDEFINED_DATA) + if (ns_event != nil) { - last_appdefined_event_data = NO_APPDEFINED_DATA; - - if (t == -2) + if ([ns_event type] == NSEventTypeApplicationDefined) { - /* The NX_APPDEFINED event we received was a timeout. */ - result = 0; + if ([ns_event data1] < 0) + { + /* The NX_APPDEFINED event we received was a timeout. */ + result = 0; + } + else + { + /* Received back from select () in fd_handler; copy the results */ + pthread_mutex_lock (&select_mutex); + if (readfds) *readfds = select_readfds; + if (writefds) *writefds = select_writefds; + pthread_mutex_unlock (&select_mutex); + result = [ns_event data1]; + } + + /* Remove the NX_APPDEFINED event from the queue as it's no + longer needed. */ + [NSApp nextEventMatchingMask: NSEventMaskAny + untilDate: nil + inMode: NSDefaultRunLoopMode + dequeue: YES]; } - else if (t == -1) + else { - /* The NX_APPDEFINED event we received was the result of - at least one real input event arriving. */ + /* A real NSEvent came in. */ + handle_input_available_signal (0); errno = EINTR; result = -1; } - else - { - /* Received back from select () in fd_handler; copy the results */ - pthread_mutex_lock (&select_mutex); - if (readfds) *readfds = select_readfds; - if (writefds) *writefds = select_writefds; - pthread_mutex_unlock (&select_mutex); - result = t; - } } else { errno = EINTR; result = -1; + /* Reading from the NSEvent queue timed out. */ + result = 0; } return result; -- 2.12.0 --17pEHd4RhPHOinZp-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 12 15:32:35 2017 Received: (at 25265) by debbugs.gnu.org; 12 Jun 2017 19:32:35 +0000 Received: from localhost ([127.0.0.1]:44003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dKV4l-0007cX-Hi for submit@debbugs.gnu.org; Mon, 12 Jun 2017 15:32:35 -0400 Received: from sinyavsky.aurox.ch ([37.35.109.145]:39488) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dKV4j-0007cJ-BE for 25265@debbugs.gnu.org; Mon, 12 Jun 2017 15:32:33 -0400 Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) by sinyavsky.aurox.ch (Postfix) with ESMTP id 6EF082246F for <25265@debbugs.gnu.org>; Mon, 12 Jun 2017 19:27:40 +0000 (UTC) Authentication-Results: sinyavsky.aurox.ch (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=aurox.ch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aurox.ch; h= content-transfer-encoding:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:to:subject:subject; s=dkim; t=1497295658; x= 1498159659; bh=aUYnbbxAPvynn9xv3aCI4aWd/Er7MNtlO7ZoTIMTY/8=; b=f DA2ENPz94P/2vyGrUf15Z7JxhGwDBU2TIF6XWgSdZ5d3+EC2rZCyEefhkHh6dyCM FXAvrFSSNtnWPqQtwxbR723uyktwrEpXrK4QcmdCh4p69wnRpq9NQQ6zLOWnaqtO y8evL46j28S/F9ciYUFcNrZsk8wvRasQTcycklsU6w= X-Virus-Scanned: Debian amavisd-new at test.virtualizor.com Received: from sinyavsky.aurox.ch ([127.0.0.1]) by sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ms4pSip2lexs for <25265@debbugs.gnu.org>; Mon, 12 Jun 2017 19:27:38 +0000 (UTC) Received: from [192.168.1.121] (125.85.192.178.dynamic.wline.res.cust.swisscom.ch [178.192.85.125]) by sinyavsky.aurox.ch (Postfix) with ESMTPSA id 7459522469; Mon, 12 Jun 2017 19:27:38 +0000 (UTC) Subject: Re: bug#25265: make-thread crashes in OS X 10.6 To: Alan Third References: <20170502204935.GA79100@breton.holly.idiocy.org> From: "Charles A. Roelli" Message-ID: Date: Mon, 12 Jun 2017 21:32:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170502204935.GA79100@breton.holly.idiocy.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 25265 Cc: 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) The issue seems to be improved now (not sure what changed it). I tried this sample code, and it worked without a crash: (dotimes (i 100) (make-thread (lambda () "string"))) Then I tried this code, and there's a crash every few runs (or sometimes, an infinite loop that can't be exited without killing the process). The crash normally happens when I supply input (via the keyboard), and the loop seems to be happen randomly. (make-thread (lambda () (dotimes (i 10) (sit-for 1) (goto-char (random (buffer-size)))))) I also noticed GDB's I/O buffer printing many of these warnings as soon as the `make-thread' form was called: 2017-06-12 21:13:55.943 Emacs[10829:6683] *** __NSAutoreleaseNoPool(): Object 0x10216bf50 of class NSBezierPath autoreleased with no pool in place - just leaking 2017-06-12 21:13:55.944 Emacs[10829:6683] *** __NSAutoreleaseNoPool(): Object 0x101ec41b0 of class NSBezierPath autoreleased with no pool in place - just leaking 2017-06-12 21:13:56.443 Emacs[10829:6683] *** __NSAutoreleaseNoPool(): Object 0x10216c0f0 of class NSBezierPath autoreleased with no pool in place - just leaking 2017-06-12 21:13:56.444 Emacs[10829:6683] *** __NSAutoreleaseNoPool(): Object 0x101ec43e0 of class NSBezierPath autoreleased with no pool in place - just leaking On 02/05/2017 22:49, Alan Third wrote: > On Sat, Dec 24, 2016 at 12:06:45PM +0100, Charles A. Roelli wrote: >> Running Emacs -Q on the latest commit (e36a3882), >> >> M-: (make-thread (lambda () "string")) >> >> appears to hang Emacs immediately. > Ive been working on this on and off for a while now, and I just cant > fix it. > > Ive attached two patches that together are the best Ive managed to > achieve, but unfortunately it randomly freezes up with 100% CPU usage. > > Ive not yet managed to work out what its doing when it goes into the > 100% CPU loop. I can only assume Ive missed some crucial case in > ns_select or something. > > The first patch stops the NS port from using SIGIO, as it seems to be > the source of a number of problems. The second removes the NS event > loop in ns_select as it requires block_input/unblock_input wrapped > around it, but thats whats causing the crash in make-thread. > > Instead it just looks for whether there is a new NS event as I dont > think that requires blocking input. > From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 13 16:46:54 2017 Received: (at 25265) by debbugs.gnu.org; 13 Jun 2017 20:46:54 +0000 Received: from localhost ([127.0.0.1]:46284 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dKsiE-0008V1-Ag for submit@debbugs.gnu.org; Tue, 13 Jun 2017 16:46:54 -0400 Received: from mail-wr0-f182.google.com ([209.85.128.182]:33635) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dKsiB-0008Un-Lp for 25265@debbugs.gnu.org; Tue, 13 Jun 2017 16:46:52 -0400 Received: by mail-wr0-f182.google.com with SMTP id v104so151177533wrb.0 for <25265@debbugs.gnu.org>; Tue, 13 Jun 2017 13:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=BFUGHeNOjJZKIsOvmSd9ynUdeymBENS/wMB/ZRIdquA=; b=C4uvwzdJe5o3xoSRZiX+NgUbTwMfHnl0ZzOa/gfbskki0bqicgPEgEdf3poDISYWHN /fGGTqiy9Y6r5xEqPVPIoXsR+y6aC9BRWbo0lsXiiyeprpMy4yoZDTF/e+9uzV22Funl XNdkz9HBnk8wl0GXAa8PmdG4dFGPVlqLcYnNsX4tBzNMMLoytl74hrWkQOpdCshY7ntY L7axJ+xG3pddgI4qXVRJxG3WEInEQeXL6RxnDvjrAN1sRwRhq1L0HFh3rRsvab5tdD2y M951fvWT3YWNIFGYSrUqCrl+UB1KTdBOKcs8oMxGhLX8lS0VADnheDtEnv7vAfGw1jjg krIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=BFUGHeNOjJZKIsOvmSd9ynUdeymBENS/wMB/ZRIdquA=; b=W95gNE7maNhNOL3l4lzygvnh0uA2Wo5e4kThuxgqlG78+o9qF0os9UJP+ZGRW790Kv LwQ2Vxx6PEZVNDjvKsOXDUN/nENyuSz+Jqr9uP9udpYbL9SGnIyg3FlCOEjfd3mY0cl0 Po6/vlZibv1G/9Dmbw9m0W9uwiOjusLXLiK7zuzG+ianDNU+zxp/UN/nzV7tgY9uR48D /tJQZEgapU6FIXBRHXe3qEmKzz4lxbtm97SuI/Yaim0KxsIj0GNWoKPgj+VlBn0ZCTft gJIAJVTN6qvA1+mf8QF9lAS2vHA+p+0JWugAgD0eCqyJVCZjVQYFAla5qh04+LmItgf/ Q4ug== X-Gm-Message-State: AKS2vOxwThB+wSghWZziwnAA+o424sFgSniHxkDEPqcwMA8SHmrHvvl1 smNltsqF3EnSiGKkrEU= X-Received: by 10.28.230.153 with SMTP id e25mr11598548wmi.41.1497386805666; Tue, 13 Jun 2017 13:46:45 -0700 (PDT) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-58c7-5550-e6e7-d91f.holly.idiocy.org. [2001:8b0:3f8:8129:58c7:5550:e6e7:d91f]) by smtp.gmail.com with ESMTPSA id g3sm26931694wrd.11.2017.06.13.13.46.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jun 2017 13:46:44 -0700 (PDT) Date: Tue, 13 Jun 2017 21:46:43 +0100 From: Alan Third To: "Charles A. Roelli" Subject: Re: bug#25265: make-thread crashes in OS X 10.6 Message-ID: <20170613204643.GA98084@breton.holly.idiocy.org> References: <20170502204935.GA79100@breton.holly.idiocy.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 25265 Cc: 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Mon, Jun 12, 2017 at 09:32:21PM +0200, Charles A. Roelli wrote: > The issue seems to be improved now (not sure what changed it). > > I tried this sample code, and it worked without a crash: > > (dotimes (i 100) > (make-thread (lambda () "string"))) > > Then I tried this code, and there's a crash every few runs (or > sometimes, an infinite loop that can't be exited without killing the > process). The crash normally happens when I supply input (via the > keyboard), and the loop seems to be happen randomly. > > (make-thread (lambda () > (dotimes (i 10) > (sit-for 1) > (goto-char (random (buffer-size)))))) I went back and noticed an approach Eli suggested that I had given up on, but understood this time round. I’ve attached a patch that seems to not crash. It introduces a warning or two, and test/src/thread-tests.el randomly fails up to two tests, but no crashes afaics. > I also noticed GDB's I/O buffer printing many of these warnings as > soon as the `make-thread' form was called: > > 2017-06-12 21:13:55.943 Emacs[10829:6683] *** __NSAutoreleaseNoPool(): > Object 0x10216bf50 of class NSBezierPath autoreleased with no pool in place > - just leaking > 2017-06-12 21:13:55.944 Emacs[10829:6683] *** __NSAutoreleaseNoPool(): > Object 0x101ec41b0 of class NSBezierPath autoreleased with no pool in place > - just leaking > 2017-06-12 21:13:56.443 Emacs[10829:6683] *** __NSAutoreleaseNoPool(): > Object 0x10216c0f0 of class NSBezierPath autoreleased with no pool in place > - just leaking > 2017-06-12 21:13:56.444 Emacs[10829:6683] *** __NSAutoreleaseNoPool(): > Object 0x101ec43e0 of class NSBezierPath autoreleased with no pool in place > - just leaking It must be a sub‐thread running some objective c code without an autorelease pool. It would be nice to be able to work out where that’s happening. Perhaps threads will need to define an autorelease pool on creation, and drain it on ending... -- Alan Third --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="0001-Fix-threads-on-NS-bug-25265.patch" >From 22c33d9f2516dd488c3d76ccb3360e4855df7bb6 Mon Sep 17 00:00:00 2001 From: Alan Third Date: Tue, 13 Jun 2017 21:40:25 +0100 Subject: [PATCH] Fix threads on NS (bug#25265) --- src/nsterm.h | 2 +- src/nsterm.m | 10 ++++++++-- src/process.c | 4 ++++ 3 files changed, 13 insertions(+), 3 deletions(-) diff --git a/src/nsterm.h b/src/nsterm.h index bed0b92c79..10d5db2cff 100644 --- a/src/nsterm.h +++ b/src/nsterm.h @@ -1226,7 +1226,7 @@ extern void x_set_z_group (struct frame *f, Lisp_Object new_value, Lisp_Object old_value); extern int ns_select (int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timespec const *timeout, - sigset_t const *sigmask); + sigset_t *sigmask); extern unsigned long ns_get_rgb_color (struct frame *f, float r, float g, float b, float a); diff --git a/src/nsterm.m b/src/nsterm.m index e05dbf45fb..8fc27ed752 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -4294,7 +4294,7 @@ in certain situations (rapid incoming events). int ns_select (int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timespec const *timeout, - sigset_t const *sigmask) + sigset_t *sigmask) /* -------------------------------------------------------------------------- Replacement for select, checking for events -------------------------------------------------------------------------- */ @@ -4327,7 +4327,13 @@ in certain situations (rapid incoming events). if (NSApp == nil || ![NSThread isMainThread] || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0)) - return pselect (nfds, readfds, writefds, exceptfds, timeout, sigmask); + return thread_select(pselect, nfds, readfds, writefds, + exceptfds, timeout, sigmask); + else + { + struct timespec t = {0, 0}; + thread_select(pselect, 0, NULL, NULL, NULL, &t, sigmask); + } [outerpool release]; outerpool = [[NSAutoreleasePool alloc] init]; diff --git a/src/process.c b/src/process.c index 2a1c2eecde..eec907e14a 100644 --- a/src/process.c +++ b/src/process.c @@ -5371,6 +5371,10 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd, nfds = xg_select (max_desc + 1, &Available, (check_write ? &Writeok : 0), NULL, &timeout, NULL); +#elif defined HAVE_NS + nfds = ns_select (max_desc + 1, + &Available, (check_write ? &Writeok : 0), + NULL, &timeout, NULL); #else /* !HAVE_GLIB */ nfds = thread_select ( # ifdef HAVE_NS -- 2.12.0 --Nq2Wo0NMKNjxTN9z-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 15 14:58:02 2017 Received: (at 25265) by debbugs.gnu.org; 15 Jun 2017 18:58:02 +0000 Received: from localhost ([127.0.0.1]:49900 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLZxx-000784-TW for submit@debbugs.gnu.org; Thu, 15 Jun 2017 14:58:02 -0400 Received: from sinyavsky.aurox.ch ([37.35.109.145]:41892) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLZxv-00077p-Ho for 25265@debbugs.gnu.org; Thu, 15 Jun 2017 14:58:00 -0400 Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) by sinyavsky.aurox.ch (Postfix) with ESMTP id E8DC322475 for <25265@debbugs.gnu.org>; Thu, 15 Jun 2017 18:53:05 +0000 (UTC) Authentication-Results: sinyavsky.aurox.ch (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=aurox.ch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aurox.ch; h= content-transfer-encoding:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:to:subject:subject; s=dkim; t=1497552780; x= 1498416781; bh=nooOi2slSHLqA8yGtbc0ysfVV48A+tZK9qY8pQl/Sz0=; b=w kyoiTyOkNUgB76UPi0FYBeC/5r6rZkmN8rAPMhuXxzM5ErvF1UdfxO7mtCmIG4RK //yVKoWwDuO9Z2rTqdylXvREJXlqDf3EoINPSQ4tPwhhDqiqxTjg1AoO0sLhIj/U 73fEwLTEtcZ7bzLslD2ZpZfhN54yn2CyzCav6GhJUE= X-Virus-Scanned: Debian amavisd-new at test.virtualizor.com Received: from sinyavsky.aurox.ch ([127.0.0.1]) by sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZXLg-K9O1__T for <25265@debbugs.gnu.org>; Thu, 15 Jun 2017 18:53:00 +0000 (UTC) Received: from [192.168.1.121] (125.85.192.178.dynamic.wline.res.cust.swisscom.ch [178.192.85.125]) by sinyavsky.aurox.ch (Postfix) with ESMTPSA id D9A8C22457; Thu, 15 Jun 2017 18:52:59 +0000 (UTC) Subject: Re: bug#25265: make-thread crashes in OS X 10.6 To: Alan Third References: <20170502204935.GA79100@breton.holly.idiocy.org> <20170613204643.GA98084@breton.holly.idiocy.org> From: "Charles A. Roelli" Message-ID: Date: Thu, 15 Jun 2017 20:57:45 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170613204643.GA98084@breton.holly.idiocy.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 25265 Cc: 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Well done, it works here without a crash. I ran all the tests and 'thread-tests.el' passed. But I couldn't find how to rerun it. What command did you use? On 13/06/2017 22:46, Alan Third wrote: > On Mon, Jun 12, 2017 at 09:32:21PM +0200, Charles A. Roelli wrote: >> The issue seems to be improved now (not sure what changed it). >> >> I tried this sample code, and it worked without a crash: >> >> (dotimes (i 100) >> (make-thread (lambda () "string"))) >> >> Then I tried this code, and there's a crash every few runs (or >> sometimes, an infinite loop that can't be exited without killing the >> process). The crash normally happens when I supply input (via the >> keyboard), and the loop seems to be happen randomly. >> >> (make-thread (lambda () >> (dotimes (i 10) >> (sit-for 1) >> (goto-char (random (buffer-size)))))) > I went back and noticed an approach Eli suggested that I had given up > on, but understood this time round. > > I’ve attached a patch that seems to not crash. It introduces a warning > or two, and test/src/thread-tests.el randomly fails up to two tests, > but no crashes afaics. > >> I also noticed GDB's I/O buffer printing many of these warnings as >> soon as the `make-thread' form was called: >> >> 2017-06-12 21:13:55.943 Emacs[10829:6683] *** __NSAutoreleaseNoPool(): >> Object 0x10216bf50 of class NSBezierPath autoreleased with no pool in place >> - just leaking >> 2017-06-12 21:13:55.944 Emacs[10829:6683] *** __NSAutoreleaseNoPool(): >> Object 0x101ec41b0 of class NSBezierPath autoreleased with no pool in place >> - just leaking >> 2017-06-12 21:13:56.443 Emacs[10829:6683] *** __NSAutoreleaseNoPool(): >> Object 0x10216c0f0 of class NSBezierPath autoreleased with no pool in place >> - just leaking >> 2017-06-12 21:13:56.444 Emacs[10829:6683] *** __NSAutoreleaseNoPool(): >> Object 0x101ec43e0 of class NSBezierPath autoreleased with no pool in place >> - just leaking > It must be a sub‐thread running some objective c code without an > autorelease pool. It would be nice to be able to work out where that’s > happening. Perhaps threads will need to define an autorelease pool on > creation, and drain it on ending... From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 15 15:04:39 2017 Received: (at 25265) by debbugs.gnu.org; 15 Jun 2017 19:04:40 +0000 Received: from localhost ([127.0.0.1]:49904 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLa4N-0007IQ-Ll for submit@debbugs.gnu.org; Thu, 15 Jun 2017 15:04:39 -0400 Received: from mail-wm0-f46.google.com ([74.125.82.46]:38506) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLa4L-0007I8-9z for 25265@debbugs.gnu.org; Thu, 15 Jun 2017 15:04:37 -0400 Received: by mail-wm0-f46.google.com with SMTP id n195so6965990wmg.1 for <25265@debbugs.gnu.org>; Thu, 15 Jun 2017 12:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=4Xz2y4fdG047YZqtuWS8Iwc9uS4G7BYOWEx8Sf/hhdI=; b=oxJkiFlMFEfT9PBKk8vhbV3wD29GxzqlG11wYre0+55YvylZD81kCTLXs1b5FmPx26 eE4Iq3M+9cx/yIk5EGVIuDBVURNCsS3KU4k6/sbJfRr7DCSQkZ0iPwdBTi+RHVgsCDau CuFxFPtM4YNNh6Ps07qBieZvrkuHbTxMC+04WegJzZTwiCTsZ0/C0yU8o7v/zSPaQnC/ 26bEazINI+iwxgD50KPo1B/fEYAIGX2Ns2fcZVYb0s30K2ACAeqQFWKxrvij2AEMNXc/ szWFQdgOl8hmhXcQHRV0jvv7T8BEgsAlr6tQ+ncOmllqVctSGuP8nZBC92ivTInAV7Ou hJOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=4Xz2y4fdG047YZqtuWS8Iwc9uS4G7BYOWEx8Sf/hhdI=; b=uhIdG9/mM/rn1ANlDtCYhncoHJ1kFQ8/xHYWgywQK2VX7ZzH73MjkjexEsKhGT4iL3 t/ZdD3JoZDeyMd85Getuzrjcpma1VSrbjV6oajsKgTvbJwujWuxnQBAdWhk8thGnnoql VvxWYUpto41OzyY+M+4hdowlZqUuAEXeNCwBerBGX/DR/+T173IdoJ2kXSilc6LlV9ph BFEqZxQRiso3or4Qwhqcujfz4QBHTn++sCk9JTco1iykNT6BLIMB5bVDuVTatqOvxQql qEglP364WjFgNfF2tqJIYOp45Ua47i9+kUB6jbMH3bu9u1bjC0JYM0GkG4tgl3OSgVaU eEUA== X-Gm-Message-State: AKS2vOzgl5EvlG/FibkamlroM7C0O35v871vNtoue3hQSSUTFAU1M4zY gVLNBUj1UdZf1jyVfEk= X-Received: by 10.28.74.218 with SMTP id n87mr4706667wmi.16.1497553471433; Thu, 15 Jun 2017 12:04:31 -0700 (PDT) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-ac7d-b00e-c9b8-6bdc.holly.idiocy.org. [2001:8b0:3f8:8129:ac7d:b00e:c9b8:6bdc]) by smtp.gmail.com with ESMTPSA id k56sm49201wrk.45.2017.06.15.12.04.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jun 2017 12:04:30 -0700 (PDT) Date: Thu, 15 Jun 2017 20:04:32 +0100 From: Alan Third To: "Charles A. Roelli" Subject: Re: bug#25265: make-thread crashes in OS X 10.6 Message-ID: <20170615190432.GA12317@breton.holly.idiocy.org> References: <20170502204935.GA79100@breton.holly.idiocy.org> <20170613204643.GA98084@breton.holly.idiocy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 25265 Cc: 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) On Thu, Jun 15, 2017 at 08:57:45PM +0200, Charles A. Roelli wrote: > Well done, it works here without a crash. > > I ran all the tests and 'thread-tests.el' passed. But I couldn't find > how to rerun it. What command did you use? M-x ert Last time I tried I couldn’t get two tests to fail, so I don’t know what the second one was. The other test fails more often than not here. I think I’ll probably have to go back through old threading bugs and see if I can pick up any hints as to what might cause the test to fail. My output: Selector: t Passed: 27 Failed: 1 (1 unexpected) Skipped: 0 Total: 28/28 Started at: 2017-06-15 20:03:07+0100 Finished. Finished at: 2017-06-15 20:03:12+0100 .F.......................... F thread-signal-early Test signaling a thread as soon as it is started by the OS. (ert-test-failed ((should-not (thread-alive-p thread)) :form (thread-alive-p #) :value t)) -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 15 15:14:11 2017 Received: (at 25265) by debbugs.gnu.org; 15 Jun 2017 19:14:11 +0000 Received: from localhost ([127.0.0.1]:49909 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLaDb-0007VW-Jb for submit@debbugs.gnu.org; Thu, 15 Jun 2017 15:14:11 -0400 Received: from mail-oi0-f50.google.com ([209.85.218.50]:35502) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLaDa-0007VK-Hc for 25265@debbugs.gnu.org; Thu, 15 Jun 2017 15:14:10 -0400 Received: by mail-oi0-f50.google.com with SMTP id e11so13074938oia.2 for <25265@debbugs.gnu.org>; Thu, 15 Jun 2017 12:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lwiIbdm+ltSILAvlbsACBcVZad52aUFHQ9KumoRnxuA=; b=pSV8Y9fKKcvRXnGwzM44tmVn3QlpWsyPXc0pgA8uf7HOrJmpqjNV/SMSbZgzTAp//f 7FX7gKXjQvPOSik/89U8ZRJluwSveoE7upQSHNxzgY9QaUguUA0uQWoSGp1s57PH/i9P NrlrizWlQ58w2IqBQwsJDi/hND/eSVeZ3vMgEf//CErBt3FUaJ6W2t+L95lc8XMFPMTi GdHwd/7eCj+5rHkfyrQ6HESnHzQNqC75ZJktVuR/YjtT8GP1W7gcQ7RxtS9yDIwUcIve NgeZLKepu0gU58X4rcqOCjFS0A3BttkhrdiUyko1sfMpRbWUNsgH2CiA+Nv1zeDJDAdj Nbow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lwiIbdm+ltSILAvlbsACBcVZad52aUFHQ9KumoRnxuA=; b=kH5S2kB3P9TtqvZBEWSTuOAQ5X/yMtrtc1RIa53Obsgw4yCcw/hanvYt1YG2MP34hl iIIo/fQux71twsUYzymcUFAqyrPQ5qpUQFT1K01wQtMbLSKvVetCz9jZ3x+pefDHnN9X ZW0o6qf9xkale9bY262VqbNru7+m/KgniWySg7Spv/7kx+epfy4swnbAi0SRh1seAuZQ aZhOfP0CaVxfwnmBSIDTSZhR4kLbYtJXKo9ql5KXm6KXwQm9GoobL4PQLDAH2cy4OG7M RSnpJLf3EDYchXHPDHcajpXTRO+eeyajRN0Lm9P6s3+WzKHeU8dN+n1QMp7esrmZ2ydJ 7M9Q== X-Gm-Message-State: AKS2vOya69IGc38l/3B42ZbTI81Rx+J1TFaCMwIGTXhr+djs47JialYX AkFQKMJOdXzBIx7mPD+IuMhHMsHTDOZk X-Received: by 10.202.214.211 with SMTP id n202mr3393351oig.48.1497554044838; Thu, 15 Jun 2017 12:14:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.113.80 with HTTP; Thu, 15 Jun 2017 12:14:04 -0700 (PDT) In-Reply-To: <20170615190432.GA12317@breton.holly.idiocy.org> References: <20170502204935.GA79100@breton.holly.idiocy.org> <20170613204643.GA98084@breton.holly.idiocy.org> <20170615190432.GA12317@breton.holly.idiocy.org> From: Noam Postavsky Date: Thu, 15 Jun 2017 15:14:04 -0400 X-Google-Sender-Auth: 6TJxBZdGTAVpTQrQM7J_qGKcz7A Message-ID: Subject: Re: bug#25265: make-thread crashes in OS X 10.6 To: Alan Third Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 25265 Cc: "Charles A. Roelli" , 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) On Thu, Jun 15, 2017 at 3:04 PM, Alan Third wrote: > On Thu, Jun 15, 2017 at 08:57:45PM +0200, Charles A. Roelli wrote: >> >> I ran all the tests and 'thread-tests.el' passed. But I couldn't find >> how to rerun it. What command did you use? > > M-x ert R (ert-results-rerun-all-tests) in the *ert* buffer should also work. From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 15:45:38 2017 Received: (at 25265) by debbugs.gnu.org; 16 Jun 2017 19:45:39 +0000 Received: from localhost ([127.0.0.1]:51720 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLxBa-0003Uj-Nu for submit@debbugs.gnu.org; Fri, 16 Jun 2017 15:45:38 -0400 Received: from mail-wr0-f182.google.com ([209.85.128.182]:33182) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLxBZ-0003UX-Ao for 25265@debbugs.gnu.org; Fri, 16 Jun 2017 15:45:37 -0400 Received: by mail-wr0-f182.google.com with SMTP id r103so43635856wrb.0 for <25265@debbugs.gnu.org>; Fri, 16 Jun 2017 12:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=+3wgXYTHieP2HxUMwHwtt3g1E66QoVkhK4bpY3ov3Ic=; b=CdrMn45dsasXeneJNBGxYz2UI93fvwnY0nFWtuQefbO5AvmervratAE/yxiDapiWP8 pDGda/hnEUyoy5q1c19l3MAVvRv/Qyjy9yIEmBFq9sNZgRnWYcHHkySRzH3HB8Vm+UdN pXBNiZty4oZQOriUIHr31y2OBzyE1LXfyZ5Jh9LKqlWtcEh4d1U533cVoCzLNjGScgNn yAUH8B5r7Z652/pvnEk+oEz0BOD9a8Tbuy1VnC42Hbng3iGn2e7IPNZKAyMoeWi7mqr2 jG42w0985zp0cUPzoHF+41aVoxgDGLRAjIYLJ6IkC8GCG3dK0A03AVBvYiuHrArGFbE8 QMUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=+3wgXYTHieP2HxUMwHwtt3g1E66QoVkhK4bpY3ov3Ic=; b=nse9Ssv905+UBs4ChwBF5Lts395i6tRjw5uT7MCDB3HqrRUuSfOyoyBkvRp+bUsLJr 6bfnc8TLmC6gK1AbfL6LPm84h8O+dJFL8UAjCUGKItxWfvbvR9ceEBfT0jHZ195TlgJi wOTDAF4qW14nF/7INzaOW9/2Ugq8GMOJF672NUuzoeLXm05dI01+xCrPi2knbxEhA/Hf yyOmB4bzNO9rB/fIeaIPrSFALhf0JKgiIhUpddFFQQvUHVOF6HvVgfGY5KdIa+g2WthG lk3rJ6QgCazM9Lbh7gNTrGw53R6r4YWgnoY2lnUW0clz+m8v23Fgxeg2LW/PCXt5f9za Z9CQ== X-Gm-Message-State: AKS2vOy1yrL5jXEoxBuY0heyuWztAWBlQdaoNPZRuHr5B3dob54P4lLP GLHkAz1ATC7QeuJZTr0= X-Received: by 10.223.162.151 with SMTP id s23mr7947586wra.68.1497642331272; Fri, 16 Jun 2017 12:45:31 -0700 (PDT) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-ac7d-b00e-c9b8-6bdc.holly.idiocy.org. [2001:8b0:3f8:8129:ac7d:b00e:c9b8:6bdc]) by smtp.gmail.com with ESMTPSA id e77sm2178090wma.32.2017.06.16.12.45.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jun 2017 12:45:30 -0700 (PDT) Date: Fri, 16 Jun 2017 20:45:31 +0100 From: Alan Third To: "Charles A. Roelli" Subject: Re: bug#25265: make-thread crashes in OS X 10.6 Message-ID: <20170616194531.GA27453@breton.holly.idiocy.org> References: <20170502204935.GA79100@breton.holly.idiocy.org> <20170613204643.GA98084@breton.holly.idiocy.org> <20170615190432.GA12317@breton.holly.idiocy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170615190432.GA12317@breton.holly.idiocy.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 25265 Cc: 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) On Thu, Jun 15, 2017 at 08:04:32PM +0100, Alan Third wrote: > Last time I tried I couldn’t get two tests to fail, so I don’t know > what the second one was. The other test fails more often than not > here. I got two to fail this time: Selector: t Passed: 26 Failed: 2 (2 unexpected) Skipped: 0 Total: 28/28 Started at: 2017-06-16 20:36:24+0100 Finished. Finished at: 2017-06-16 20:36:29+0100 .F........F................. F thread-signal-early Test signaling a thread as soon as it is started by the OS. (ert-test-failed ((should-not (thread-alive-p thread)) :form (thread-alive-p #) :value t)) F threads-condvar-wait test waiting on conditional variable (ert-test-failed ((should (= (length (all-threads)) 1)) :form (= 2 1) :value nil)) Anyone got any bright ideas where to start with debugging these? The first one looks like the thread’s starting too quick? The second looks like the thread’s not dying quick enough? Is this possibly just an artifact of the way that ns_select calls thread_select then afterwards does its actual pselect/NS Event stuff? -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 16:06:06 2017 Received: (at 25265) by debbugs.gnu.org; 16 Jun 2017 20:06:06 +0000 Received: from localhost ([127.0.0.1]:51726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLxVO-0003xb-FA for submit@debbugs.gnu.org; Fri, 16 Jun 2017 16:06:06 -0400 Received: from mail-oi0-f47.google.com ([209.85.218.47]:35255) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLxVM-0003x5-Fs for 25265@debbugs.gnu.org; Fri, 16 Jun 2017 16:06:05 -0400 Received: by mail-oi0-f47.google.com with SMTP id c189so6835471oia.2 for <25265@debbugs.gnu.org>; Fri, 16 Jun 2017 13:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=yybGo/uKB/oQa6O9I+bnaT2v2H9h+LoZuHRDdQb7+WY=; b=gqARGqloFuy1tD3svTKyFwEmku/aVy2cgr5FbWW2gct7TdyNewrn2JnQnSdFMnodKz l9K1iwKlB/VSjdNVEZTpclE4INV18Fn9RLT5uaZfeLi6Ce2lQdWvCZU/41fqFJDHf6Kl szaeQOlXAYqtr5eXyujEn6Ou6MqfOJKPVxz9ZE+lgZdzCCZad0eovyK3hISYLx6JIUV5 wpd+2DgaK9JpGMaa28QihHG8CyvK7q83JHYSWk56mD74SKtsz+Nku3x4KhkPFEZJhXCX 9hyGUE8w7mVgZnRym2Zw5GI+t8IcWBoUBXtwbTcMEzb6MuirGFYrg5H+2XanJijbDcJF byWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=yybGo/uKB/oQa6O9I+bnaT2v2H9h+LoZuHRDdQb7+WY=; b=MJycidxaZJIhQISjoD/FXmGTfAU5UHZWM2MCCRuLj2NSr2LM0pPvInR0pdonN8Ud3p oTZ6IuD3l2Mn1eAOKrCTXpASSgYW/ZcisHBtUMwUvm5ORriG0RITiGdJ5tQPek1kiCds 5L7aSyaZW9EkFFhViSNJ+D2YPQ7Ms7Rana5y+UecUlxmZFkDegeSQwPG6VtTTgxv6krr CJ5Wt9biuCenB8YQ7eGUJ0vbb5RSedlVGYbmBXo3SVfGHLteGn59sJlAiG/DpjEkTR8i VNCx18UoDixkJ+MiH0u7vVkLuwI4cfwZbjEzvPZu/3p52PPZNDuHr5aX/jsJdWRV9h8X fhHg== X-Gm-Message-State: AKS2vOyaNiQ+sXuIHqeSn60Sj3UrWvfmWDW901nozoTqTNbJrXcqY355 h4BGNGcXEDAPoQjc7+ZkvPEGpvaNyg== X-Received: by 10.202.81.134 with SMTP id f128mr7129218oib.152.1497643558872; Fri, 16 Jun 2017 13:05:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.113.80 with HTTP; Fri, 16 Jun 2017 13:05:58 -0700 (PDT) In-Reply-To: <20170616194531.GA27453@breton.holly.idiocy.org> References: <20170502204935.GA79100@breton.holly.idiocy.org> <20170613204643.GA98084@breton.holly.idiocy.org> <20170615190432.GA12317@breton.holly.idiocy.org> <20170616194531.GA27453@breton.holly.idiocy.org> From: Noam Postavsky Date: Fri, 16 Jun 2017 16:05:58 -0400 X-Google-Sender-Auth: vTpBbqcumoczEZZpUEd8w4Zse7E Message-ID: Subject: Re: bug#25265: make-thread crashes in OS X 10.6 To: Alan Third Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 25265 Cc: "Charles A. Roelli" , 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) On Fri, Jun 16, 2017 at 3:45 PM, Alan Third wrote: > The first one looks like the thread=E2=80=99s starting too quick? I think it's rather failing to be killed by the `thread-signal' call. > The second looks like the thread=E2=80=99s not dying quick enough? Same for that one. I don't know much about the thread internals, and even less macOS internals though... From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 16:51:45 2017 Received: (at 25265) by debbugs.gnu.org; 16 Jun 2017 20:51:45 +0000 Received: from localhost ([127.0.0.1]:51744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLyDZ-00052m-8w for submit@debbugs.gnu.org; Fri, 16 Jun 2017 16:51:45 -0400 Received: from mail-wr0-f181.google.com ([209.85.128.181]:36251) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLyDY-00052X-3r for 25265@debbugs.gnu.org; Fri, 16 Jun 2017 16:51:44 -0400 Received: by mail-wr0-f181.google.com with SMTP id 36so43952293wry.3 for <25265@debbugs.gnu.org>; Fri, 16 Jun 2017 13:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=ThpzhxqUyZHJyPYKv2zd7h4T/21j5H8JAg57u8+Yhbw=; b=iOk5WpQDVUa6ZNIJL3WDGLzDUDbWTKskO6qToN0bwti+RsqfC1rZ+OYHv/Z2n78gmA fVaMNU7P/pVU6LmR8vzufd7mGYRahbOs1LY1UED0DWHDtfctcFRUWk1DCORZguB1/5D/ kufLi1XIS9z+ewr8A0080c+BauIYSw0klVlwbZzMruAU0OSDHyZiL/euRY03pHvWQowK NQqmmuKDE6ReTVVKgSwim6A+jXJuhu9HTiSIsHzn9u/l1giu3lpkrecqGw65dutH8CSm +2TWnmgGo101A+IXQAeMsH3nhRH4M7cyNHYIXuuKLcg/2+8nDEeUAzMq6F0hRraT50Jp RbVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=ThpzhxqUyZHJyPYKv2zd7h4T/21j5H8JAg57u8+Yhbw=; b=MCo/kLbqX6Jeb6HyiTUuG2IzZN4hl8PKqF0Z6OgZ+CQkcJlD7G0tNJEzIul886e7+d jqyzS2XX4txynWH+WS9LSt91kUFYcBiYgd/44DdAV2UfrpGZCbgw0MkzQeCliQUQs5pe Ukm/U7UYb6OGechuD8h7Yg4Cq0eveUkG181Cu/S+jyizQL3yW0V90z3r48oxIiydkPAa 0QHHOt+YTPiDgcZSFiVE3k67kp9IDBKqe7/k6MKt9hb7hZIphGltCvF7KLx9BOSSbXpc 2VvVr8fl5zrNrwjYzdFQ++03UcWRzHaNPMt3HjJEjziXQUeu8URzInSxiau3ZWwIy2Zq FlRQ== X-Gm-Message-State: AKS2vOwW8Tv2qP2b2zHfRYeblXuOOBZRgg1uxKzA1OlmkYx7umO4ie1T IE05AUcp+alFYA== X-Received: by 10.223.167.15 with SMTP id c15mr9563137wrd.79.1497646298223; Fri, 16 Jun 2017 13:51:38 -0700 (PDT) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-ac7d-b00e-c9b8-6bdc.holly.idiocy.org. [2001:8b0:3f8:8129:ac7d:b00e:c9b8:6bdc]) by smtp.gmail.com with ESMTPSA id j10sm2715773wre.67.2017.06.16.13.51.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jun 2017 13:51:37 -0700 (PDT) Date: Fri, 16 Jun 2017 21:51:39 +0100 From: Alan Third To: Noam Postavsky Subject: Re: bug#25265: make-thread crashes in OS X 10.6 Message-ID: <20170616205139.GA27574@breton.holly.idiocy.org> References: <20170502204935.GA79100@breton.holly.idiocy.org> <20170613204643.GA98084@breton.holly.idiocy.org> <20170615190432.GA12317@breton.holly.idiocy.org> <20170616194531.GA27453@breton.holly.idiocy.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 25265 Cc: "Charles A. Roelli" , 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Fri, Jun 16, 2017 at 04:05:58PM -0400, Noam Postavsky wrote: > On Fri, Jun 16, 2017 at 3:45 PM, Alan Third wrote: > > The first one looks like the thread’s starting too quick? > > I think it's rather failing to be killed by the `thread-signal' call. Ah, yes. I completely misread the test. > > The second looks like the thread’s not dying quick enough? > > Same for that one. I don't know much about the thread internals, and > even less macOS internals though... Well, I’ve discovered that if I keep the mouse moving over the Emacs frame while the tests are running then none of them fail, so I think it’s something to do with ns_select jamming everything up for the duration of its timeout. I could probably get round that by getting the thread to fire off an NS app defined event when it dies. That would break ns_select out of its event loop, presumably letting the dying thread actually die... Amazingly that seems to have worked! Updated patch attached. -- Alan Third --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="0001-Fix-threads-on-NS-bug-25265.patch" >From ab35f15d5091c29011f6a538009612f1b5c5137d Mon Sep 17 00:00:00 2001 From: Alan Third Date: Tue, 13 Jun 2017 21:40:25 +0100 Subject: [PATCH] Fix threads on NS (bug#25265) src/nsterm.h (ns_select): Compiler doesn't like sigmask being const. (ns_select_break) [HAVE_PTHREAD]: New function. src/nsterm.m (ns_select): Call thread_select from within ns_select. (ns_select_break) [HAVE_PTHREAD]: New function. (ns_send_appdefined): Don't wait for main thread when sending app defined event. src/process.c (wait_reading_process_output): Call thread_select from within ns_select. src/systhread.c (sys_cond_broadcast) [HAVE_NS]: Break ns_select out of its event loop. --- src/nsterm.h | 7 +++++-- src/nsterm.m | 21 +++++++++++++++++---- src/process.c | 13 ++++++------- src/systhread.c | 7 +++++++ 4 files changed, 35 insertions(+), 13 deletions(-) diff --git a/src/nsterm.h b/src/nsterm.h index bed0b92c79..eac54e1bcf 100644 --- a/src/nsterm.h +++ b/src/nsterm.h @@ -1225,8 +1225,11 @@ extern void x_set_no_accept_focus (struct frame *f, Lisp_Object new_value, extern void x_set_z_group (struct frame *f, Lisp_Object new_value, Lisp_Object old_value); extern int ns_select (int nfds, fd_set *readfds, fd_set *writefds, - fd_set *exceptfds, struct timespec const *timeout, - sigset_t const *sigmask); + fd_set *exceptfds, struct timespec *timeout, + sigset_t *sigmask); +#ifdef HAVE_PTHREAD +extern void ns_select_break (void); +#endif extern unsigned long ns_get_rgb_color (struct frame *f, float r, float g, float b, float a); diff --git a/src/nsterm.m b/src/nsterm.m index e05dbf45fb..29a45ed851 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -4068,7 +4068,7 @@ overwriting cursor (usually when cursor on a tab) */ app->nextappdefined = value; [app performSelectorOnMainThread:@selector (sendFromMainThread:) withObject:nil - waitUntilDone:YES]; + waitUntilDone:NO]; return; } @@ -4293,8 +4293,8 @@ in certain situations (rapid incoming events). int ns_select (int nfds, fd_set *readfds, fd_set *writefds, - fd_set *exceptfds, struct timespec const *timeout, - sigset_t const *sigmask) + fd_set *exceptfds, struct timespec *timeout, + sigset_t *sigmask) /* -------------------------------------------------------------------------- Replacement for select, checking for events -------------------------------------------------------------------------- */ @@ -4327,7 +4327,13 @@ in certain situations (rapid incoming events). if (NSApp == nil || ![NSThread isMainThread] || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0)) - return pselect (nfds, readfds, writefds, exceptfds, timeout, sigmask); + return thread_select(pselect, nfds, readfds, writefds, + exceptfds, timeout, sigmask); + else + { + struct timespec t = {0, 0}; + thread_select(pselect, 0, NULL, NULL, NULL, &t, sigmask); + } [outerpool release]; outerpool = [[NSAutoreleasePool alloc] init]; @@ -4430,6 +4436,13 @@ in certain situations (rapid incoming events). return result; } +#ifdef HAVE_PTHREAD +void +ns_select_break () +{ + ns_send_appdefined(-1); +} +#endif /* ========================================================================== diff --git a/src/process.c b/src/process.c index 2a1c2eecde..abd017bb90 100644 --- a/src/process.c +++ b/src/process.c @@ -5371,14 +5371,13 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd, nfds = xg_select (max_desc + 1, &Available, (check_write ? &Writeok : 0), NULL, &timeout, NULL); +#elif defined HAVE_NS + /* And NS builds call thread_select in ns_select. */ + nfds = ns_select (max_desc + 1, + &Available, (check_write ? &Writeok : 0), + NULL, &timeout, NULL); #else /* !HAVE_GLIB */ - nfds = thread_select ( -# ifdef HAVE_NS - ns_select -# else - pselect -# endif - , max_desc + 1, + nfds = thread_select (pselect, max_desc + 1, &Available, (check_write ? &Writeok : 0), NULL, &timeout, NULL); diff --git a/src/systhread.c b/src/systhread.c index a84060c18f..53dfe7a9c4 100644 --- a/src/systhread.c +++ b/src/systhread.c @@ -20,6 +20,10 @@ along with GNU Emacs. If not, see . */ #include #include "lisp.h" +#ifdef HAVE_NS +#include "nsterm.h" +#endif + #ifndef THREADS_ENABLED void @@ -130,6 +134,9 @@ void sys_cond_broadcast (sys_cond_t *cond) { pthread_cond_broadcast (cond); +#ifdef HAVE_NS + ns_select_break (); +#endif } void -- 2.12.0 --BOKacYhQ+x31HxR3-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 18 09:05:19 2017 Received: (at 25265) by debbugs.gnu.org; 18 Jun 2017 13:05:19 +0000 Received: from localhost ([127.0.0.1]:54077 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMZtH-0001ao-I7 for submit@debbugs.gnu.org; Sun, 18 Jun 2017 09:05:19 -0400 Received: from sinyavsky.aurox.ch ([37.35.109.145]:44184) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMZtE-0001aW-JB for 25265@debbugs.gnu.org; Sun, 18 Jun 2017 09:05:18 -0400 Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) by sinyavsky.aurox.ch (Postfix) with ESMTP id A172C22479 for <25265@debbugs.gnu.org>; Sun, 18 Jun 2017 13:00:18 +0000 (UTC) Authentication-Results: sinyavsky.aurox.ch (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=aurox.ch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aurox.ch; h= content-transfer-encoding:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:to:subject:subject; s=dkim; t=1497790816; x= 1498654817; bh=QUNGcGY8+yu5Dz4KhwlSW7yEkg5PBzfDgMl3qMOsqiY=; b=B eQSUojmS/RpJDZm8v/c7MbvRut5yWF863Uu3af/aCHguvoUZOzInG0ys2/QVJwjD W5dCc9pW9ZxbBHui8ZYlnFWK/0X/GVKc+4LG/48cLU6xITC+KkkBxeYKekF+rRxt zRXr3ffUPUSo9DKyRey8rL1WwTc9S7i5vb1ikqQFvk= X-Virus-Scanned: Debian amavisd-new at test.virtualizor.com Received: from sinyavsky.aurox.ch ([127.0.0.1]) by sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TBp8mrDNhSPl for <25265@debbugs.gnu.org>; Sun, 18 Jun 2017 13:00:16 +0000 (UTC) Received: from [192.168.1.121] (125.85.192.178.dynamic.wline.res.cust.swisscom.ch [178.192.85.125]) by sinyavsky.aurox.ch (Postfix) with ESMTPSA id 51CA322457; Sun, 18 Jun 2017 13:00:16 +0000 (UTC) Subject: Re: bug#25265: make-thread crashes in OS X 10.6 To: Alan Third , Noam Postavsky References: <20170502204935.GA79100@breton.holly.idiocy.org> <20170613204643.GA98084@breton.holly.idiocy.org> <20170615190432.GA12317@breton.holly.idiocy.org> <20170616194531.GA27453@breton.holly.idiocy.org> <20170616205139.GA27574@breton.holly.idiocy.org> From: "Charles A. Roelli" Message-ID: Date: Sun, 18 Jun 2017 15:05:04 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170616205139.GA27574@breton.holly.idiocy.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 25265 Cc: 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) The tests sometimes all pass with the updated patch, but then I got this once (the errors you've seen previously, I think): Selector: t Passed: 26 Failed: 2 (2 unexpected) Skipped: 0 Total: 28/28 Started at: 2017-06-18 14:54:43+0200 Finished. Finished at: 2017-06-18 14:54:47+0200 .F........F................. F thread-signal-early Test signaling a thread as soon as it is started by the OS. (ert-test-failed ((should-not (thread-alive-p thread)) :form (thread-alive-p #) :value t)) F threads-condvar-wait test waiting on conditional variable (ert-test-failed ((should (= (length (all-threads)) 1)) :form (= 2 1) :value nil)) from nextstep/Emacs.app/Contents/MacOS/Emacs -Q -l ert -l test/src/thread-tests.el I also tried this way of running the tests in batch mode: cd test && rm -rf src/thread-tests.log && make src/thread-tests.log but got a segfault: GEN src/thread-tests.log /bin/sh: line 1: 87214 Segmentation fault HOME=/nonexistent EMACSLOADPATH= LC_ALL=C EMACS_TEST_DIRECTORY=/Volumes/Toblerone/Code/emacs-devel/test "../src/emacs" -batch --no-site-file --no-site-lisp -L ":." -l ert -l src/thread-tests.el --eval "(ert-run-tests-batch-and-exit nil)" > src/thread-tests.log 2>&1 Running 28 tests (2017-06-18 15:00:03+0200) make: *** [src/thread-tests.log] Error 139 I'm not sure where the problem is happening (or if it's specific to NS). The file 'src/thread-tests.log' also doesn't give any extra information (besides 'Running 28 tests (2017-06-18 15:00:03+0200)'). On 16/06/2017 22:51, Alan Third wrote: > On Fri, Jun 16, 2017 at 04:05:58PM -0400, Noam Postavsky wrote: >> On Fri, Jun 16, 2017 at 3:45 PM, Alan Third wrote: >>> The first one looks like the threads starting too quick? >> I think it's rather failing to be killed by the `thread-signal' call. > Ah, yes. I completely misread the test. > >>> The second looks like the threads not dying quick enough? >> Same for that one. I don't know much about the thread internals, and >> even less macOS internals though... > Well, Ive discovered that if I keep the mouse moving over the Emacs > frame while the tests are running then none of them fail, so I think > its something to do with ns_select jamming everything up for the > duration of its timeout. > > I could probably get round that by getting the thread to fire off an > NS app defined event when it dies. That would break ns_select out of > its event loop, presumably letting the dying thread actually die... > > Amazingly that seems to have worked! Updated patch attached. From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 18 10:01:29 2017 Received: (at 25265) by debbugs.gnu.org; 18 Jun 2017 14:01:29 +0000 Received: from localhost ([127.0.0.1]:55216 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMald-0003Ge-EC for submit@debbugs.gnu.org; Sun, 18 Jun 2017 10:01:29 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:35066) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMalb-0003GP-MB for 25265@debbugs.gnu.org; Sun, 18 Jun 2017 10:01:28 -0400 Received: by mail-wm0-f54.google.com with SMTP id x70so59144272wme.0 for <25265@debbugs.gnu.org>; Sun, 18 Jun 2017 07:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=feqk9UkHA/o7l+zhGSSYIIhInVV3KglzVt6feKp80AI=; b=HXLXQlL9PucYCogxmiDUKAlNqZ0zRMqoxxYV8WCqNmYujRKGCDyznXHVuBTAJV5Pjk v2E6Yfctmfeu/LykeqbuBmxBtYWUTEtD1AAbOLuhrBCE1pqzem84duCT0xQ7vADP5Y+B X51dQ7aVzNV3rvsW1jxF6UAAOL0H2VeUBLfkcfDUaF7B3UL+e4+K0sqanKtMHT/Gv+x7 05TgUHFxH/B3p53Fz+5ut+ZIUX3WoWieV9Fh+4LcrHZK8SG1SP2PAkScNJ183ddj9aha GAGW7U/Rk9OYP9IbRZRAIfLbDKVnURZdT2+ViWB8eMS0ANiKB56kIs8xlseKZVdLJeJS sZCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=feqk9UkHA/o7l+zhGSSYIIhInVV3KglzVt6feKp80AI=; b=G30y6vd9eL2lTQektvyegAB4Yz+Rq4pEDJSyDcm4tKv5utZX1dLK2c6suIziwsJK4w IQe5ccIoSAZukX6/cDC1UFFhkZsIYunEak4oJYy4ofWjGc+tWS1PhnM3QgAxA1DBUFA6 vX86UxDMTTO6QeYtD0eOUD2XuZUEy/JO7N+tLBOyC/+l9ya+R79wxBjMKVZU9QSBe8Yz nhuS7v9JZPn161M8JIgOguwTi2AUj8gWhIZQyjoXC+BRP4JUjuiswpI4KEPps4XPtHXV 0uj3V1aa7nGW9b1rVMb/Ngg6Gwn5zwQh040gekMzsqni4HpVWI/IyBr7Rad3lTV1Vzz4 kpuA== X-Gm-Message-State: AKS2vOzOFZB6w1TpGSlN8ZtiruZ3jsmsM+pVhJ/14tLNXgTTT6opL/T0 321d8oUq9U4UhTtRQfOBWg== X-Received: by 10.28.51.199 with SMTP id z190mr3589927wmz.103.1497794481862; Sun, 18 Jun 2017 07:01:21 -0700 (PDT) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-9c48-3d60-5bc4-3b29.holly.idiocy.org. [2001:8b0:3f8:8129:9c48:3d60:5bc4:3b29]) by smtp.gmail.com with ESMTPSA id b192sm3925712wmf.25.2017.06.18.07.01.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Jun 2017 07:01:20 -0700 (PDT) Date: Sun, 18 Jun 2017 15:01:18 +0100 From: Alan Third To: "Charles A. Roelli" Subject: Re: bug#25265: make-thread crashes in OS X 10.6 Message-ID: <20170618140118.GA33083@breton.holly.idiocy.org> References: <20170502204935.GA79100@breton.holly.idiocy.org> <20170613204643.GA98084@breton.holly.idiocy.org> <20170615190432.GA12317@breton.holly.idiocy.org> <20170616194531.GA27453@breton.holly.idiocy.org> <20170616205139.GA27574@breton.holly.idiocy.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) 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: On Sun, Jun 18, 2017 at 03:05:04PM +0200, Charles A. Roelli wrote: > The tests sometimes all pass with the updated patch, but then I got > this once (the errors you've seen previously, I think): > [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (athird[at]googlemail.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [74.125.82.54 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [74.125.82.54 listed in wl.mailspike.net] -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 1.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different X-Debbugs-Envelope-To: 25265 Cc: 25265@debbugs.gnu.org, Noam Postavsky 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.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: On Sun, Jun 18, 2017 at 03:05:04PM +0200, Charles A. Roelli wrote: > The tests sometimes all pass with the updated patch, but then I got > this once (the errors you've seen previously, I think): > [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [74.125.82.54 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [74.125.82.54 listed in list.dnswl.org] 1.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (athird[at]googlemail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 1.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Sun, Jun 18, 2017 at 03:05:04PM +0200, Charles A. Roelli wrote: > The tests sometimes all pass with the updated patch, but then I got > this once (the errors you've seen previously, I think): > Yeah, they look the same. I’m not sure what I can do to fix them if they’re still happening. > I also tried this way of running the tests in batch mode: > > cd test && rm -rf src/thread-tests.log && make src/thread-tests.log > > but got a segfault: > > GEN src/thread-tests.log > /bin/sh: line 1: 87214 Segmentation fault HOME=/nonexistent > EMACSLOADPATH= LC_ALL=C > EMACS_TEST_DIRECTORY=/Volumes/Toblerone/Code/emacs-devel/test "../src/emacs" > -batch --no-site-file --no-site-lisp -L ":." -l ert -l src/thread-tests.el > --eval "(ert-run-tests-batch-and-exit nil)" > src/thread-tests.log 2>&1 > Running 28 tests (2017-06-18 15:00:03+0200) > make: *** [src/thread-tests.log] Error 139 > > I'm not sure where the problem is happening (or if it's specific to > NS). The file 'src/thread-tests.log' also doesn't give any extra > information (besides 'Running 28 tests (2017-06-18 15:00:03+0200)'). Yeah, I think that’s because I, accidentally, have the non‐GUI version trying to run some GUI stuff. I noticed this myself yesterday. Running NS Emacs without a GUI has always worked with threads because it just bypasses the NS run loop which is the problem. I’ve attached a new patch that actually checks whether we’re running the NS GUI. -- Alan Third --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="0001-Fix-threads-on-NS-bug-25265.patch" >From 62ac72333084ae32719d63b82166f1c6daee1ed9 Mon Sep 17 00:00:00 2001 From: Alan Third Date: Tue, 13 Jun 2017 21:40:25 +0100 Subject: [PATCH] Fix threads on NS (bug#25265) src/nsterm.h (ns_select): Compiler doesn't like sigmask being const. (ns_run_loop_break) [HAVE_PTHREAD]: New function. src/nsterm.m (ns_select): Call thread_select from within ns_select. (ns_run_loop_break) [HAVE_PTHREAD]: New function. (ns_send_appdefined): Don't wait for main thread when sending app defined event. src/process.c (wait_reading_process_output): Call thread_select from within ns_select. src/systhread.c (sys_cond_broadcast) [HAVE_NS]: Break ns_select out of its event loop using ns_run_loop_break. --- src/nsterm.h | 7 +++++-- src/nsterm.m | 26 ++++++++++++++++++++++---- src/process.c | 13 ++++++------- src/systhread.c | 11 +++++++++++ 4 files changed, 44 insertions(+), 13 deletions(-) diff --git a/src/nsterm.h b/src/nsterm.h index bed0b92c79..73d846d114 100644 --- a/src/nsterm.h +++ b/src/nsterm.h @@ -1225,8 +1225,11 @@ extern void x_set_no_accept_focus (struct frame *f, Lisp_Object new_value, extern void x_set_z_group (struct frame *f, Lisp_Object new_value, Lisp_Object old_value); extern int ns_select (int nfds, fd_set *readfds, fd_set *writefds, - fd_set *exceptfds, struct timespec const *timeout, - sigset_t const *sigmask); + fd_set *exceptfds, struct timespec *timeout, + sigset_t *sigmask); +#ifdef HAVE_PTHREAD +extern void ns_run_loop_break (void); +#endif extern unsigned long ns_get_rgb_color (struct frame *f, float r, float g, float b, float a); diff --git a/src/nsterm.m b/src/nsterm.m index e05dbf45fb..bf83550b3d 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -4068,7 +4068,7 @@ overwriting cursor (usually when cursor on a tab) */ app->nextappdefined = value; [app performSelectorOnMainThread:@selector (sendFromMainThread:) withObject:nil - waitUntilDone:YES]; + waitUntilDone:NO]; return; } @@ -4293,8 +4293,8 @@ in certain situations (rapid incoming events). int ns_select (int nfds, fd_set *readfds, fd_set *writefds, - fd_set *exceptfds, struct timespec const *timeout, - sigset_t const *sigmask) + fd_set *exceptfds, struct timespec *timeout, + sigset_t *sigmask) /* -------------------------------------------------------------------------- Replacement for select, checking for events -------------------------------------------------------------------------- */ @@ -4327,7 +4327,13 @@ in certain situations (rapid incoming events). if (NSApp == nil || ![NSThread isMainThread] || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0)) - return pselect (nfds, readfds, writefds, exceptfds, timeout, sigmask); + return thread_select(pselect, nfds, readfds, writefds, + exceptfds, timeout, sigmask); + else + { + struct timespec t = {0, 0}; + thread_select(pselect, 0, NULL, NULL, NULL, &t, sigmask); + } [outerpool release]; outerpool = [[NSAutoreleasePool alloc] init]; @@ -4430,6 +4436,18 @@ in certain situations (rapid incoming events). return result; } +#ifdef HAVE_PTHREAD +void +ns_run_loop_break () +/* Break out of the NS run loop in ns_select or ns_read_socket. */ +{ + NSTRACE_WHEN (NSTRACE_GROUP_EVENTS, "ns_run_loop_break"); + + /* If we don't have a GUI, don't send the event. */ + if (NSApp != NULL) + ns_send_appdefined(-1); +} +#endif /* ========================================================================== diff --git a/src/process.c b/src/process.c index 2a1c2eecde..abd017bb90 100644 --- a/src/process.c +++ b/src/process.c @@ -5371,14 +5371,13 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd, nfds = xg_select (max_desc + 1, &Available, (check_write ? &Writeok : 0), NULL, &timeout, NULL); +#elif defined HAVE_NS + /* And NS builds call thread_select in ns_select. */ + nfds = ns_select (max_desc + 1, + &Available, (check_write ? &Writeok : 0), + NULL, &timeout, NULL); #else /* !HAVE_GLIB */ - nfds = thread_select ( -# ifdef HAVE_NS - ns_select -# else - pselect -# endif - , max_desc + 1, + nfds = thread_select (pselect, max_desc + 1, &Available, (check_write ? &Writeok : 0), NULL, &timeout, NULL); diff --git a/src/systhread.c b/src/systhread.c index a84060c18f..aee12a9b48 100644 --- a/src/systhread.c +++ b/src/systhread.c @@ -20,6 +20,10 @@ along with GNU Emacs. If not, see . */ #include #include "lisp.h" +#ifdef HAVE_NS +#include "nsterm.h" +#endif + #ifndef THREADS_ENABLED void @@ -130,6 +134,13 @@ void sys_cond_broadcast (sys_cond_t *cond) { pthread_cond_broadcast (cond); +#ifdef HAVE_NS + /* Send an app defined event to break out of the NS run loop. + It seems that if ns_select is running the NS run loop, this + broadcast has no effect until the loop is done, breaking a couple + of tests in thread-tests.el. */ + ns_run_loop_break (); +#endif } void -- 2.12.0 --d6Gm4EdcadzBjdND-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 19 14:34:06 2017 Received: (at 25265) by debbugs.gnu.org; 19 Jun 2017 18:34:07 +0000 Received: from localhost ([127.0.0.1]:56509 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dN1V0-0007Mz-Nl for submit@debbugs.gnu.org; Mon, 19 Jun 2017 14:34:06 -0400 Received: from sinyavsky.aurox.ch ([37.35.109.145]:45182) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dN1Uz-0007MV-2W for 25265@debbugs.gnu.org; Mon, 19 Jun 2017 14:34:05 -0400 Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) by sinyavsky.aurox.ch (Postfix) with ESMTP id C54BF2247E for <25265@debbugs.gnu.org>; Mon, 19 Jun 2017 18:29:08 +0000 (UTC) Authentication-Results: sinyavsky.aurox.ch (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=aurox.ch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aurox.ch; h= content-transfer-encoding:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:to:subject:subject; s=dkim; t=1497896947; x= 1498760948; bh=bUBchvcgptJWdymqMFqT2o1SH1MvCSl40npvYJ7Lw44=; b=S o588k44dIKp4lvQLyEuXif4DbBw+ASXtSKBa+87XyydVfS5c8yk/w8bjBEcDCZDq mJPnXac+Flqi58suJajgFYDPcE8+7eZ4hBSofU70AVGROPhfKjZwjJVvuPNRnh97 CFfOFIdkiEdsmLa3nhPSNxwsvaG1+sXaCgBTkxrwPg= X-Virus-Scanned: Debian amavisd-new at test.virtualizor.com Received: from sinyavsky.aurox.ch ([127.0.0.1]) by sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id u-sG_FR9xAuw for <25265@debbugs.gnu.org>; Mon, 19 Jun 2017 18:29:07 +0000 (UTC) Received: from [192.168.1.121] (125.85.192.178.dynamic.wline.res.cust.swisscom.ch [178.192.85.125]) by sinyavsky.aurox.ch (Postfix) with ESMTPSA id E487122457; Mon, 19 Jun 2017 18:29:04 +0000 (UTC) Subject: Re: bug#25265: make-thread crashes in OS X 10.6 To: Alan Third References: <20170502204935.GA79100@breton.holly.idiocy.org> <20170613204643.GA98084@breton.holly.idiocy.org> <20170615190432.GA12317@breton.holly.idiocy.org> <20170616194531.GA27453@breton.holly.idiocy.org> <20170616205139.GA27574@breton.holly.idiocy.org> <20170618140118.GA33083@breton.holly.idiocy.org> From: "Charles A. Roelli" Message-ID: Date: Mon, 19 Jun 2017 20:34:00 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170618140118.GA33083@breton.holly.idiocy.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 25265 Cc: 25265@debbugs.gnu.org, Noam Postavsky 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.7 (/) On 18/06/2017 16:01, Alan Third wrote: > On Sun, Jun 18, 2017 at 03:05:04PM +0200, Charles A. Roelli wrote: >> The tests sometimes all pass with the updated patch, but then I got >> this once (the errors you've seen previously, I think): >> > > > Yeah, they look the same. I’m not sure what I can do to fix them if > they’re still happening. Wish I could help here. Thanks for getting this far! > >> I also tried this way of running the tests in batch mode: >> >> cd test && rm -rf src/thread-tests.log && make src/thread-tests.log >> >> but got a segfault: >> >> GEN src/thread-tests.log >> /bin/sh: line 1: 87214 Segmentation fault HOME=/nonexistent >> EMACSLOADPATH= LC_ALL=C >> EMACS_TEST_DIRECTORY=/Volumes/Toblerone/Code/emacs-devel/test "../src/emacs" >> -batch --no-site-file --no-site-lisp -L ":." -l ert -l src/thread-tests.el >> --eval "(ert-run-tests-batch-and-exit nil)" > src/thread-tests.log 2>&1 >> Running 28 tests (2017-06-18 15:00:03+0200) >> make: *** [src/thread-tests.log] Error 139 >> >> I'm not sure where the problem is happening (or if it's specific to >> NS). The file 'src/thread-tests.log' also doesn't give any extra >> information (besides 'Running 28 tests (2017-06-18 15:00:03+0200)'). > Yeah, I think that’s because I, accidentally, have the non‐GUI version > trying to run some GUI stuff. I noticed this myself yesterday. > > Running NS Emacs without a GUI has always worked with threads because > it just bypasses the NS run loop which is the problem. > > I’ve attached a new patch that actually checks whether we’re running > the NS GUI. Thanks, the new patch fixes the issue. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 01 08:04:41 2017 Received: (at 25265) by debbugs.gnu.org; 1 Jul 2017 12:04:41 +0000 Received: from localhost ([127.0.0.1]:46969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dRH8j-00075B-CC for submit@debbugs.gnu.org; Sat, 01 Jul 2017 08:04:41 -0400 Received: from mail-wr0-f169.google.com ([209.85.128.169]:33882) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dRH8h-00074y-Se for 25265@debbugs.gnu.org; Sat, 01 Jul 2017 08:04:40 -0400 Received: by mail-wr0-f169.google.com with SMTP id 77so214879892wrb.1 for <25265@debbugs.gnu.org>; Sat, 01 Jul 2017 05:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=gtK4TdY0PNOR4gPyI05rhYvRoMQFKtWS/yVCpVIU5/k=; b=otu8vZSJkSHvFLXQ0rw9hME49NKvHzqxjVjrAKBgHlX2tZveUAkdYwrkmi6q/9OJvS z+L5XNvoIKFCRDMymdYDnAspcEV8tfxX49VvQhSY9wRksVIclFATv/jBprzF9gKTW/Wd 1BEgJeMdK/M7T7vrgRw2Yee8DuAmZQ4405oZXQPr4HmrL7lvEKRNI487OGWN0AQhTMCN smos0cm69MwYK2sYW2nRNEBBDxtTF2/YTdnsJb+nHDk5H1yl9fqzm/T+3JEcyIfxAv8u Z1UiLPiUA5GEB15RD/eZn4rJe5COUisKIZ2uTe8W9vZVASX2Taa/0fi56fthw83oXsvd 52iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=gtK4TdY0PNOR4gPyI05rhYvRoMQFKtWS/yVCpVIU5/k=; b=jGuoQo6j7Izr6avNV0ol/DM3woHp/nDMN5uaUUWZRfWAtQm4Nq5uAz9sFXFEsDoXKy bY11WTSf1KtUeN4lrgybGGZbSssL/0ZVt1GzEm7Q1I6k0CE608HiHH8nws6HIu2gLzqH sRjSXNbKNwXdrNDfQ4b6fs9xnzad9YWmf4yJMg1Qj0GWiDIgkUHOceh7HtTH4EZ6DvyT cvDhbzVk1LybR8HRI9LdKgZVgZ5EhAOvGMSPcS9UPGduR21wTJdcH85sKPI7MkWvmhcn ldNWwaqhUUE+7I38TDzhUOnAMcuS/BVdvlJTxoj6R3Vm+qMETWktM0+jk3K2knWbylSn C3RQ== X-Gm-Message-State: AKS2vOyxX/MF+fY3FqmKW7hPRpwpbjqyNg/8iXdUJb2BOULT2d0d/uGk zEG0DQqWl0qcwA== X-Received: by 10.223.146.161 with SMTP id 30mr31850656wrn.164.1498910674234; Sat, 01 Jul 2017 05:04:34 -0700 (PDT) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-5589-829d-0648-e40b.holly.idiocy.org. [2001:8b0:3f8:8129:5589:829d:648:e40b]) by smtp.gmail.com with ESMTPSA id h16sm25036219wma.14.2017.07.01.05.04.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Jul 2017 05:04:33 -0700 (PDT) Date: Sat, 1 Jul 2017 13:04:31 +0100 From: Alan Third To: "Charles A. Roelli" Subject: Re: bug#25265: make-thread crashes in OS X 10.6 Message-ID: <20170701120431.GA17227@breton.holly.idiocy.org> References: <20170613204643.GA98084@breton.holly.idiocy.org> <20170615190432.GA12317@breton.holly.idiocy.org> <20170616194531.GA27453@breton.holly.idiocy.org> <20170616205139.GA27574@breton.holly.idiocy.org> <20170618140118.GA33083@breton.holly.idiocy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 25265 Cc: 25265@debbugs.gnu.org, Noam Postavsky 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.6 (--) On Mon, Jun 19, 2017 at 08:34:00PM +0200, Charles A. Roelli wrote: > On 18/06/2017 16:01, Alan Third wrote: > > > > I’ve attached a new patch that actually checks whether we’re running > > the NS GUI. > > Thanks, the new patch fixes the issue. I’ve pushed this patch up to master. Even if it’s still throwing up errors in the thread tests occasionally, it’s far better than just crashing. Should we close this bug report, or would you rather leave it open until we can be sure it’s all working fine? -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 04 02:59:52 2017 Received: (at 25265) by debbugs.gnu.org; 4 Jul 2017 06:59:52 +0000 Received: from localhost ([127.0.0.1]:51134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dSHoO-0000FW-Ik for submit@debbugs.gnu.org; Tue, 04 Jul 2017 02:59:52 -0400 Received: from sinyavsky.aurox.ch ([37.35.109.145]:57857) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dSHoN-0000FI-4m for 25265@debbugs.gnu.org; Tue, 04 Jul 2017 02:59:51 -0400 Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) by sinyavsky.aurox.ch (Postfix) with ESMTP id 13FDB2249D for <25265@debbugs.gnu.org>; Tue, 4 Jul 2017 06:54:38 +0000 (UTC) Authentication-Results: sinyavsky.aurox.ch (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=aurox.ch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aurox.ch; h=to :references:message-id:content-transfer-encoding:date:date :in-reply-to:x-mailer:from:from:subject:subject:mime-version :content-type:content-type; s=dkim; t=1499151276; x=1500015277; bh=aMCquz3kAU9mWdkzwI4WZYp9uhw9SO2BtBXruaj7hEs=; b=dM9aESGEZ0Y4 /T87ahdzjLELYUwWeR6XvRORRAaTZviVSXiOYhYwRvPdqLUJZR6ZeZh8J+S+v6Yj NrRVJjIijOPiYnfRM5laP3+TGOKB9FnewEDTFLtmDlct+pks9aLXkO3AR9P9/Z84 ySBUiEYNpPVIcMal0NBL16PmrTFrV9M= X-Virus-Scanned: Debian amavisd-new at test.virtualizor.com Received: from sinyavsky.aurox.ch ([127.0.0.1]) by sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3pS6QC1D0xct for <25265@debbugs.gnu.org>; Tue, 4 Jul 2017 06:54:36 +0000 (UTC) Received: from [10.118.164.76] (180.236.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch [178.197.236.180]) by sinyavsky.aurox.ch (Postfix) with ESMTPSA id 8BAFF2247A; Tue, 4 Jul 2017 06:54:36 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: bug#25265: make-thread crashes in OS X 10.6 From: "Charles A. Roelli" X-Mailer: iPhone Mail (14F89) In-Reply-To: <20170701120431.GA17227@breton.holly.idiocy.org> Date: Tue, 4 Jul 2017 08:59:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <484AC29D-71B4-43A7-B7D4-9D0797B41C03@aurox.ch> References: <20170613204643.GA98084@breton.holly.idiocy.org> <20170615190432.GA12317@breton.holly.idiocy.org> <20170616194531.GA27453@breton.holly.idiocy.org> <20170616205139.GA27574@breton.holly.idiocy.org> <20170618140118.GA33083@breton.holly.idiocy.org> <20170701120431.GA17227@breton.holly.idiocy.org> To: Alan Third X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 25265 Cc: 25265@debbugs.gnu.org, Noam Postavsky 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.7 (/) Up to you. Thank you for pushing the fix. > On 1 Jul 2017, at 14:04, Alan Third wrote: >=20 >> On Mon, Jun 19, 2017 at 08:34:00PM +0200, Charles A. Roelli wrote: >>> On 18/06/2017 16:01, Alan Third wrote: >>>=20 >>> I=E2=80=99ve attached a new patch that actually checks whether we=E2=80=99= re running >>> the NS GUI. >>=20 >> Thanks, the new patch fixes the issue. >=20 > I=E2=80=99ve pushed this patch up to master. Even if it=E2=80=99s still th= rowing up > errors in the thread tests occasionally, it=E2=80=99s far better than just= > crashing. >=20 > Should we close this bug report, or would you rather leave it open > until we can be sure it=E2=80=99s all working fine? > --=20 > Alan Third From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 04 08:03:30 2017 Received: (at 25265) by debbugs.gnu.org; 4 Jul 2017 12:03:30 +0000 Received: from localhost ([127.0.0.1]:51236 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dSMYE-0000kq-Cd for submit@debbugs.gnu.org; Tue, 04 Jul 2017 08:03:30 -0400 Received: from mail-it0-f65.google.com ([209.85.214.65]:34963) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dSMYC-0000kc-Rg for 25265@debbugs.gnu.org; Tue, 04 Jul 2017 08:03:29 -0400 Received: by mail-it0-f65.google.com with SMTP id v193so11277033itc.2 for <25265@debbugs.gnu.org>; Tue, 04 Jul 2017 05:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=AKhityaNQJT7GlshtsXmIYXcB7awcjFgabu9R2Qyj3Y=; b=M45vserkK/lsnc1m1GZ7FGeU7sMb9lkW93vDQFkjg7m3955ElG3+OF+kWimZcwVuk+ altGTMVr7nz3GpobQtog5A23JOPrfBGimtwoizU7IuetdJtAQRvVc8VQu6DJz03PRGdB +RB6YmaX0ExltjDbJ79E1buhPhtoD8/n+npUUnsibCndYKBsHXyLJ9qWJwKliYXoPxgs Gc5cJVaoJEJMYcTF44GaOdBLVjYXzOl2K7PqZFyF3fMI4Q7jRZVA7SNse1LYfaGOR9Nj zewdzERk3CsBfXAY9PQgsHbSdwzS1tfK46IDAfw8Q/yC/4AoJZtesJv9OjXP/9DekFql D/zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version :content-transfer-encoding; bh=AKhityaNQJT7GlshtsXmIYXcB7awcjFgabu9R2Qyj3Y=; b=a6jgXhPm5yFkw2ms/c6u17SLHA02AngEkahAjMdiMsAqy29NbIjvGidTJKc30/uEsU 8MOZAabI5bFuibM/CubT7qO4n2CpziX7zzZS0AYaKMcvXmavhGL+Vbv/yHBFiD0mJsoF NU0Zvjv541M/IexcqxZdjprmAzVYyNE5Ec98tPYWZ9i3jGEYUSTvvbUWdZqpsmW+5t+r xVehh8h4t7N3PmefFUJBYl1Ze6w7aInCA+c6e0lUoNGgEPHcINmOUkbSfZxJxSX6QJQm AZOqoUPrEaKkC8qz70aURH7iwzUomP0zRjcT1CtsEo+gMYQ3UH6mL4rXKD7N6NkNUTKF mlhw== X-Gm-Message-State: AKS2vOwdv+kwd+mz6zMGHL15I6JK5Ux0iEUc+QtQouY/8yalUe5u4NRz JNHAShRERExy/6b4Bpc= X-Received: by 10.36.172.7 with SMTP id s7mr33456227ite.67.1499169802951; Tue, 04 Jul 2017 05:03:22 -0700 (PDT) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id z64sm10292295ioe.61.2017.07.04.05.03.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 04 Jul 2017 05:03:21 -0700 (PDT) From: npostavs@users.sourceforge.net To: "Charles A. Roelli" Subject: Re: bug#25265: make-thread crashes in OS X 10.6 References: <20170613204643.GA98084@breton.holly.idiocy.org> <20170615190432.GA12317@breton.holly.idiocy.org> <20170616194531.GA27453@breton.holly.idiocy.org> <20170616205139.GA27574@breton.holly.idiocy.org> <20170618140118.GA33083@breton.holly.idiocy.org> <20170701120431.GA17227@breton.holly.idiocy.org> <484AC29D-71B4-43A7-B7D4-9D0797B41C03@aurox.ch> Date: Tue, 04 Jul 2017 08:04:56 -0400 In-Reply-To: <484AC29D-71B4-43A7-B7D4-9D0797B41C03@aurox.ch> (Charles A. Roelli's message of "Tue, 4 Jul 2017 08:59:36 +0200") Message-ID: <874lusif13.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 25265 Cc: Alan Third , 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) > >> On 1 Jul 2017, at 14:04, Alan Third wrote: >>=20 >> Should we close this bug report, or would you rather leave it open >> until we can be sure it=E2=80=99s all working fine? I would suggest closing this bug and opening a new one for the test failure, keeps things more readable and searchable. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 05 15:38:54 2017 Received: (at control) by debbugs.gnu.org; 5 Jul 2017 19:38:54 +0000 Received: from localhost ([127.0.0.1]:53730 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dSq8U-00020H-A8 for submit@debbugs.gnu.org; Wed, 05 Jul 2017 15:38:54 -0400 Received: from mail-wr0-f196.google.com ([209.85.128.196]:35062) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dSq8S-000204-CL for control@debbugs.gnu.org; Wed, 05 Jul 2017 15:38:52 -0400 Received: by mail-wr0-f196.google.com with SMTP id z45so51200761wrb.2 for ; Wed, 05 Jul 2017 12:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:message-id:to:from:subject; bh=pB/2RalH7zqZmCQVlWWdo8TkT4nCl8TX2iH/1NvkB3o=; b=jh4CTm6B9PGOleqDjx/BAkGbmuaIh/nPOWPbTdhFWFU++b2cedS2kOhyXmj4b1REYu eMnsvg3EuqsNHJ6ofQk59DE7vWGdyzVDKEAsTJqpnKU1Lg/XH2mUdhAWdp+PsyDMqnaZ aXHHHoIBvU061TT6pY+GUlHdqkOnmkJSYaTkMJMVnlE12v40MEMaHvr3vs3XDgV+cMxe qCeSOGGlyO52c8fAuAH5szXL5sdyHBFynnoJUFmB006eG+HmrU0KdxdHeYuUk+1BsJ/Z PY054rZokugLI6NubBaCgyfi+qzaXz+OUmXu6BYAorxtCBg/OjmYHq2UtdyT8/SSlCWI dG5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:message-id:to:from:subject; bh=pB/2RalH7zqZmCQVlWWdo8TkT4nCl8TX2iH/1NvkB3o=; b=d3a4GQ7grdixy1w4XkHUNzu3nL1GhpaX8Q6P2mmAjlWsWMWgeh3xVvkU8tIm5k00jr Q6wynE5jlfuIYK0Bv4EjPhj0kt8d+v/x9lbW+l/tx5iPRkFNYeM6r/4YNHWveV+w7W61 Y1bckhsBx0mmeJug7FigTaNIPzierhOfeJlcl4iHfZWZfoO55z6skoOAg2pF3cTGa8LK KjLKyAazYqtFEyjzqsKQFHawp+8hGcaXbcVhDKp2d07ziVpl0ZgQnI4ZOfigUDwh8rnN Is2f3//nQRpXTPWPDn2GQ/T3DB62S8eL7lbQSgdBtwyxr6m9oC2ukDAIlXV51vFKMvRx BN4g== X-Gm-Message-State: AKS2vOxmV8WcwVRL0GCkmnFnHiNnCfiWG8OEZTYRh8FLW0kGNOZ7Cfs9 bA0mC8S+HOWG+Ejqkis= X-Received: by 10.223.151.44 with SMTP id r41mr39200150wrb.6.1499283526454; Wed, 05 Jul 2017 12:38:46 -0700 (PDT) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-25fe-c0b7-06f1-a456.holly.idiocy.org. [2001:8b0:3f8:8129:25fe:c0b7:6f1:a456]) by smtp.gmail.com with ESMTPSA id q30sm20251017wrc.65.2017.07.05.12.38.45 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 05 Jul 2017 12:38:45 -0700 (PDT) Date: Wed, 05 Jul 2017 20:38:31 +0100 Message-Id: To: control@debbugs.gnu.org From: Alan Third Subject: control message for bug #25265 X-Spam-Score: -2.1 (--) 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: -2.1 (--) tags 25265 fixed close 25265 26.1 From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 06 05:25:50 2017 Received: (at 25265) by debbugs.gnu.org; 6 Jul 2017 09:25:50 +0000 Received: from localhost ([127.0.0.1]:54193 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dT32k-0004il-Bt for submit@debbugs.gnu.org; Thu, 06 Jul 2017 05:25:50 -0400 Received: from sinyavsky.aurox.ch ([37.35.109.145]:59244) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dT32i-0004iY-Fm for 25265@debbugs.gnu.org; Thu, 06 Jul 2017 05:25:49 -0400 Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) by sinyavsky.aurox.ch (Postfix) with ESMTP id 3523B224A2 for <25265@debbugs.gnu.org>; Thu, 6 Jul 2017 09:20:35 +0000 (UTC) Authentication-Results: sinyavsky.aurox.ch (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=aurox.ch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aurox.ch; h=to :references:message-id:content-transfer-encoding:date:date :in-reply-to:x-mailer:from:from:subject:subject:mime-version :content-type:content-type; s=dkim; t=1499332831; x=1500196832; bh=nEDYqqYAMVJ2fQi0czuaTJQlBgg95RtArRQXx3bmUBc=; b=uzLYV8j1Xrs/ UKZroTWUC12oAsbGeDnoAVIgQzvRKmMAnaC3n6MAFsdnRbBdWusnykPsY8y6YsCe 7eiGjNrjTSpbnupqYPD7xZZPlStYLUYIZTt7W0Qgw1JZUfLKyduZoZOw4cr0k9vU SBegeLaWrsH4YxUm+iYXuo6lN3Ume/w= X-Virus-Scanned: Debian amavisd-new at test.virtualizor.com Received: from sinyavsky.aurox.ch ([127.0.0.1]) by sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YMoMGGV1ydBS for <25265@debbugs.gnu.org>; Thu, 6 Jul 2017 09:20:31 +0000 (UTC) Received: from [10.232.228.243] (184.224.197.178.dynamic.wless.zhbmb00p-cgnat.res.cust.swisscom.ch [178.197.224.184]) by sinyavsky.aurox.ch (Postfix) with ESMTPSA id 3EC1F22492; Thu, 6 Jul 2017 09:20:31 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: bug#25265: make-thread crashes in OS X 10.6 From: "Charles A. Roelli" X-Mailer: iPhone Mail (14F89) In-Reply-To: <20170705193642.GA18888@breton.holly.idiocy.org> Date: Thu, 6 Jul 2017 11:25:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <35B6B799-B1D4-4764-9F45-9568831A1EF8@aurox.ch> References: <20170615190432.GA12317@breton.holly.idiocy.org> <20170616194531.GA27453@breton.holly.idiocy.org> <20170616205139.GA27574@breton.holly.idiocy.org> <20170618140118.GA33083@breton.holly.idiocy.org> <20170701120431.GA17227@breton.holly.idiocy.org> <484AC29D-71B4-43A7-B7D4-9D0797B41C03@aurox.ch> <874lusif13.fsf@users.sourceforge.net> <20170705193642.GA18888@breton.holly.idiocy.org> To: Alan Third X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 25265 Cc: 25265@debbugs.gnu.org, npostavs@users.sourceforge.net 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.7 (/) Sure, will get to it later today. > On 5 Jul 2017, at 21:36, Alan Third wrote: >=20 >> On Tue, Jul 04, 2017 at 08:04:56AM -0400, npostavs@users.sourceforge.net w= rote: >>>>=20 >>>> On 1 Jul 2017, at 14:04, Alan Third wrote: >>>>=20 >>>> Should we close this bug report, or would you rather leave it open >>>> until we can be sure it=E2=80=99s all working fine? >>=20 >> I would suggest closing this bug and opening a new one for the test >> failure, keeps things more readable and searchable. >=20 > Sounds sensible. >=20 > Charles, I can=E2=80=99t reproduce the errors, so if you=E2=80=99re still g= etting them > could you please raise a new bug report for them? >=20 > Thanks, all. > --=20 > Alan Third From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 06 13:10:56 2017 Received: (at 25265) by debbugs.gnu.org; 6 Jul 2017 17:10:56 +0000 Received: from localhost ([127.0.0.1]:55391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dTAIq-0000dw-KC for submit@debbugs.gnu.org; Thu, 06 Jul 2017 13:10:56 -0400 Received: from sinyavsky.aurox.ch ([37.35.109.145]:59567) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dTAIo-0000dg-Da for 25265@debbugs.gnu.org; Thu, 06 Jul 2017 13:10:55 -0400 Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) by sinyavsky.aurox.ch (Postfix) with ESMTP id 941C8224A2 for <25265@debbugs.gnu.org>; Thu, 6 Jul 2017 17:05:42 +0000 (UTC) Authentication-Results: sinyavsky.aurox.ch (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=aurox.ch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aurox.ch; h= content-transfer-encoding:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:to:subject:subject; s=dkim; t=1499360741; x= 1500224742; bh=43GwnMPzDnc7q3cu6NBRxtd/8mG4xGPhriCvSSHo+GE=; b=Z 3sKjcIBN/DhVZ0549jUvIIG9VCb6i9aZTogLNV4Q8jae7lZdAk27JC7bNmVTSVoa NPaVAAZx1UCXv9lYLmjOGqkVz5KvABh5U7GF0hmTFL/qZBt4QLOP65l8AwUSDWaw yb4O9gnoPISEZgDHrWQPNk0CDc+Kwqg8icf7LaudYs= X-Virus-Scanned: Debian amavisd-new at test.virtualizor.com Received: from sinyavsky.aurox.ch ([127.0.0.1]) by sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qffBITRMkIiu for <25265@debbugs.gnu.org>; Thu, 6 Jul 2017 17:05:41 +0000 (UTC) Received: from [192.168.1.120] (125.85.192.178.dynamic.wline.res.cust.swisscom.ch [178.192.85.125]) by sinyavsky.aurox.ch (Postfix) with ESMTPSA id CC83A22443; Thu, 6 Jul 2017 17:05:40 +0000 (UTC) Subject: Re: bug#25265: make-thread crashes in OS X 10.6 To: Alan Third , npostavs@users.sourceforge.net References: <20170615190432.GA12317@breton.holly.idiocy.org> <20170616194531.GA27453@breton.holly.idiocy.org> <20170616205139.GA27574@breton.holly.idiocy.org> <20170618140118.GA33083@breton.holly.idiocy.org> <20170701120431.GA17227@breton.holly.idiocy.org> <484AC29D-71B4-43A7-B7D4-9D0797B41C03@aurox.ch> <874lusif13.fsf@users.sourceforge.net> <20170705193642.GA18888@breton.holly.idiocy.org> From: "Charles A. Roelli" Message-ID: Date: Thu, 6 Jul 2017 19:10:46 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170705193642.GA18888@breton.holly.idiocy.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 25265 Cc: 25265@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) I've just made a new report (bug #27598) for thread-signal-early. I wasn't able to reproduce the other issue this time around. On 05/07/2017 21:36, Alan Third wrote: > On Tue, Jul 04, 2017 at 08:04:56AM -0400, npostavs@users.sourceforge.net wrote: >>>> On 1 Jul 2017, at 14:04, Alan Third wrote: >>>> >>>> Should we close this bug report, or would you rather leave it open >>>> until we can be sure it’s all working fine? >> I would suggest closing this bug and opening a new one for the test >> failure, keeps things more readable and searchable. > Sounds sensible. > > Charles, I can’t reproduce the errors, so if you’re still getting them > could you please raise a new bug report for them? > > Thanks, all. From unknown Sat Jun 21 12:12:32 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 04 Aug 2017 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator