From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation Date: Fri, 12 Jul 2019 14:34:44 +0000 Message-ID: References: <87muhks3b5.fsf@hochschule-trier.de> <83k1cn2z0l.fsf@gnu.org> <83ftnb2wf9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="23243"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 12 16:38:11 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hlwgd-0005rs-He for geb-bug-gnu-emacs@m.gmane.org; Fri, 12 Jul 2019 16:38:11 +0200 Original-Received: from localhost ([::1]:50138 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hlwfa-0005tc-RQ for geb-bug-gnu-emacs@m.gmane.org; Fri, 12 Jul 2019 10:37:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46103) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hlwea-0001rv-6l for bug-gnu-emacs@gnu.org; Fri, 12 Jul 2019 10:36:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hlweY-0004Kp-1F for bug-gnu-emacs@gnu.org; Fri, 12 Jul 2019 10:36:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59888) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hlweX-0004Kj-Ts for bug-gnu-emacs@gnu.org; Fri, 12 Jul 2019 10:36:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hlweX-0007yf-Pq for bug-gnu-emacs@gnu.org; Fri, 12 Jul 2019 10:36:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2019 14:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36609 X-GNU-PR-Package: emacs Original-Received: via spool by 36609-submit@debbugs.gnu.org id=B36609.156294213030621 (code B ref 36609); Fri, 12 Jul 2019 14:36:01 +0000 Original-Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 14:35:30 +0000 Original-Received: from localhost ([127.0.0.1]:40476 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlwe1-0007xn-V9 for submit@debbugs.gnu.org; Fri, 12 Jul 2019 10:35:30 -0400 Original-Received: from mail-ot1-f51.google.com ([209.85.210.51]:42309) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlwdz-0007xY-8a for 36609@debbugs.gnu.org; Fri, 12 Jul 2019 10:35:27 -0400 Original-Received: by mail-ot1-f51.google.com with SMTP id l15so9647102otn.9 for <36609@debbugs.gnu.org>; Fri, 12 Jul 2019 07:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vC7KUbM0gjp7ohOiPN9gTjhRmBe1pLu3XUX6aTs6Jk0=; b=sYd+FSiSxpGkd1XTXtMU9tHu7aDTxxu0DMacHkFy9iwgZ1PhPVWLp+VXXbmMrP67V6 61IqhaaJy6TueVypLFjHPLG511bfZfv767xhtNDQnLhJJ3hkxn+jdgWvuQUjMo9GkQlw pR7+3PdcVd7Cfg7+xb4lHyJwXSiXywdHqUXY5Xpx5frhcNmCZ9vl/WS2qE2eMJpkOTXs GwdwSb4mEVlQR0MvZXEiPV9PGTk3b15zDEaMpMNDz3BRt4HetSFgjinjUbPhZyWBVZF+ eduKhEvHuQn9sL2Wb6HvzIiVhPsXkBBbQZW2VA6JOzXDkMQWDyngbeSqOANv8KthbNLD PsrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vC7KUbM0gjp7ohOiPN9gTjhRmBe1pLu3XUX6aTs6Jk0=; b=qtgZf7jXtcQkLd7vzRLoQQXT10HlbJxpTy5Cw8flt+CEFsMy05CyWQ/Zr0J7FTgYmM h0Mc2jVlWuagV4StLgkBzYNELNI6Hnins4G4J8GVoX+PJBf0+H/cnazf7gK7bpXl9eRf 3q75CXoduWRNVGO6u8Mzhx5zgMxqF+v8FmvDlsaZurabx6gBb019kzlYs9ptrVv8LgVt cSAu0bRhcOyCGp/2BotRkpcG0/EbObbWgQ9+n/dCxC9s0Awf86j1a9cezfzRW1sW7ev+ CQhhVfQaZGLrrWCbg6uR5mRHiQ+4qOm9uGZJedJKl/MuQUjl5sT+qpEj0VCXbhJH9ZuV xOKg== X-Gm-Message-State: APjAAAVbSBroq6kWnibk0LtChUhWu46VqgJgxEZ2TWJRxWNRG8E1tRn7 z7+iPw7e/WfbIHouZx+RPyJmlfhOKfQ/Yn16oxg= X-Google-Smtp-Source: APXvYqz5eWJAnNIRDo2YIJ9TiyvcSPcc5p7O29jvgRROYt9Yv+gu4mYvkGr+nu/0YW30mTdF8LVitiuDPeS2VLsHPZs= X-Received: by 2002:a9d:6014:: with SMTP id h20mr8770549otj.210.1562942121623; Fri, 12 Jul 2019 07:35:21 -0700 (PDT) In-Reply-To: <83ftnb2wf9.fsf@gnu.org> 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: 209.51.188.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:162773 Archived-At: On Fri, Jul 12, 2019 at 1:51 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Fri, 12 Jul 2019 13:40:15 +0000 > > Cc: politza@hochschule-trier.de, 36609@debbugs.gnu.org > > > > When a thread is signalled (by thread-signal, which sets another > > thread's error_symbol) while the signalled thread is inside a > > select(), thread_select() will return non-locally for that thread, and > > we fail to release an internal GLib lock through > > g_main_context_release(). That's the first bug. > > We should either release the global lock before the thread exits, or > defer the acting upon the signal until later. We cannot disable the > signal handling altogether because it is entirely legitimate to signal > another thread, and when we do, that other thread will _always_ be > inside thread_select. Really? What about thread-yield? > For the main thread, handling the signal in that situation shouldn't > be a problem, because it is not going to exit. Right? I think the main thread can still fail to release the lock... > > When xg_select() fails to acquire the internal GLib lock, it simply > > does a select() on the remaining file descriptors: > > Why does it fail to acquire that lock? Because another thread holds it, either an Emacs or a non-Emacs thread. In both cases, I think we might miss events unless we return with errno == EINTR. > > context_acquired = g_main_context_acquire (context) > > /* FIXME: If we couldn't acquire the context, we just silently proceed > > because this function handles more than just glib file descriptors. > > Note that, as implemented, this failure is completely silent: there is > > no feedback to the caller. */ > > > > This seems like a second, albeit documented, bug to me. I think we're > > risking not waking up from the actual select because another > > (non-Emacs) thread happened to hold the main context at the time. > > So what is the proposal for that? spin waiting for the lock? I don't know, to be honest, but I'm afraid there's currently no better way. There's a way to take the lock without spinning, but it's been deprecated.