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#30364: 26.0.91; thread crash on macos Date: Sat, 17 Feb 2018 20:55:54 +0200 Message-ID: <83inavbg3p.fsf@gnu.org> References: <87bmgs9y8y.fsf@users.sourceforge.net> <871shj7k0n.fsf@gmail.com> <83k1vbbhvv.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1518895730 29221 195.159.176.226 (17 Feb 2018 19:28:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 17 Feb 2018 19:28:50 +0000 (UTC) Cc: 30364@debbugs.gnu.org, npostavs@gmail.com, npostavs@users.sourceforge.net To: Aaron Jensen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 17 20:28:45 2018 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 1en8A1-0006mX-3V for geb-bug-gnu-emacs@m.gmane.org; Sat, 17 Feb 2018 20:28:37 +0100 Original-Received: from localhost ([::1]:51136 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1en8C2-0001LV-DT for geb-bug-gnu-emacs@m.gmane.org; Sat, 17 Feb 2018 14:30:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47281) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1en7fW-00032Q-0S for bug-gnu-emacs@gnu.org; Sat, 17 Feb 2018 13:57:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1en7fS-00016w-4z for bug-gnu-emacs@gnu.org; Sat, 17 Feb 2018 13:57:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40717) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1en7fS-00016n-16 for bug-gnu-emacs@gnu.org; Sat, 17 Feb 2018 13:57:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1en7fR-0003Wf-RQ for bug-gnu-emacs@gnu.org; Sat, 17 Feb 2018 13:57:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Feb 2018 18:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30364 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30364-submit@debbugs.gnu.org id=B30364.151889376813476 (code B ref 30364); Sat, 17 Feb 2018 18:57:01 +0000 Original-Received: (at 30364) by debbugs.gnu.org; 17 Feb 2018 18:56:08 +0000 Original-Received: from localhost ([127.0.0.1]:48611 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1en7ea-0003VI-5A for submit@debbugs.gnu.org; Sat, 17 Feb 2018 13:56:08 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:56018) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1en7eY-0003UY-R5 for 30364@debbugs.gnu.org; Sat, 17 Feb 2018 13:56:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1en7eS-0000lM-RQ for 30364@debbugs.gnu.org; Sat, 17 Feb 2018 13:56:01 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56986) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1en7eN-0000jF-Fc; Sat, 17 Feb 2018 13:55:55 -0500 Original-Received: from [176.228.60.248] (port=4404 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1en7eM-00034x-S6; Sat, 17 Feb 2018 13:55:55 -0500 In-reply-to: (message from Aaron Jensen on Sat, 17 Feb 2018 10:40:10 -0800) 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:143399 Archived-At: > From: Aaron Jensen > Date: Sat, 17 Feb 2018 10:40:10 -0800 > Cc: Noam Postavsky , 30364@debbugs.gnu.org, > Noam Postavsky > > On Sat, Feb 17, 2018 at 10:17 AM, Eli Zaretskii wrote: > > When this crashes, is one of the threads you launched always doing GC, > > like in the first backtrace you've shown? > > I can tell this by the mark_object/mark_vectorlike calls in the stack, > right? Yes. > Ultimately, I was trying to port company-dabbrev to use threads. I > noticed the crash while working on it, so the 100 threads at the same > time was just a way of more consistently reproducing it. I could > probably have run the 100 threads serially to reproduce it, I don't > know. They do run serially, the way you wrote the code. The call to make-thread creates the thread, but the thread doesn't run, it waits for the currently-running thread to release the global lock. Normally, I'd expect the first of the 100 threads to start running almost immediately, because you don't do anything in the main thread. But the other 99 will wait. Whether some of them will start running before the first one exits, depends on the code of the thread function, and you didn't show all of it: I understand that the bulk is in company-mode. > I don't know what this is, but I do know that there are > (input-pending-p)'s in the thread from the current implementation. Where are they? I don't see those input-pending-p calls in the code on the page to which you referred. > They don't need to be there (i guess they'd be replaced by > thread-yields, but when I did that it got very slow). I don't have > time to test if removing those fixes the crashes just yet, but could > that be causing the crash? The thread also calls `message`, I don't > know if that's considered "UI stuff" If we are to believe to the backtrace, the thread that crashed was the main thread, and it crashed inside pthread_mutex_lock. Which probably means some snafu with pthreads synchronization functions. But the NS port has some complicated architecture wrt threads, so maybe that's why it crashes.