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: Fri, 23 Dec 2016 16:14:28 +0200 Message-ID: <83mvfmzq9n.fsf@gnu.org> References: <87bmw4w9i2.fsf@gmail.com> <83a8bn27qn.fsf@gnu.org> <87h95vmi7b.fsf@gmail.com> <83wperyrgj.fsf@gnu.org> <878tr651a9.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1482502518 19286 195.159.176.226 (23 Dec 2016 14:15:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 23 Dec 2016 14:15:18 +0000 (UTC) Cc: raeburn@raeburn.org, 25247@debbugs.gnu.org To: Tino Calancha Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 23 15:15:11 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 1cKQcj-0003QK-Hw for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Dec 2016 15:15:05 +0100 Original-Received: from localhost ([::1]:39391 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cKQco-0008BE-7M for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Dec 2016 09:15:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52172) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cKQci-0008A6-0U for bug-gnu-emacs@gnu.org; Fri, 23 Dec 2016 09:15:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cKQcg-0004dI-Q4 for bug-gnu-emacs@gnu.org; Fri, 23 Dec 2016 09:15:04 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36761) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cKQcg-0004dD-Lx for bug-gnu-emacs@gnu.org; Fri, 23 Dec 2016 09:15:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cKQcg-0007s8-GG for bug-gnu-emacs@gnu.org; Fri, 23 Dec 2016 09:15: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: Fri, 23 Dec 2016 14:15: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.148250250130249 (code B ref 25247); Fri, 23 Dec 2016 14:15:02 +0000 Original-Received: (at 25247) by debbugs.gnu.org; 23 Dec 2016 14:15:01 +0000 Original-Received: from localhost ([127.0.0.1]:52160 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cKQcf-0007rg-4v for submit@debbugs.gnu.org; Fri, 23 Dec 2016 09:15:01 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:32924) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cKQcd-0007rT-MG for 25247@debbugs.gnu.org; Fri, 23 Dec 2016 09:14:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cKQcV-0004Z8-Dp for 25247@debbugs.gnu.org; Fri, 23 Dec 2016 09:14:54 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33599) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cKQcV-0004Z4-9t; Fri, 23 Dec 2016 09:14:51 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2010 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cKQcU-0005y4-H1; Fri, 23 Dec 2016 09:14:50 -0500 In-reply-to: <878tr651a9.fsf@gmail.com> (message from Tino Calancha on Fri, 23 Dec 2016 20:32:14 +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:127368 Archived-At: > From: Tino Calancha > Cc: raeburn@raeburn.org, Tino Calancha , 25247@debbugs.gnu.org > Date: Fri, 23 Dec 2016 20:32:14 +0900 > > Eli Zaretskii writes: > > I run > run -r -Q -l /tmp/test.el > with /tmp/test.el: > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > (defun mytest () > (dotimes (n 10) > (sleep-for 0.5))) > > (defun run-test () > (dotimes (_ 50) > (make-thread #'mytest))) > > (run-test) > > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > Then i splitted windows, called a few times > (run-test) > and visited *Buffer List* before getting a crash. > > the threads showing "really_call_select" in their backtraces are > 1, and 155-204 (inclusive); all but thread 158 have > context_acquired = false > The thread 158 is the one rising the exception, and it has > context_acquired = true. Thanks, this means that code in xgselect.c is doing its job well. If you ever again succeed in reproducing the abort in unblock_input_to, due to level being negative, please do the same sequence of GDB commands, and see if context_acquired is true in more than one thread. > Thread 158 (Thread 0x7fff343f9700 (LWP 29195)): > #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 0x00007ffff48bf7e7 in XPending () from /usr/lib/x86_64-linux-gnu/libX11.so.6 > #8 0x00007ffff6712cee in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 > #9 0x00007ffff5039edd in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #10 0x00007ffff503a91b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #11 0x00007ffff503aab7 in g_main_context_pending () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #12 0x000000000070fff0 in xg_select (fds_lim=14, rfds=0x7fff343f8170, wfds=0x7fff343f80f0, efds=0x0, timeout=0x7fff343f80d0, sigmask=0x0) at xgselect.c:160 > #13 0x00000000006e031a in really_call_select (arg=0x7fff343f7e70) at thread.c:520 This seems to say that we somehow still call X from more than one thread. I don't understand how this could happen, since sleep-for doesn't enter redisplay, at least AFAIK. Could it be that g_main_context_default or g_main_context_acquire or pselect itself calls X via some GTK hook? Hmm... Tino, is it possible for you to try this again, but this time with Emacs in X synchronous mode? The file etc/DEBUG describes 2 ways of doing that under "If you encounter X protocol errors". Maybe this way we will get the X error in a different place, which will give a hint about what's going on. Failing that, I hope the changes that Ken is testing will fix this. Thanks for collecting and posting all this data, Tino.