From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#25247: 26.0.50; Concurrency crashes Date: Thu, 22 Dec 2016 19:28:48 +0200 Message-ID: <83a8bn27qn.fsf@gnu.org> References: <87bmw4w9i2.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1482427823 4054 195.159.176.226 (22 Dec 2016 17:30:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 22 Dec 2016 17:30:23 +0000 (UTC) Cc: 25247@debbugs.gnu.org To: Tino Calancha , Ken Raeburn Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 22 18:30:16 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cK7C3-0008Nh-07 for geb-bug-gnu-emacs@m.gmane.org; Thu, 22 Dec 2016 18:30:15 +0100 Original-Received: from localhost ([::1]:35421 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cK7C7-0001q5-7h for geb-bug-gnu-emacs@m.gmane.org; Thu, 22 Dec 2016 12:30:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cK7Bw-0001mi-UZ for bug-gnu-emacs@gnu.org; Thu, 22 Dec 2016 12:30:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cK7Bq-0003r1-Sr for bug-gnu-emacs@gnu.org; Thu, 22 Dec 2016 12:30:09 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36408) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cK7Bq-0003qm-PC for bug-gnu-emacs@gnu.org; Thu, 22 Dec 2016 12:30:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cK7Bq-0001zZ-Gq for bug-gnu-emacs@gnu.org; Thu, 22 Dec 2016 12:30:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 22 Dec 2016 17:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25247 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25247-submit@debbugs.gnu.org id=B25247.14824277677584 (code B ref 25247); Thu, 22 Dec 2016 17:30:02 +0000 Original-Received: (at 25247) by debbugs.gnu.org; 22 Dec 2016 17:29:27 +0000 Original-Received: from localhost ([127.0.0.1]:51807 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cK7BH-0001yG-9C for submit@debbugs.gnu.org; Thu, 22 Dec 2016 12:29:27 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:53123) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cK7BC-0001y0-I3 for 25247@debbugs.gnu.org; Thu, 22 Dec 2016 12:29:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cK7B4-0003Ek-3m for 25247@debbugs.gnu.org; Thu, 22 Dec 2016 12:29:17 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38570) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cK7B4-0003Ea-1D; Thu, 22 Dec 2016 12:29:14 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1127 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cK7B3-0000pL-8a; Thu, 22 Dec 2016 12:29:13 -0500 In-reply-to: <87bmw4w9i2.fsf@gmail.com> (message from Tino Calancha on Thu, 22 Dec 2016 19:20:21 +0900) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:127332 Archived-At: > From: Tino Calancha > Date: Thu, 22 Dec 2016 19:20:21 +0900 > > > 1) > Save a file /tmp/test.el with contains: > > (defun mytest () > (dotimes (n 10) > (message "[%d] Sleeping ..." n) > (sleep-for 0.5)) > (message "End!") > (sleep-for 1) > (message nil)) > > (defun run-test () > (dotimes (_ 50) > (make-thread #'mytest)) > (message "Number of threads %d" (length (all-threads)))) > > ;; (run-test) > > 2) > emacs -Q -l /tmp/test.el > ;; Evaluate (run-test) in buffer *scratch*; keep using Emacs, for instance, > ;; split the window, and visit other buffers, or call (run-test) again: > C-x 3 > C-x C-b > C-o RET > ;; Sometimes Emacs crash or hangs. Thanks. It doesn't crash or hang here. Which is not surprising, since the backtraces seem to indicate some issue with X11/xcb and threads. Ken, could you take a look, please? Are we violating some X11 protocols by calling redisplay from different threads? > Following is the backtrace: > > (gdb) bt When reporting backtraces with threads, please always show the backtrace of all the threads in the process. Like this: (gdb) thread apply all bt > #12 0x000000000058f781 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:379 > #13 0x00000000006278aa in die (msg=0x76d3a8 "((uintptr_t) start) % GC_POINTER_ALIGNMENT == 0", file=0x76cb30 "alloc.c", line=4893) at alloc.c:7315 > #14 0x0000000000622c81 in mark_memory (start=0x7fffbda63b17, end=0x7fffbda63b17) at alloc.c:4893 > #15 0x0000000000622cdb in mark_stack (bottom=0x7fffbda63b17 "", end=0x7fffbda63b17 "") at alloc.c:5058 > #16 0x00000000006e02f1 in mark_one_thread (thread=0x161bd60 ) at thread.c:558 Looks like the byte stack is unaligned. In run_thread I see this: static void * run_thread (void *state) { char stack_pos; struct thread_state *self = state; struct thread_state **iter; self->m_stack_bottom = &stack_pos; self->stack_top = &stack_pos; which AFAIU could very well produce unaligned pointers. Does the patch below prevent this crash? > (gdb) bt > #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58 > #1 0x00007fffefa9940a in __GI_abort () at abort.c:89 > #2 0x00007fffefa90e47 in __assert_fail_base (fmt=, assertion=assertion@entry=0x7ffff493fc00 "!xcb_xlib_threads_sequence_lost", file=file@entry=0x7ffff493fa6b "../../src/xcb_io.c", line=line@entry=259, function=function@entry=0x7ffff493fea8 "poll_for_event") at assert.c:92 > #3 0x00007fffefa90ef2 in __GI___assert_fail (assertion=0x7ffff493fc00 "!xcb_xlib_threads_sequence_lost", file=0x7ffff493fa6b "../../src/xcb_io.c", line=259, function=0x7ffff493fea8 "poll_for_event") at assert.c:101 > #4 0x00007ffff48cd77a in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6 > #5 0x00007ffff48cd82b in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6 > #6 0x00007ffff48cdb1d in _XEventsQueued () from /usr/lib/x86_64-linux-gnu/libX11.so.6 > #7 0x00007ffff48af58a in XFlush () from /usr/lib/x86_64-linux-gnu/libX11.so.6 > #8 0x0000000000541ff2 in x_flush (f=0x145ac30 ) at xterm.c:257 > #9 0x0000000000543111 in x_flip_and_flush (f=0x145ac30 ) at xterm.c:1217 > #10 0x000000000058e269 in flush_frame (f=0x145ac30 ) at frame.h:1481 > #11 0x0000000000467d3a in echo_area_display (update_frame_p=true) at xdisp.c:11435 > #12 0x0000000000464e43 in message3_nolog (m=...) at xdisp.c:10413 > #13 0x0000000000464af1 in message3 (m=...) at xdisp.c:10342 > #14 0x000000000063e868 in Fmessage (nargs=2, args=0x7fff3b015360) at editfns.c:3767 If you remove the calls to 'message' from the thread function, do these problems go away? > #2 0x00000000005bddd9 in emacs_abort () at sysdep.c:2364 > #3 0x00000000005a3903 in unblock_input_to (level=-1) at keyboard.c:7170 > #4 0x00000000005a391a in unblock_input () at keyboard.c:7186 Somehow more than one thread called block_input/unblock_input, sigh... Here's the patch to try: diff --git a/src/thread.c b/src/thread.c index 6966df3..fcb7f69 100644 --- a/src/thread.c +++ b/src/thread.c @@ -644,12 +644,16 @@ do_nothing (Lisp_Object whatever) static void * run_thread (void *state) { - char stack_pos; + union + { + void *p; + char c; + } stack_pos; struct thread_state *self = state; struct thread_state **iter; - self->m_stack_bottom = &stack_pos; - self->stack_top = &stack_pos; + self->m_stack_bottom = (char *)&stack_pos; + self->stack_top = (char *)&stack_pos; self->thread_id = sys_thread_self (); acquire_global_lock (self);