GNU bug report logs - #36609
27.0.50; Possible race-condition in threading implementation

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Andreas Politz <politza@HIDDEN>; dated Thu, 11 Jul 2019 20:52:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 13 Jul 2019 16:03:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 13 12:03:05 2019
Received: from localhost ([127.0.0.1]:43235 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hmKUL-0007Wk-50
	for submit <at> debbugs.gnu.org; Sat, 13 Jul 2019 12:03:05 -0400
Received: from eggs.gnu.org ([209.51.188.92]:58966)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hmKUJ-0007WG-7h
 for 36609 <at> debbugs.gnu.org; Sat, 13 Jul 2019 12:03:03 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:37388)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hmKU8-0005q2-Cj; Sat, 13 Jul 2019 12:02:52 -0400
Received: from [176.228.60.248] (port=3142 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hmKU6-00041L-9R; Sat, 13 Jul 2019 12:02:52 -0400
Date: Sat, 13 Jul 2019 19:02:37 +0300
Message-Id: <83r26tzzvm.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-reply-to: <CAOqdjBeWeSgPE9BuO3Rrbb49+CK=nr240eKwZb8hV46rGG_nYw@HIDDEN>
 (message from Pip Cet on Sat, 13 Jul 2019 15:57:17 +0000)
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <83muhj2zmb.fsf@HIDDEN>
 <CAOqdjBe7RUWUpkW1NPnak_rY4B+3NkWUXYUK7S+kGicxp-q0pQ@HIDDEN>
 <83ims72xcj.fsf@HIDDEN>
 <CAOqdjBe1sVkKMGH4irscrB7orOqUt+80s5HZrB-8orXYUCDAsA@HIDDEN>
 <83a7dj2sz9.fsf@HIDDEN>
 <CAOqdjBdQ7i5TJidczzs+tyN7C7GSMwASrJb5sJmZp2Psq7NwVg@HIDDEN>
 <835zo72jmr.fsf@HIDDEN> <834l3r2jbe.fsf@HIDDEN>
 <CAOqdjBfkPbSebE-VhVezPCH2Lc_1RYBskf0YmFGiAR6N-7Z9SQ@HIDDEN>
 <8336jb2fhq.fsf@HIDDEN>
 <CAOqdjBeMgjZapif+2bBVnoGU--r9H57r=7PvRBzG4PjidS9PQA@HIDDEN>
 <83wogmyo1k.fsf@HIDDEN> <83sgraylof.fsf@HIDDEN>
 <CAOqdjBeWeSgPE9BuO3Rrbb49+CK=nr240eKwZb8hV46rGG_nYw@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Pip Cet <pipcet@HIDDEN>
> Date: Sat, 13 Jul 2019 15:57:17 +0000
> Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
> 
> > Specifically, why not make this flag thread-independent, and have any
> > thread release the context lock if that variable is non-zero?  I don't
> > think it matters which thread locked the Glib context, we just need to
> > release it once we emerge from thread_select, and do it before we
> > might call Fsignal.  That the lock might be released by a thread other
> > than the one which locked it shouldn't matter, I think, as long as we
> > consider all the Lisp threads acting together on behalf of Emacs.
> 
> I agree entirely.

Great, then I think we are in agreement.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 13 Jul 2019 15:58:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 13 11:58:01 2019
Received: from localhost ([127.0.0.1]:43229 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hmKPR-0005EZ-AB
	for submit <at> debbugs.gnu.org; Sat, 13 Jul 2019 11:58:01 -0400
Received: from mail-ot1-f54.google.com ([209.85.210.54]:46479)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <pipcet@HIDDEN>) id 1hmKPP-0005EK-Kr
 for 36609 <at> debbugs.gnu.org; Sat, 13 Jul 2019 11:58:00 -0400
Received: by mail-ot1-f54.google.com with SMTP id z23so12465499ote.13
 for <36609 <at> debbugs.gnu.org>; Sat, 13 Jul 2019 08:57:59 -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=gx2dwGDHTSKy1W7N9Zf+G+Rm++uSMVXOmjVEVpjKRbU=;
 b=F9xdfU6Wz+RVxMM2o6DEc64ARH94mh66tKRihBNPLo8grJa6INVNU11PHR8yF1fRMd
 3edPTtBv/OuYlQxbfBYfwKwjOg421JCL7QQyzlkXSqhb/B9tjTdwHZ4lTuYtZddNqG+A
 sAAG7RDiTQGzETdjpYg/1hmWeo2rp7A9VWX+IOBvZgb3b1kUoPWmnh4aRQuq9YsNLJJ7
 aXAWdcpyM5cM+LQdx4wz8w3B26J72RGhfyuNm+D4iyK3Q5Jt3hv8oAfcMR+XZaMQQV9O
 UJidxYkTeLFLtVti/v301vYm3rF3hrfEXp27Y/gjH1rDi+CuIH3Gb1k8dmqD1ti4+msr
 hLXw==
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=gx2dwGDHTSKy1W7N9Zf+G+Rm++uSMVXOmjVEVpjKRbU=;
 b=mTmrg1iEsWx6YruRO7/iX6OKGjfssQrNdWP/s2uu6OEEKMTi0PK/iXW1VnUDJwvL6Q
 HNO77itg1wlBDlrGOEo9o2vOC38RC9/IACw3xpDrAAAYKYRgEWferxfQCICCNZtAWaMN
 XelQHf+XehTej35sIJxW8yWcL6q9H0a9pBBpmxnmq5icRI7lSngExUTEVQ4N9CJIbB6E
 m1rFTNjb7FlZzoFzTfyNULwTzL3jnku3RIJsxspH2dvJHElp+zcy9+3eOXLDIdYIo8Sx
 25vjkeh75ibvrvtzrmL7EYzNSEk/NjU9HbdBX1rGs4tDBuoobpQ3LkBnKIsCpA6W3doo
 VyvA==
X-Gm-Message-State: APjAAAUAovj0JND+DoXqvR4a/F3u+fMdJH24wmjy4mco1Ry4h6L4jSEu
 bYFdREOHxg/zJcF3sH1ySFSkVLQOuBkiDHcF3/Q=
X-Google-Smtp-Source: APXvYqwEzJUmkMpyLWKE3r4qn67hr+QfRe8W2Hc0i8dZDwKN4UxV0pd3bpP44gISge+y0OqevRjwmWvYC7BT0Ev8nuY=
X-Received: by 2002:a9d:664c:: with SMTP id q12mr8278598otm.175.1563033473979; 
 Sat, 13 Jul 2019 08:57:53 -0700 (PDT)
MIME-Version: 1.0
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <83muhj2zmb.fsf@HIDDEN>
 <CAOqdjBe7RUWUpkW1NPnak_rY4B+3NkWUXYUK7S+kGicxp-q0pQ@HIDDEN>
 <83ims72xcj.fsf@HIDDEN>
 <CAOqdjBe1sVkKMGH4irscrB7orOqUt+80s5HZrB-8orXYUCDAsA@HIDDEN>
 <83a7dj2sz9.fsf@HIDDEN>
 <CAOqdjBdQ7i5TJidczzs+tyN7C7GSMwASrJb5sJmZp2Psq7NwVg@HIDDEN>
 <835zo72jmr.fsf@HIDDEN> <834l3r2jbe.fsf@HIDDEN>
 <CAOqdjBfkPbSebE-VhVezPCH2Lc_1RYBskf0YmFGiAR6N-7Z9SQ@HIDDEN>
 <8336jb2fhq.fsf@HIDDEN>
 <CAOqdjBeMgjZapif+2bBVnoGU--r9H57r=7PvRBzG4PjidS9PQA@HIDDEN>
 <83wogmyo1k.fsf@HIDDEN> <83sgraylof.fsf@HIDDEN>
In-Reply-To: <83sgraylof.fsf@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Date: Sat, 13 Jul 2019 15:57:17 +0000
Message-ID: <CAOqdjBeWeSgPE9BuO3Rrbb49+CK=nr240eKwZb8hV46rGG_nYw@HIDDEN>
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On Sat, Jul 13, 2019 at 3:54 PM Eli Zaretskii <eliz@HIDDEN> wrote:
> > But I still would like to understand why we need to maintain a flag
> > per thread.

We don't. I had originally planned to make reacquiring the lock fail
gracefully if we can't spin-lock, but that didn't make it into the
patch, so it should be simplified as you suggest.

> Specifically, why not make this flag thread-independent, and have any
> thread release the context lock if that variable is non-zero?  I don't
> think it matters which thread locked the Glib context, we just need to
> release it once we emerge from thread_select, and do it before we
> might call Fsignal.  That the lock might be released by a thread other
> than the one which locked it shouldn't matter, I think, as long as we
> consider all the Lisp threads acting together on behalf of Emacs.

I agree entirely.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 13 Jul 2019 15:55:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 13 11:55:01 2019
Received: from localhost ([127.0.0.1]:43220 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hmKMX-00059T-7M
	for submit <at> debbugs.gnu.org; Sat, 13 Jul 2019 11:55:01 -0400
Received: from eggs.gnu.org ([209.51.188.92]:56583)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hmKMU-00059D-QT
 for 36609 <at> debbugs.gnu.org; Sat, 13 Jul 2019 11:54:59 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:37210)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hmKMP-0005Uz-2x; Sat, 13 Jul 2019 11:54:53 -0400
Received: from [176.228.60.248] (port=2649 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hmKMO-0004bG-Fn; Sat, 13 Jul 2019 11:54:52 -0400
Date: Sat, 13 Jul 2019 18:54:40 +0300
Message-Id: <83sgraylof.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: pipcet@HIDDEN
In-reply-to: <83wogmyo1k.fsf@HIDDEN> (message from Eli Zaretskii on Sat, 13
 Jul 2019 18:03:35 +0300)
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <83muhj2zmb.fsf@HIDDEN>
 <CAOqdjBe7RUWUpkW1NPnak_rY4B+3NkWUXYUK7S+kGicxp-q0pQ@HIDDEN>
 <83ims72xcj.fsf@HIDDEN>
 <CAOqdjBe1sVkKMGH4irscrB7orOqUt+80s5HZrB-8orXYUCDAsA@HIDDEN>
 <83a7dj2sz9.fsf@HIDDEN>
 <CAOqdjBdQ7i5TJidczzs+tyN7C7GSMwASrJb5sJmZp2Psq7NwVg@HIDDEN>
 <835zo72jmr.fsf@HIDDEN> <834l3r2jbe.fsf@HIDDEN>
 <CAOqdjBfkPbSebE-VhVezPCH2Lc_1RYBskf0YmFGiAR6N-7Z9SQ@HIDDEN>
 <8336jb2fhq.fsf@HIDDEN>
 <CAOqdjBeMgjZapif+2bBVnoGU--r9H57r=7PvRBzG4PjidS9PQA@HIDDEN>
 <83wogmyo1k.fsf@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Sat, 13 Jul 2019 18:03:35 +0300
> From: Eli Zaretskii <eliz@HIDDEN>
> Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
> 
> But I still would like to understand why we need to maintain a flag
> per thread.

Specifically, why not make this flag thread-independent, and have any
thread release the context lock if that variable is non-zero?  I don't
think it matters which thread locked the Glib context, we just need to
release it once we emerge from thread_select, and do it before we
might call Fsignal.  That the lock might be released by a thread other
than the one which locked it shouldn't matter, I think, as long as we
consider all the Lisp threads acting together on behalf of Emacs.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 13 Jul 2019 15:13:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 13 11:13:50 2019
Received: from localhost ([127.0.0.1]:43124 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hmJig-0005xa-Jk
	for submit <at> debbugs.gnu.org; Sat, 13 Jul 2019 11:13:50 -0400
Received: from eggs.gnu.org ([209.51.188.92]:44133)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hmJie-0005x8-Kc
 for 36609 <at> debbugs.gnu.org; Sat, 13 Jul 2019 11:13:48 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:36445)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hmJiY-0000na-I9; Sat, 13 Jul 2019 11:13:42 -0400
Received: from [176.228.60.248] (port=4137 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hmJiX-0002TH-Sp; Sat, 13 Jul 2019 11:13:42 -0400
Date: Sat, 13 Jul 2019 18:13:30 +0300
Message-Id: <83v9w6ynl1.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: pipcet@HIDDEN
In-reply-to: <83wogmyo1k.fsf@HIDDEN> (message from Eli Zaretskii on Sat, 13
 Jul 2019 18:03:35 +0300)
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <83muhj2zmb.fsf@HIDDEN>
 <CAOqdjBe7RUWUpkW1NPnak_rY4B+3NkWUXYUK7S+kGicxp-q0pQ@HIDDEN>
 <83ims72xcj.fsf@HIDDEN>
 <CAOqdjBe1sVkKMGH4irscrB7orOqUt+80s5HZrB-8orXYUCDAsA@HIDDEN>
 <83a7dj2sz9.fsf@HIDDEN>
 <CAOqdjBdQ7i5TJidczzs+tyN7C7GSMwASrJb5sJmZp2Psq7NwVg@HIDDEN>
 <835zo72jmr.fsf@HIDDEN> <834l3r2jbe.fsf@HIDDEN>
 <CAOqdjBfkPbSebE-VhVezPCH2Lc_1RYBskf0YmFGiAR6N-7Z9SQ@HIDDEN>
 <8336jb2fhq.fsf@HIDDEN>
 <CAOqdjBeMgjZapif+2bBVnoGU--r9H57r=7PvRBzG4PjidS9PQA@HIDDEN>
 <83wogmyo1k.fsf@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Sat, 13 Jul 2019 18:03:35 +0300
> From: Eli Zaretskii <eliz@HIDDEN>
> Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
> 
> Also, I think I lost the context: does this attempt to solve the
> original problem reported by Andreas, or only the problem reported by
> you later in the discussion?

I guess Andreas just answered this question.

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 13 Jul 2019 15:04:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 13 11:04:27 2019
Received: from localhost ([127.0.0.1]:43099 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hmJZa-0005hd-Vv
	for submit <at> debbugs.gnu.org; Sat, 13 Jul 2019 11:04:27 -0400
Received: from gateway-a.fh-trier.de ([143.93.54.181]:41619)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <politza@HIDDEN>) id 1hmJZZ-0005hW-KQ
 for 36609 <at> debbugs.gnu.org; Sat, 13 Jul 2019 11:04:26 -0400
X-Virus-Scanned: by Amavisd-new + Sophos + ClamAV [Rechenzentrum Hochschule
 Trier (RZ/HT)]
Received: from localhost (x4dbd379a.dyn.telefonica.de [77.189.55.154])
 (using TLSv1 with cipher AES256-SHA (256/256 bits))
 (No client certificate requested) (Authenticated sender: politza)
 by gateway-a.fh-trier.de (Postfix) with ESMTPSA id B57B0186C482;
 Sat, 13 Jul 2019 17:04:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=hochschule-trier.de;
 s=default; t=1563030263; bh=s7ry+QO/HWcP6ovjmQNkhxDKcdc=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:Message-ID:
 MIME-Version:Content-Type;
 b=NBTkPIhqmNb3tgs4WulsQX2xgcGALQXpO4HiCiA1uYEQWVCvpElnrv6GBtw+QA6QW
 M7E4eLb2Xnf+o6LS/03AIHCnutz7XFbKLFQkrLjp4siQhzVGyNx/ZY1cQycT/FYPFu
 jIWFGnMvUF5oIrQbHCHV415/XjqXFmdsXkzK8klo=
From: Andreas Politz <politza@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <83muhj2zmb.fsf@HIDDEN>
 <CAOqdjBe7RUWUpkW1NPnak_rY4B+3NkWUXYUK7S+kGicxp-q0pQ@HIDDEN>
 <83ims72xcj.fsf@HIDDEN>
 <CAOqdjBe1sVkKMGH4irscrB7orOqUt+80s5HZrB-8orXYUCDAsA@HIDDEN>
 <83a7dj2sz9.fsf@HIDDEN>
 <CAOqdjBdQ7i5TJidczzs+tyN7C7GSMwASrJb5sJmZp2Psq7NwVg@HIDDEN>
 <835zo72jmr.fsf@HIDDEN> <834l3r2jbe.fsf@HIDDEN>
 <CAOqdjBfkPbSebE-VhVezPCH2Lc_1RYBskf0YmFGiAR6N-7Z9SQ@HIDDEN>
 <8336jb2fhq.fsf@HIDDEN>
 <CAOqdjBeMgjZapif+2bBVnoGU--r9H57r=7PvRBzG4PjidS9PQA@HIDDEN>
Date: Sat, 13 Jul 2019 17:04:23 +0200
In-Reply-To: <CAOqdjBeMgjZapif+2bBVnoGU--r9H57r=7PvRBzG4PjidS9PQA@HIDDEN>
 (Pip Cet's message of "Sat, 13 Jul 2019 14:37:25 +0000")
Message-ID: <87k1cm2cy0.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 36609
Cc: Eli Zaretskii <eliz@HIDDEN>, 36609 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)


I ran my problematic code a couple thousand times on this patch without
freezes, while producing the expected results.

Thanks for figuring this out.

Andreas




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 13 Jul 2019 15:03:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 13 11:03:58 2019
Received: from localhost ([127.0.0.1]:43095 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hmJZ8-0005gY-Ao
	for submit <at> debbugs.gnu.org; Sat, 13 Jul 2019 11:03:58 -0400
Received: from eggs.gnu.org ([209.51.188.92]:41709)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hmJZ6-0005gK-St
 for 36609 <at> debbugs.gnu.org; Sat, 13 Jul 2019 11:03:57 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:36235)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hmJYz-0004DX-Ed; Sat, 13 Jul 2019 11:03:50 -0400
Received: from [176.228.60.248] (port=3536 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hmJYx-0001fc-VE; Sat, 13 Jul 2019 11:03:49 -0400
Date: Sat, 13 Jul 2019 18:03:35 +0300
Message-Id: <83wogmyo1k.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-reply-to: <CAOqdjBeMgjZapif+2bBVnoGU--r9H57r=7PvRBzG4PjidS9PQA@HIDDEN>
 (message from Pip Cet on Sat, 13 Jul 2019 14:37:25 +0000)
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <83muhj2zmb.fsf@HIDDEN>
 <CAOqdjBe7RUWUpkW1NPnak_rY4B+3NkWUXYUK7S+kGicxp-q0pQ@HIDDEN>
 <83ims72xcj.fsf@HIDDEN>
 <CAOqdjBe1sVkKMGH4irscrB7orOqUt+80s5HZrB-8orXYUCDAsA@HIDDEN>
 <83a7dj2sz9.fsf@HIDDEN>
 <CAOqdjBdQ7i5TJidczzs+tyN7C7GSMwASrJb5sJmZp2Psq7NwVg@HIDDEN>
 <835zo72jmr.fsf@HIDDEN> <834l3r2jbe.fsf@HIDDEN>
 <CAOqdjBfkPbSebE-VhVezPCH2Lc_1RYBskf0YmFGiAR6N-7Z9SQ@HIDDEN>
 <8336jb2fhq.fsf@HIDDEN>
 <CAOqdjBeMgjZapif+2bBVnoGU--r9H57r=7PvRBzG4PjidS9PQA@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Pip Cet <pipcet@HIDDEN>
> Date: Sat, 13 Jul 2019 14:37:25 +0000
> Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
> 
> Well, I think we're going to have to do one or more of the following:
> 
> - have a race condition
> - access glib-locked data from the "wrong" thread (another Emacs thread)
> - release the glib lock from the "wrong" thread (another Emacs thread)
> 
> Of these, the second is the best alternative, I think: we simply grab
> the g_main_context lock globally, acting for all Emacs threads, and
> the last thread to require it releases it when it leaves xg_select.

I agree.

> As long as there's at least one thread in the critical section of
> xg_select, we hold the lock, but access to the context isn't
> necessarily from the thread which locked it.

Hmm... wouldn't this cause us always hold that lock when there's more
than one Lisp thread?  And if so, what will that do to GTK and its own
threads, which also want to acquire the Glib context?

IOW, I guess I don't understand what problem would the proposed
changes solve that the current code doesn't.  Can you tell?

> > Hmm... how would this work with your patch?  Suppose one thread calls
> > xg_select, acquires the Glib lock, sets its holding_glib_lock flag,
> > then releases the global Lisp lock and calls pselect.  Since the
> > global Lisp lock is now up for grabs, some other Lisp thread can
> > acquire it and start running.
> 
> And when it starts running, it releases the Glib lock.

But only if its holding_glib_lock flag is set, which is not
necessarily true.  For example, what about a thread that was just
created, and never called xg_select yet?

> Okay, that sounds like option #2 above. The attached patch exposes
> glib externals to the generic code, but it appears to work. If you
> think the approach is okay, I'll move the glib-specific parts to
> xgselect.c (if that's okay).

Yes, we should have accessor functions in xgselect.c instead of
letting thread.c etc. access the GTK/Glib data directly.

But I still would like to understand why we need to maintain a flag
per thread.

Also, I think I lost the context: does this attempt to solve the
original problem reported by Andreas, or only the problem reported by
you later in the discussion?

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 13 Jul 2019 14:38:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 13 10:38:14 2019
Received: from localhost ([127.0.0.1]:43039 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hmJAD-0000g5-Du
	for submit <at> debbugs.gnu.org; Sat, 13 Jul 2019 10:38:14 -0400
Received: from mail-ot1-f66.google.com ([209.85.210.66]:37957)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <pipcet@HIDDEN>) id 1hmJA7-0000fa-J2
 for 36609 <at> debbugs.gnu.org; Sat, 13 Jul 2019 10:38:08 -0400
Received: by mail-ot1-f66.google.com with SMTP id d17so12379131oth.5
 for <36609 <at> debbugs.gnu.org>; Sat, 13 Jul 2019 07:38:07 -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=FAqQN2vS7aqDYXJTpIkMEcxCQY5XmhkSyFZUIkX24Xo=;
 b=VPCh/AcmZjUvBtdba+5GTT7PZ5Cqj+zw9PFgG6sVQkDRVYLdYsxPpIi3e2qK27voa6
 uAg2CUroZ1+7sS+FXbMzSd92QqUxJxCSMs8aBd6hiNE/nY6cRe/TpdJkpQ1otZKdNfI/
 XgVKYUc+8ru+uVwhkyyJErIYCoEJ6p5SDDi4yf5C3GrNLsIIYm/D9qBlIzKqyJ1IRGPH
 czzNEhegRZvWBH6wxVeUWLr5HXQAAievgaKkp6rFDmbR9qAPn8wDAvlxqMy7FcpX8k4D
 UzwQk0CJI1ROxcGbrHSRfPTdZCpg50UGCxFSLhBsxYMlsQNoxLSkgmdyVC9oBaR8kMnr
 kRrQ==
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=FAqQN2vS7aqDYXJTpIkMEcxCQY5XmhkSyFZUIkX24Xo=;
 b=tDeif4CuIQp8NeVTod5VHtFqliJ66W35psZPg3VgEi1/kcRYNtmn0SVjVlfZLZ/fJE
 atyecbWA5gaffOaV1GWXJYf3MbLEmxu1bXXMsWw3x+3Nl0hhJD1d3Lmft+QdqQtQ0Wp+
 f8HLIo0HPjY6ptdq6hQnzMBcAh74P2nYqePKcJSYi1+2y5MEnSYrxlWT7UgAUuRI4GK2
 mtBGyug1cyB740cDpysSEW8tfav2yf1u/hlaypw7ENszstLZXCiMTceM0AbaocCvtANk
 N112+x5cG6czvdH8VQuS6rVwQnZ7/RSGPvP1pD7MVLhrdzxgue4UTo5WRpYOphHLeXUt
 hdPQ==
X-Gm-Message-State: APjAAAU7BVIszUnmLW7S8a7z4nNrrTei8TQ88sRE9jpqK/ApHTO1p1c6
 HcnLAH6TBnJL6cIyUasWcVYt2fWyll4iYqbZ1ivsfg==
X-Google-Smtp-Source: APXvYqycShPz4iqZw4NaExzvLo18KrEKUyYM3eZKG/QkisMRNtqmO2fIahQdAnGhMQKfOog4g6pFinH24+/VAAaoJcw=
X-Received: by 2002:a9d:554b:: with SMTP id h11mr5058923oti.154.1563028681854; 
 Sat, 13 Jul 2019 07:38:01 -0700 (PDT)
MIME-Version: 1.0
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <83muhj2zmb.fsf@HIDDEN>
 <CAOqdjBe7RUWUpkW1NPnak_rY4B+3NkWUXYUK7S+kGicxp-q0pQ@HIDDEN>
 <83ims72xcj.fsf@HIDDEN>
 <CAOqdjBe1sVkKMGH4irscrB7orOqUt+80s5HZrB-8orXYUCDAsA@HIDDEN>
 <83a7dj2sz9.fsf@HIDDEN>
 <CAOqdjBdQ7i5TJidczzs+tyN7C7GSMwASrJb5sJmZp2Psq7NwVg@HIDDEN>
 <835zo72jmr.fsf@HIDDEN> <834l3r2jbe.fsf@HIDDEN>
 <CAOqdjBfkPbSebE-VhVezPCH2Lc_1RYBskf0YmFGiAR6N-7Z9SQ@HIDDEN>
 <8336jb2fhq.fsf@HIDDEN>
In-Reply-To: <8336jb2fhq.fsf@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Date: Sat, 13 Jul 2019 14:37:25 +0000
Message-ID: <CAOqdjBeMgjZapif+2bBVnoGU--r9H57r=7PvRBzG4PjidS9PQA@HIDDEN>
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/mixed; boundary="0000000000005b37e5058d90f9b8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--0000000000005b37e5058d90f9b8
Content-Type: text/plain; charset="UTF-8"

On Fri, Jul 12, 2019 at 7:57 PM Eli Zaretskii <eliz@HIDDEN> wrote:
> > I'm now convinced that there simply is no safe way to call select()
> > from two threads at once when using glib.
>
> I hope not, although GTK with its idiosyncrasies caused a lot of pain
> for the threads implementation in Emacs.

Well, I think we're going to have to do one or more of the following:

- have a race condition
- access glib-locked data from the "wrong" thread (another Emacs thread)
- release the glib lock from the "wrong" thread (another Emacs thread)

Of these, the second is the best alternative, I think: we simply grab
the g_main_context lock globally, acting for all Emacs threads, and
the last thread to require it releases it when it leaves xg_select. As
long as there's at least one thread in the critical section of
xg_select, we hold the lock, but access to the context isn't
necessarily from the thread which locked it.

> > I think our options are hacking around it and hoping nothing breaks
> > (this is what the attached patch does; it releases the main context
> > glib lock from the wrong thread soon "after" the other thread called
> > select, but there's actually no way to ensure that "after" is
> > accurate), or rewriting things so we have a single thread that does
> > all the select()ing.
>
> Hmm... how would this work with your patch?  Suppose one thread calls
> xg_select, acquires the Glib lock, sets its holding_glib_lock flag,
> then releases the global Lisp lock and calls pselect.  Since the
> global Lisp lock is now up for grabs, some other Lisp thread can
> acquire it and start running.

And when it starts running, it releases the Glib lock.

> If that other thread then calls
> xg_select, it will hang forever trying to acquire the Glib lock,
> because the first thread that holds it is stuck in pselect.

The first thread no longer holds the Glib lock, it was released when
we switched threads.

> I know very little about GTK and the Glib context lock, but AFAIR we
> really must treat that lock as a global one, not a thread-local one.
> So I think it's okay for one thread to take the Glib lock, and another
> to release it, because Glib just wants to know whether the "rest of
> the program" has it, it doesn't care which thread is that which holds
> the lock.

Okay, that sounds like option #2 above. The attached patch exposes
glib externals to the generic code, but it appears to work. If you
think the approach is okay, I'll move the glib-specific parts to
xgselect.c (if that's okay).

--0000000000005b37e5058d90f9b8
Content-Type: text/x-patch; charset="US-ASCII"; name="glib-hack-002.diff"
Content-Disposition: attachment; filename="glib-hack-002.diff"
Content-Transfer-Encoding: base64
Content-ID: <f_jy1mw7ph0>
X-Attachment-Id: f_jy1mw7ph0

ZGlmZiAtLWdpdCBhL3NyYy90aHJlYWQuYyBiL3NyYy90aHJlYWQuYwppbmRleCBlMmRlYWRkN2E4
Li4wZGRiNzk0NjBiIDEwMDY0NAotLS0gYS9zcmMvdGhyZWFkLmMKKysrIGIvc3JjL3RocmVhZC5j
CkBAIC0xOSw2ICsxOSw5IEBAIENvcHlyaWdodCAoQykgMjAxMi0yMDE5IEZyZWUgU29mdHdhcmUg
Rm91bmRhdGlvbiwgSW5jLgogCiAjaW5jbHVkZSA8Y29uZmlnLmg+CiAjaW5jbHVkZSA8c2V0am1w
Lmg+CisjaWZkZWYgSEFWRV9HTElCCisjaW5jbHVkZSA8Z2xpYi5oPgorI2VuZGlmCiAjaW5jbHVk
ZSAibGlzcC5oIgogI2luY2x1ZGUgImNoYXJhY3Rlci5oIgogI2luY2x1ZGUgImJ1ZmZlci5oIgpA
QCAtODIsNyArODUsNyBAQCBwb3N0X2FjcXVpcmVfZ2xvYmFsX2xvY2sgKHN0cnVjdCB0aHJlYWRf
c3RhdGUgKnNlbGYpCiAKICAgLyogRG8gdGhpcyBlYXJseSBvbiwgc28gdGhhdCBjb2RlIGJlbG93
IGNvdWxkIHNpZ25hbCBlcnJvcnMgKGUuZy4sCiAgICAgIHVuYmluZF9mb3JfdGhyZWFkX3N3aXRj
aCBtaWdodCkgY29ycmVjdGx5LCBiZWNhdXNlIHdlIGFyZSBhbHJlYWR5Ci0gICAgIHJ1bm5pbmcg
aW4gdGhlIGNvbnRleHQgb2YgdGhlIHRocmVhZCBwb2ludGVkIGJ5IFNFTEYuICAqLworICAgICBy
dW5uaW5nIGluIHRoZSBjb250ZXh0IG9mIHRoZSB0aHJlYWQgcG9pbnRlZCB0byBieSBTRUxGLiAg
Ki8KICAgY3VycmVudF90aHJlYWQgPSBzZWxmOwogCiAgIGlmIChwcmV2X3RocmVhZCAhPSBjdXJy
ZW50X3RocmVhZCkKQEAgLTU4Niw2ICs1ODksMTcgQEAgcmVhbGx5X2NhbGxfc2VsZWN0ICh2b2lk
ICphcmcpCiAgIHNhLT5yZXN1bHQgPSAoc2EtPmZ1bmMpIChzYS0+bWF4X2Zkcywgc2EtPnJmZHMs
IHNhLT53ZmRzLCBzYS0+ZWZkcywKIAkJCSAgIHNhLT50aW1lb3V0LCBzYS0+c2lnbWFzayk7CiAK
KyNpZmRlZiBIQVZFX0dMSUIKKyAgLyogUmVsZWFzZSB0aGUgR2xpYiBsb2NrLCBpZiB0aGVyZSBh
cmUgbm8gb3RoZXIgdGhyZWFkcyBpbiB0aGUKKyAgICAgY3JpdGljYWwgc2VjdGlvbi4gICovCisg
IGlmIChjdXJyZW50X3RocmVhZCAhPSBOVUxMICYmIGN1cnJlbnRfdGhyZWFkLT5ob2xkaW5nX2ds
aWJfbG9jaykKKyAgICB7CisgICAgICBjdXJyZW50X3RocmVhZC0+aG9sZGluZ19nbGliX2xvY2sg
PSBmYWxzZTsKKyAgICAgIGlmICgtLXRocmVhZHNfaG9sZGluZ19nbGliX2xvY2sgPT0gMCkKKwln
X21haW5fY29udGV4dF9yZWxlYXNlIChnbGliX21haW5fY29udGV4dCk7CisgICAgfQorI2VuZGlm
CisKICAgYmxvY2tfaW50ZXJydXB0X3NpZ25hbCAoJm9sZHNldCk7CiAgIC8qIElmIHdlIHdlcmUg
aW50ZXJydXB0ZWQgYnkgQy1nIHdoaWxlIGluc2lkZSBzYS0+ZnVuYyBhYm92ZSwgdGhlCiAgICAg
IHNpZ25hbCBoYW5kbGVyIGNvdWxkIGhhdmUgY2FsbGVkIG1heWJlX3JlYWNxdWlyZV9nbG9iYWxf
bG9jaywgaW4KQEAgLTc1Niw2ICs3NzAsMTMgQEAgcnVuX3RocmVhZCAodm9pZCAqc3RhdGUpCiAg
ICAgICB9CiAgIH0KIAorI2lmZGVmIEhBVkVfR0xJQgorICAvKiBSZW1lbWJlciB0byByZWxlYXNl
IHRoZSBHbGliIGxvY2sgd2UgbWlnaHQgc3RpbGwgYmUgaG9sZGluZworICAgICAoPykgICovCisg
IGlmIChjdXJyZW50X3RocmVhZC0+aG9sZGluZ19nbGliX2xvY2spCisgICAgaWYgKC0tdGhyZWFk
c19ob2xkaW5nX2dsaWJfbG9jayA9PSAwKQorICAgICAgZ19tYWluX2NvbnRleHRfcmVsZWFzZSAo
Z2xpYl9tYWluX2NvbnRleHQpOworI2VuZGlmCiAgIGN1cnJlbnRfdGhyZWFkID0gTlVMTDsKICAg
c3lzX2NvbmRfYnJvYWRjYXN0ICgmc2VsZi0+dGhyZWFkX2NvbmR2YXIpOwogCmRpZmYgLS1naXQg
YS9zcmMvdGhyZWFkLmggYi9zcmMvdGhyZWFkLmgKaW5kZXggNDk4Yjk5MDljOS4uMWE1OGY2NWM4
OCAxMDA2NDQKLS0tIGEvc3JjL3RocmVhZC5oCisrKyBiL3NyYy90aHJlYWQuaApAQCAtMjksOSAr
MjksMTggQEAgI2RlZmluZSBUSFJFQURfSAogI2luY2x1ZGUgPHNpZ25hbC5oPgkJLyogc2lnc2V0
X3QgKi8KICNlbmRpZgogCisjaWZkZWYgSEFWRV9HTElCCisjaW5jbHVkZSA8Z2xpYi5oPgorI2Vu
ZGlmCisKICNpbmNsdWRlICJzeXNzZWxlY3QuaCIJCS8qIEZJWE1FICovCiAjaW5jbHVkZSAic3lz
dGhyZWFkLmgiCiAKKyNpZmRlZiBIQVZFX0dMSUIKK2V4dGVybiBwdHJkaWZmX3QgdGhyZWFkc19o
b2xkaW5nX2dsaWJfbG9jazsKK2V4dGVybiBHTWFpbkNvbnRleHQgKmdsaWJfbWFpbl9jb250ZXh0
OworI2VuZGlmCisKIHN0cnVjdCB0aHJlYWRfc3RhdGUKIHsKICAgdW5pb24gdmVjdG9ybGlrZV9o
ZWFkZXIgaGVhZGVyOwpAQCAtMTY5LDYgKzE3OCw5IEBAICNkZWZpbmUgZ2V0Y2ptcCAoY3VycmVu
dF90aHJlYWQtPm1fZ2V0Y2ptcCkKICAgICAgaW50ZXJydXB0ZXIgc2hvdWxkIGJyb2FkY2FzdCB0
byB0aGlzIGNvbmRpdGlvbi4gICovCiAgIHN5c19jb25kX3QgKndhaXRfY29uZHZhcjsKIAorI2lm
ZGVmIEhBVkVfR0xJQgorICBib29sIGhvbGRpbmdfZ2xpYl9sb2NrOworI2VuZGlmCiAgIC8qIFRo
aXMgdGhyZWFkIG1pZ2h0IGhhdmUgcmVsZWFzZWQgdGhlIGdsb2JhbCBsb2NrLiAgSWYgc28sIHRo
aXMgaXMKICAgICAgbm9uLXplcm8uICBXaGVuIGEgdGhyZWFkIHJ1bnMgb3V0c2lkZSB0aHJlYWRf
c2VsZWN0IHdpdGggdGhpcwogICAgICBmbGFnIG5vbi16ZXJvLCBpdCBtZWFucyBpdCBoYXMgYmVl
biBpbnRlcnJ1cHRlZCBieSBTSUdJTlQgd2hpbGUKZGlmZiAtLWdpdCBhL3NyYy94Z3NlbGVjdC5j
IGIvc3JjL3hnc2VsZWN0LmMKaW5kZXggOTk4MmExZjBlOS4uMGM5NTg1N2VmOSAxMDA2NDQKLS0t
IGEvc3JjL3hnc2VsZWN0LmMKKysrIGIvc3JjL3hnc2VsZWN0LmMKQEAgLTI5LDYgKzI5LDkgQEAg
Q29weXJpZ2h0IChDKSAyMDA5LTIwMTkgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCiAj
aW5jbHVkZSAiYmxvY2tpbnB1dC5oIgogI2luY2x1ZGUgInN5c3RpbWUuaCIKIAorcHRyZGlmZl90
IHRocmVhZHNfaG9sZGluZ19nbGliX2xvY2s7CitHTWFpbkNvbnRleHQgKmdsaWJfbWFpbl9jb250
ZXh0OworCiAvKiBgeGdfc2VsZWN0JyBpcyBhIGBwc2VsZWN0JyByZXBsYWNlbWVudC4gIFdoeSBk
byB3ZSBuZWVkIGEgc2VwYXJhdGUgZnVuY3Rpb24/CiAgICAxLiBUaW1lb3V0cy4gIEdsaWIgYW5k
IEd0ayByZWx5IG9uIHRpbWVyIGV2ZW50cy4gIElmIHdlIGRpZCBwc2VsZWN0CiAgICAgICB3aXRo
IGEgZ3JlYXRlciB0aW1lb3V0IHRoZW4gdGhlIG9uZSBzY2hlZHVsZWQgYnkgR2xpYiwgd2Ugd291
bGQKQEAgLTU0LDI2ICs1NywyOCBAQCB4Z19zZWxlY3QgKGludCBmZHNfbGltLCBmZF9zZXQgKnJm
ZHMsIGZkX3NldCAqd2ZkcywgZmRfc2V0ICplZmRzLAogICBHUG9sbEZEICpnZmRzID0gZ2Zkc19i
dWY7CiAgIGludCBnZmRzX3NpemUgPSBBUlJBWUVMVFMgKGdmZHNfYnVmKTsKICAgaW50IG5fZ2Zk
cywgcmV0dmFsID0gMCwgb3VyX2ZkcyA9IDAsIG1heF9mZHMgPSBmZHNfbGltIC0gMTsKLSAgYm9v
bCBjb250ZXh0X2FjcXVpcmVkID0gZmFsc2U7CiAgIGludCBpLCBuZmRzLCB0bW9faW5fbWlsbGlz
ZWMsIG11c3RfZnJlZSA9IDA7CiAgIGJvb2wgbmVlZF90b19kaXNwYXRjaDsKIAogICBjb250ZXh0
ID0gZ19tYWluX2NvbnRleHRfZGVmYXVsdCAoKTsKLSAgY29udGV4dF9hY3F1aXJlZCA9IGdfbWFp
bl9jb250ZXh0X2FjcXVpcmUgKGNvbnRleHQpOwotICAvKiBGSVhNRTogSWYgd2UgY291bGRuJ3Qg
YWNxdWlyZSB0aGUgY29udGV4dCwgd2UganVzdCBzaWxlbnRseSBwcm9jZWVkCi0gICAgIGJlY2F1
c2UgdGhpcyBmdW5jdGlvbiBoYW5kbGVzIG1vcmUgdGhhbiBqdXN0IGdsaWIgZmlsZSBkZXNjcmlw
dG9ycy4KLSAgICAgTm90ZSB0aGF0LCBhcyBpbXBsZW1lbnRlZCwgdGhpcyBmYWlsdXJlIGlzIGNv
bXBsZXRlbHkgc2lsZW50OiB0aGVyZSBpcwotICAgICBubyBmZWVkYmFjayB0byB0aGUgY2FsbGVy
LiAgKi8KKyAgLyogQWNxdWlyZSB0aGUgbG9jay4gIFRoaXMgaXMgYSBidXN5IHdhaXQgZm9yIHRl
c3RpbmcuICAqLworICBpZiAoY3VycmVudF90aHJlYWQgIT0gTlVMTCAmJiAhY3VycmVudF90aHJl
YWQtPmhvbGRpbmdfZ2xpYl9sb2NrKQorICAgIHsKKyAgICAgIGlmICh0aHJlYWRzX2hvbGRpbmdf
Z2xpYl9sb2NrKysgPT0gMCkKKwl3aGlsZSAoIWdfbWFpbl9jb250ZXh0X2FjcXVpcmUgKGNvbnRl
eHQpKQorCSAgeworCSAgfQorICAgICAgY3VycmVudF90aHJlYWQtPmhvbGRpbmdfZ2xpYl9sb2Nr
ID0gdHJ1ZTsKKyAgICAgIGdsaWJfbWFpbl9jb250ZXh0ID0gY29udGV4dDsKKyAgICB9CiAKICAg
aWYgKHJmZHMpIGFsbF9yZmRzID0gKnJmZHM7CiAgIGVsc2UgRkRfWkVSTyAoJmFsbF9yZmRzKTsK
ICAgaWYgKHdmZHMpIGFsbF93ZmRzID0gKndmZHM7CiAgIGVsc2UgRkRfWkVSTyAoJmFsbF93ZmRz
KTsKIAotICBuX2dmZHMgPSAoY29udGV4dF9hY3F1aXJlZAotCSAgICA/IGdfbWFpbl9jb250ZXh0
X3F1ZXJ5IChjb250ZXh0LCBHX1BSSU9SSVRZX0xPVywgJnRtb19pbl9taWxsaXNlYywKLQkJCQkg
ICAgZ2ZkcywgZ2Zkc19zaXplKQotCSAgICA6IC0xKTsKKyAgbl9nZmRzID0gZ19tYWluX2NvbnRl
eHRfcXVlcnkgKGNvbnRleHQsIEdfUFJJT1JJVFlfTE9XLCAmdG1vX2luX21pbGxpc2VjLAorCQkJ
CSBnZmRzLCBnZmRzX3NpemUpOwogCiAgIGlmIChnZmRzX3NpemUgPCBuX2dmZHMpCiAgICAgewpA
QCAtMTUxLDggKzE1NiwxOSBAQCB4Z19zZWxlY3QgKGludCBmZHNfbGltLCBmZF9zZXQgKnJmZHMs
IGZkX3NldCAqd2ZkcywgZmRfc2V0ICplZmRzLAogI2Vsc2UKICAgbmVlZF90b19kaXNwYXRjaCA9
IHRydWU7CiAjZW5kaWYKLSAgaWYgKG5lZWRfdG9fZGlzcGF0Y2ggJiYgY29udGV4dF9hY3F1aXJl
ZCkKKyAgaWYgKG5lZWRfdG9fZGlzcGF0Y2gpCiAgICAgeworICAgICAgLyogQWNxdWlyZSB0aGUg
bG9jay4gIFRoaXMgaXMgYSBidXN5IHdhaXQgZm9yIHRlc3RpbmcuICAqLworICAgICAgZ2xpYl9t
YWluX2NvbnRleHQgPSBjb250ZXh0OworICAgICAgaWYgKCFjdXJyZW50X3RocmVhZC0+aG9sZGlu
Z19nbGliX2xvY2spCisJeworCSAgaWYgKHRocmVhZHNfaG9sZGluZ19nbGliX2xvY2srKyA9PSAw
KQorCSAgICB3aGlsZSAoIWdfbWFpbl9jb250ZXh0X2FjcXVpcmUgKGNvbnRleHQpKQorCSAgICAg
IHsKKwkgICAgICB9CisJICBjdXJyZW50X3RocmVhZC0+aG9sZGluZ19nbGliX2xvY2sgPSB0cnVl
OworCX0KKwogICAgICAgaW50IHBzZWxlY3RfZXJybm8gPSBlcnJubzsKICAgICAgIC8qIFByZXZl
bnQgZ19tYWluX2Rpc3BhdGNoIHJlY3Vyc2lvbiwgdGhhdCB3b3VsZCBvY2N1ciB3aXRob3V0CiAg
ICAgICAgICBibG9ja19pbnB1dCB3cmFwcGVyLCBiZWNhdXNlIGV2ZW50IGhhbmRsZXJzIGNhbGwK
QEAgLTE2NCw4ICsxODAsMTIgQEAgeGdfc2VsZWN0IChpbnQgZmRzX2xpbSwgZmRfc2V0ICpyZmRz
LCBmZF9zZXQgKndmZHMsIGZkX3NldCAqZWZkcywKICAgICAgIGVycm5vID0gcHNlbGVjdF9lcnJu
bzsKICAgICB9CiAKLSAgaWYgKGNvbnRleHRfYWNxdWlyZWQpCi0gICAgZ19tYWluX2NvbnRleHRf
cmVsZWFzZSAoY29udGV4dCk7CisgIGlmIChjdXJyZW50X3RocmVhZCAhPSBOVUxMICYmIGN1cnJl
bnRfdGhyZWFkLT5ob2xkaW5nX2dsaWJfbG9jaykKKyAgICBpZiAoLS10aHJlYWRzX2hvbGRpbmdf
Z2xpYl9sb2NrID09IDApCisgICAgICB7CisJZ19tYWluX2NvbnRleHRfcmVsZWFzZSAoY29udGV4
dCk7CisJY3VycmVudF90aHJlYWQtPmhvbGRpbmdfZ2xpYl9sb2NrID0gZmFsc2U7CisgICAgICB9
CiAKICAgLyogVG8gbm90IGhhdmUgdG8gcmVjYWxjdWxhdGUgdGltZW91dCwgcmV0dXJuIGxpa2Ug
dGhpcy4gICovCiAgIGlmICgob3VyX2ZkcyA+IDAgfHwgKG5mZHMgPT0gMCAmJiB0bW9wID09ICZ0
bW8pKSAmJiAocmV0dmFsID09IDApKQo=
--0000000000005b37e5058d90f9b8--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 13 Jul 2019 06:50:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 13 02:50:19 2019
Received: from localhost ([127.0.0.1]:41379 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hmBrP-0002mE-E5
	for submit <at> debbugs.gnu.org; Sat, 13 Jul 2019 02:50:19 -0400
Received: from eggs.gnu.org ([209.51.188.92]:57945)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hmBrM-0002lM-Pt
 for 36609 <at> debbugs.gnu.org; Sat, 13 Jul 2019 02:50:17 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:58114)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hmBrH-0003xy-1u; Sat, 13 Jul 2019 02:50:11 -0400
Received: from [176.228.60.248] (port=4320 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hmBrG-00042u-4u; Sat, 13 Jul 2019 02:50:10 -0400
Date: Sat, 13 Jul 2019 09:50:02 +0300
Message-Id: <83wogm1l9h.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-reply-to: <CAOqdjBe=7cofDzhc2as0x50akNRVxid73QnLQGGRfdOap12R3w@HIDDEN>
 (message from Pip Cet on Fri, 12 Jul 2019 19:30:34 +0000)
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <CAOqdjBcNVU0C2TEjbR4UZ4QX-j=oR27YdGHNgL01RPfPUBQdSA@HIDDEN>
 <83k1cn2z0l.fsf@HIDDEN>
 <CAOqdjBeAcNNTwd8YEAkO60RZc34uhYFYXAPpAb8i=hQFGos+0A@HIDDEN>
 <83ftnb2wf9.fsf@HIDDEN>
 <CAOqdjBdg4Gkz=Zw+EVwTDNaRjLU0nL8FjQB4nsnOkT7=n4AgHw@HIDDEN>
 <83blxz2t43.fsf@HIDDEN>
 <CAOqdjBe=7cofDzhc2as0x50akNRVxid73QnLQGGRfdOap12R3w@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Pip Cet <pipcet@HIDDEN>
> Date: Fri, 12 Jul 2019 19:30:34 +0000
> Cc: politza@HIDDEN, 36609 <at> debbugs.gnu.org
> 
> > > > 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?
> >
> > What about it?
> >
> > You are asking whether, when thread-signal is executed, the thread
> > which we are signaling is necessarily parked inside thread_select?  If
> > so, I don't understand your surprise: only one thread can ever be
> > running, and that is by definition the thread which calls
> > thread-signal.  All the other threads cannot be running, which means
> > they are parked either in thread_select or in sys_mutex_lock called
> > from acquire_global_lock.  Right?
> 
> No, they might also be in the sys_thread_yield syscall, having
> released the global lock but not yet reacquired it:
> 
>   release_global_lock ();
>   sys_thread_yield (); <<<<< here
>   acquire_global_lock (self);

OK, but that, too, means the thread being signaled is not running,
right?  And I still think that a very frequent case, perhaps the most
frequent, is that the thread being signaled is inside thread_select.

> I'm not sure how it's relevant to assert that "that other thread will
> _always_ be inside thread_select".

OK, we've now established that the other thread could also be in
acquire_global_lock or (for a very short time) in sys_thread_yield.

> I have an idea where you might be going with that

I was merely pointing out that we cannot disable the signal handling
as a means to solve the problem.

> but that idea wouldn't work (to release the lock from the signalling
> thread, not the signalled thread that holds it).

Maybe we have a misunderstanding here.  I was talking about this part
of post_acquire_global_lock:

   /* We could have been signaled while waiting to grab the global lock
      for the first time since this thread was created, in which case
      we didn't yet have the opportunity to set up the handlers.  Delay
      raising the signal in that case (it will be actually raised when
      the thread comes here after acquiring the lock the next time).  */
  if (!NILP (current_thread->error_symbol) && handlerlist)
    {
      Lisp_Object sym = current_thread->error_symbol;
      Lisp_Object data = current_thread->error_data;

      current_thread->error_symbol = Qnil;
      current_thread->error_data = Qnil;
      Fsignal (sym, data);
    }

In this part, we have already switched to the thread that has been
signaled, so we are in the signaled thread, not in the signaling
thread.  I meant to release the lock before the call to Fsignal here.

> > If the problem with missing events,
> > then which events are those, and what bad things will happen if we
> > miss them?
> 
> All events that glib knows about but Emacs doesn't. For example, a
> glib timeout is apparently used to achieve some kind of scroll effect
> on GTK menus, which is why we call xg_select from xmenu.c.
> 
> I don't know which libraries use glib-based threads, but I think dbus does, too.
> 
> I believe, but am not certain, that this also includes X events when
> using GTK. That would explain the frozen sessions.

So is the problem that the Glib context is locked "forever", or is the
problem that it's locked by another Lisp thread, even if this lock is
short-lived?  If the former, then arranging for the release of that
lock when the signaled thread exits would solve the problem, right?
And if the problem is the latter one, then why didn't we hear about
this much earlier?  Can you show the bad effect from missing these
events without signaling a thread?

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 19:57:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 15:57:25 2019
Received: from localhost ([127.0.0.1]:40753 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hm1fW-0003YR-6f
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 15:57:24 -0400
Received: from eggs.gnu.org ([209.51.188.92]:40790)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hm1fU-0003YF-Hf
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 15:57:21 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:46916)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hm1fO-0006LU-PJ; Fri, 12 Jul 2019 15:57:14 -0400
Received: from [176.228.60.248] (port=4397 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hm1fN-0005E9-BI; Fri, 12 Jul 2019 15:57:14 -0400
Date: Fri, 12 Jul 2019 22:57:05 +0300
Message-Id: <8336jb2fhq.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-reply-to: <CAOqdjBfkPbSebE-VhVezPCH2Lc_1RYBskf0YmFGiAR6N-7Z9SQ@HIDDEN>
 (message from Pip Cet on Fri, 12 Jul 2019 19:24:38 +0000)
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <83muhj2zmb.fsf@HIDDEN>
 <CAOqdjBe7RUWUpkW1NPnak_rY4B+3NkWUXYUK7S+kGicxp-q0pQ@HIDDEN>
 <83ims72xcj.fsf@HIDDEN>
 <CAOqdjBe1sVkKMGH4irscrB7orOqUt+80s5HZrB-8orXYUCDAsA@HIDDEN>
 <83a7dj2sz9.fsf@HIDDEN>
 <CAOqdjBdQ7i5TJidczzs+tyN7C7GSMwASrJb5sJmZp2Psq7NwVg@HIDDEN>
 <835zo72jmr.fsf@HIDDEN> <834l3r2jbe.fsf@HIDDEN>
 <CAOqdjBfkPbSebE-VhVezPCH2Lc_1RYBskf0YmFGiAR6N-7Z9SQ@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Pip Cet <pipcet@HIDDEN>
> Date: Fri, 12 Jul 2019 19:24:38 +0000
> Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
> 
> I'm now convinced that there simply is no safe way to call select()
> from two threads at once when using glib.

I hope not, although GTK with its idiosyncrasies caused a lot of pain
for the threads implementation in Emacs.

> I think our options are hacking around it and hoping nothing breaks
> (this is what the attached patch does; it releases the main context
> glib lock from the wrong thread soon "after" the other thread called
> select, but there's actually no way to ensure that "after" is
> accurate), or rewriting things so we have a single thread that does
> all the select()ing.

Hmm... how would this work with your patch?  Suppose one thread calls
xg_select, acquires the Glib lock, sets its holding_glib_lock flag,
then releases the global Lisp lock and calls pselect.  Since the
global Lisp lock is now up for grabs, some other Lisp thread can
acquire it and start running.  If that other thread then calls
xg_select, it will hang forever trying to acquire the Glib lock,
because the first thread that holds it is stuck in pselect.

Am I missing something?

I know very little about GTK and the Glib context lock, but AFAIR we
really must treat that lock as a global one, not a thread-local one.
So I think it's okay for one thread to take the Glib lock, and another
to release it, because Glib just wants to know whether the "rest of
the program" has it, it doesn't care which thread is that which holds
the lock.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 19:31:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 15:31:18 2019
Received: from localhost ([127.0.0.1]:40749 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hm1GI-0002w3-01
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 15:31:18 -0400
Received: from mail-oi1-f178.google.com ([209.85.167.178]:35379)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <pipcet@HIDDEN>) id 1hm1GG-0002vp-CC
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 15:31:16 -0400
Received: by mail-oi1-f178.google.com with SMTP id a127so8124639oii.2
 for <36609 <at> debbugs.gnu.org>; Fri, 12 Jul 2019 12:31:16 -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=uh18TgPOc3bPBJ4lUI/llHtgVdLs1H48yh++40fsg2U=;
 b=F19rYLdhK8XMXmJoPOZpufPL3I6ABLzdxwiWADRec+hoHMRAKRUi2dvlYy9khKU+pD
 +XVAZ5Bti1pFsK6SWPd1YfALS6sWwA8NoO5Okbb3YgQl04j2rLabN6/bJNzJCw65pJHD
 JTzqykZLDInjVDe6bBon5kt7sjANS0/Zmo0y4SeUkG4FA2IKbod/y6q32S9RUT2SXDBe
 CM/1H4MghoxrR6fFym2ElheLHYF7WmdWtLZVdz293WFsQG7BybEd5KiUmb8Sd5rv3Omd
 hvOWbzrPeCpk8zshh6zKhzFwTOFqd5o3ZAftW1s4Zw4SWTh+Mc8vti/j7XIY8sXCUe5G
 c5tg==
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=uh18TgPOc3bPBJ4lUI/llHtgVdLs1H48yh++40fsg2U=;
 b=HwQJKfv2r51jWwQvnMRaQgIkrP0FZTZ31upSBhyUisQZwDktc4zlGgdQ+yB1U76niu
 zIwc5YZWhHEQmG43HM8XYoZG1MTzzES7UEHIf8vbyWDw0FtC9QeNOlhnl9zawqZWWDp5
 Kt29HDADzi8HmZyn7A8wXkyjfeL/8gxMbUnc+LvXJe18ZXSqR2m4t9IMdDSlNDfxNsja
 CWDuvCYpoR+clpZmrZ/elV7Cw1A+IqnKJe6pFdwvfQbjP4RNlSg7VtPdV8HT6pNLtfqj
 2HD8AOZxcLNihYmFzErpG5rsfkYwDIo+EmJuiMkiCa3/tkGqbard4Irk3BA8ArBPLOBy
 sfgQ==
X-Gm-Message-State: APjAAAU64RMC3LI4XzVAD/zyvywPQtR71QE7Ekesye0zr6xaPiVUe+Jh
 4a8LEEgAvtN3It2MeAmwp+E20UeN2NDPULUjbSw=
X-Google-Smtp-Source: APXvYqzErcMEOyrktymeGNAhcIZjv7s7pPG4/QZxz1CAB80dwOlaznowZRNnPrFgZxLfh/0AB4JeMx4/PnldMBYjdvE=
X-Received: by 2002:a05:6808:313:: with SMTP id
 i19mr6790386oie.30.1562959870729; 
 Fri, 12 Jul 2019 12:31:10 -0700 (PDT)
MIME-Version: 1.0
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <CAOqdjBcNVU0C2TEjbR4UZ4QX-j=oR27YdGHNgL01RPfPUBQdSA@HIDDEN>
 <83k1cn2z0l.fsf@HIDDEN>
 <CAOqdjBeAcNNTwd8YEAkO60RZc34uhYFYXAPpAb8i=hQFGos+0A@HIDDEN>
 <83ftnb2wf9.fsf@HIDDEN>
 <CAOqdjBdg4Gkz=Zw+EVwTDNaRjLU0nL8FjQB4nsnOkT7=n4AgHw@HIDDEN>
 <83blxz2t43.fsf@HIDDEN>
In-Reply-To: <83blxz2t43.fsf@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Date: Fri, 12 Jul 2019 19:30:34 +0000
Message-ID: <CAOqdjBe=7cofDzhc2as0x50akNRVxid73QnLQGGRfdOap12R3w@HIDDEN>
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

> > > 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?
>
> What about it?
>
> You are asking whether, when thread-signal is executed, the thread
> which we are signaling is necessarily parked inside thread_select?  If
> so, I don't understand your surprise: only one thread can ever be
> running, and that is by definition the thread which calls
> thread-signal.  All the other threads cannot be running, which means
> they are parked either in thread_select or in sys_mutex_lock called
> from acquire_global_lock.  Right?

No, they might also be in the sys_thread_yield syscall, having
released the global lock but not yet reacquired it:

  release_global_lock ();
  sys_thread_yield (); <<<<< here
  acquire_global_lock (self);

> As for thread-yield, I'm not sure I understand how is it related to
> the issue we are discussing.

I'm not sure how it's relevant to assert that "that other thread will
_always_ be inside thread_select". I have an idea where you might be
going with that, but that idea wouldn't work (to release the lock from
the signalling thread, not the signalled thread that holds it).

> If the problem with missing events,
> then which events are those, and what bad things will happen if we
> miss them?

All events that glib knows about but Emacs doesn't. For example, a
glib timeout is apparently used to achieve some kind of scroll effect
on GTK menus, which is why we call xg_select from xmenu.c.

I don't know which libraries use glib-based threads, but I think dbus does, too.

I believe, but am not certain, that this also includes X events when
using GTK. That would explain the frozen sessions.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 19:25:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 15:25:22 2019
Received: from localhost ([127.0.0.1]:40744 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hm1AY-0002lo-70
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 15:25:22 -0400
Received: from mail-ot1-f67.google.com ([209.85.210.67]:45180)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <pipcet@HIDDEN>) id 1hm1AW-0002la-VO
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 15:25:21 -0400
Received: by mail-ot1-f67.google.com with SMTP id x21so10513434otq.12
 for <36609 <at> debbugs.gnu.org>; Fri, 12 Jul 2019 12:25:20 -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=AhgdYj1G21HGZTdqmJ0skkYYtWUuBTkRPrbWx5ljj24=;
 b=kwQ9ZOhdaedfKh5ad/jwr3I88OhPo2JYEVlU1NuXyPE2DizAWW1a3EwA1ZVhOUEeqN
 BNa5yGpWDpnqkUgyuovLzie4Sfcohh6iueVy/VZLdNWpEWuq9wl5X/QfRLPD4c8XenJ9
 Myvt01zz4Mntn59afBm9rqQ9IETqssXlGV3Bz3GcRsog0ysx+HmOOFhLBsBhdbC2cIL9
 LcXtE21R+xYTq4YlmTYQdeRPfMX79LflXlv2WbhbZZlt+TSkSyWp4jRIqcMU1OhJCU3Y
 7i0wR8zLJfvTkDYQvYBo8c5SvsUPd6atm6wobH3dMTc0svwLKIDV8GJzZVuXdR1GZskw
 1pMw==
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=AhgdYj1G21HGZTdqmJ0skkYYtWUuBTkRPrbWx5ljj24=;
 b=GSJj3ClooJh+NbZRvMzJhXtp7s65nsiPgBzBVmGbj7TKhqb19n32O8Vct1hxM+MWdI
 vuaCjtxz1cF1G15MFHs+lhIld8E1t6T4FgjtXWbUyD8nIwcyLfU0rwNsf9xcDYL3oK8S
 rEDeCuLyU+WPKXFuUdib/2BhRoXuSE3jtvEvfjQT/MBeO2JP5HEV3kov/72RBbt/8ETQ
 dovnaqcB4KzGUGnwbN1xb/ljJA9Ef8bOLjsoi/m5kZZa6ozflZlgmDqxTFDrZPmZGcfj
 TIGKQBu3Z+GpD9E52yFbiMBoQClKJu46Z5TOv1tGeW1CNjOZyRMVoFBnPUGBhGymB7gC
 IpwA==
X-Gm-Message-State: APjAAAV1sP0FnUXBvto+v2qaOt8N+DFnKC7fEJxBAO1ErBrs36llSSkl
 ik/zo80x74uFeyiLyaRqtj5wHBt/mntD1G65lRg=
X-Google-Smtp-Source: APXvYqy9fvljvgoUzipQQGdHbNPPy5nViIzkyzip2oW94L/G0xO57sxVkgQFwwylU3uwwAdGI6BT2alBbFm3Zo+EEDw=
X-Received: by 2002:a9d:664c:: with SMTP id q12mr5274838otm.175.1562959515182; 
 Fri, 12 Jul 2019 12:25:15 -0700 (PDT)
MIME-Version: 1.0
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <83muhj2zmb.fsf@HIDDEN>
 <CAOqdjBe7RUWUpkW1NPnak_rY4B+3NkWUXYUK7S+kGicxp-q0pQ@HIDDEN>
 <83ims72xcj.fsf@HIDDEN>
 <CAOqdjBe1sVkKMGH4irscrB7orOqUt+80s5HZrB-8orXYUCDAsA@HIDDEN>
 <83a7dj2sz9.fsf@HIDDEN>
 <CAOqdjBdQ7i5TJidczzs+tyN7C7GSMwASrJb5sJmZp2Psq7NwVg@HIDDEN>
 <835zo72jmr.fsf@HIDDEN> <834l3r2jbe.fsf@HIDDEN>
In-Reply-To: <834l3r2jbe.fsf@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Date: Fri, 12 Jul 2019 19:24:38 +0000
Message-ID: <CAOqdjBfkPbSebE-VhVezPCH2Lc_1RYBskf0YmFGiAR6N-7Z9SQ@HIDDEN>
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/mixed; boundary="000000000000b3a7a4058d80de4f"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--000000000000b3a7a4058d80de4f
Content-Type: text/plain; charset="UTF-8"

On Fri, Jul 12, 2019 at 6:34 PM Eli Zaretskii <eliz@HIDDEN> wrote:
> > Sorry, I don't want to call unwind-protect there.  Call me paranoid,
> > if you want.
>
> Maybe I should explain the rationale behind that paranoia.  The main

I don't think it's paranoia, I just wasn't sure there was a good way
to avoid it.

I'm now convinced that there simply is no safe way to call select()
from two threads at once when using glib.

I think our options are hacking around it and hoping nothing breaks
(this is what the attached patch does; it releases the main context
glib lock from the wrong thread soon "after" the other thread called
select, but there's actually no way to ensure that "after" is
accurate), or rewriting things so we have a single thread that does
all the select()ing.

> reason is that you are proposing to do that inside code that can
> switch threads.  Switching threads means switching to another stack
> and also to another set of handlers.  So using the unwind-protect
> machinery in this situation is IMO asking for trouble.

Thanks for explaining.

--000000000000b3a7a4058d80de4f
Content-Type: application/x-patch; name="glib-hack.diff"
Content-Disposition: attachment; filename="glib-hack.diff"
Content-Transfer-Encoding: base64
Content-ID: <f_jy0gqn390>
X-Attachment-Id: f_jy0gqn390

ZGlmZiAtLWdpdCBhL3NyYy90aHJlYWQuYyBiL3NyYy90aHJlYWQuYwppbmRleCBlMmRlYWRkN2E4
Li5iMWFkNWU4OTQ2IDEwMDY0NAotLS0gYS9zcmMvdGhyZWFkLmMKKysrIGIvc3JjL3RocmVhZC5j
CkBAIC0xOSw2ICsxOSw5IEBAIENvcHlyaWdodCAoQykgMjAxMi0yMDE5IEZyZWUgU29mdHdhcmUg
Rm91bmRhdGlvbiwgSW5jLgogCiAjaW5jbHVkZSA8Y29uZmlnLmg+CiAjaW5jbHVkZSA8c2V0am1w
Lmg+CisjaWZkZWYgSEFWRV9HTElCCisjaW5jbHVkZSA8Z2xpYi5oPgorI2VuZGlmCiAjaW5jbHVk
ZSAibGlzcC5oIgogI2luY2x1ZGUgImNoYXJhY3Rlci5oIgogI2luY2x1ZGUgImJ1ZmZlci5oIgpA
QCAtODAsMTEgKzgzLDI2IEBAIHBvc3RfYWNxdWlyZV9nbG9iYWxfbG9jayAoc3RydWN0IHRocmVh
ZF9zdGF0ZSAqc2VsZikKIHsKICAgc3RydWN0IHRocmVhZF9zdGF0ZSAqcHJldl90aHJlYWQgPSBj
dXJyZW50X3RocmVhZDsKIAorI2lmZGVmIEhBVkVfR0xJQgorICBpZiAoY3VycmVudF90aHJlYWQg
IT0gTlVMTCAmJiBjdXJyZW50X3RocmVhZC0+aG9sZGluZ19nbGliX2xvY2spCisgICAgZ19tYWlu
X2NvbnRleHRfcmVsZWFzZSAoY3VycmVudF90aHJlYWQtPmNvbnRleHQpOworI2VuZGlmCisKICAg
LyogRG8gdGhpcyBlYXJseSBvbiwgc28gdGhhdCBjb2RlIGJlbG93IGNvdWxkIHNpZ25hbCBlcnJv
cnMgKGUuZy4sCiAgICAgIHVuYmluZF9mb3JfdGhyZWFkX3N3aXRjaCBtaWdodCkgY29ycmVjdGx5
LCBiZWNhdXNlIHdlIGFyZSBhbHJlYWR5Ci0gICAgIHJ1bm5pbmcgaW4gdGhlIGNvbnRleHQgb2Yg
dGhlIHRocmVhZCBwb2ludGVkIGJ5IFNFTEYuICAqLworICAgICBydW5uaW5nIGluIHRoZSBjb250
ZXh0IG9mIHRoZSB0aHJlYWQgcG9pbnRlZCB0byBieSBTRUxGLiAgKi8KICAgY3VycmVudF90aHJl
YWQgPSBzZWxmOwogCisjaWZkZWYgSEFWRV9HTElCCisgIGlmIChjdXJyZW50X3RocmVhZC0+aG9s
ZGluZ19nbGliX2xvY2spCisgICAgZG8KKyAgICAgIHsKKwljdXJyZW50X3RocmVhZC0+aG9sZGlu
Z19nbGliX2xvY2sgPQorCSAgZ19tYWluX2NvbnRleHRfYWNxdWlyZSAoY3VycmVudF90aHJlYWQt
PmNvbnRleHQpOworICAgICAgfQorICAgIHdoaWxlICghY3VycmVudF90aHJlYWQtPmhvbGRpbmdf
Z2xpYl9sb2NrKTsKKyNlbmRpZgorCiAgIGlmIChwcmV2X3RocmVhZCAhPSBjdXJyZW50X3RocmVh
ZCkKICAgICB7CiAgICAgICAvKiBQUkVWX1RIUkVBRCBpcyBOVUxMIGlmIHRoZSBwcmV2aW91c2x5
IGN1cnJlbnQgdGhyZWFkCkBAIC03NTYsNiArNzc0LDEwIEBAIHJ1bl90aHJlYWQgKHZvaWQgKnN0
YXRlKQogICAgICAgfQogICB9CiAKKyNpZmRlZiBIQVZFX0dMSUIKKyAgaWYgKGN1cnJlbnRfdGhy
ZWFkLT5ob2xkaW5nX2dsaWJfbG9jaykKKyAgICBnX21haW5fY29udGV4dF9yZWxlYXNlIChjdXJy
ZW50X3RocmVhZC0+Y29udGV4dCk7CisjZW5kaWYKICAgY3VycmVudF90aHJlYWQgPSBOVUxMOwog
ICBzeXNfY29uZF9icm9hZGNhc3QgKCZzZWxmLT50aHJlYWRfY29uZHZhcik7CiAKZGlmZiAtLWdp
dCBhL3NyYy90aHJlYWQuaCBiL3NyYy90aHJlYWQuaAppbmRleCA0OThiOTkwOWM5Li45ZTVjODcw
MDBlIDEwMDY0NAotLS0gYS9zcmMvdGhyZWFkLmgKKysrIGIvc3JjL3RocmVhZC5oCkBAIC0yOSw2
ICsyOSwxMCBAQCAjZGVmaW5lIFRIUkVBRF9ICiAjaW5jbHVkZSA8c2lnbmFsLmg+CQkvKiBzaWdz
ZXRfdCAqLwogI2VuZGlmCiAKKyNpZmRlZiBIQVZFX0dMSUIKKyNpbmNsdWRlIDxnbGliLmg+Cisj
ZW5kaWYKKwogI2luY2x1ZGUgInN5c3NlbGVjdC5oIgkJLyogRklYTUUgKi8KICNpbmNsdWRlICJz
eXN0aHJlYWQuaCIKIApAQCAtMTY5LDYgKzE3MywxMCBAQCAjZGVmaW5lIGdldGNqbXAgKGN1cnJl
bnRfdGhyZWFkLT5tX2dldGNqbXApCiAgICAgIGludGVycnVwdGVyIHNob3VsZCBicm9hZGNhc3Qg
dG8gdGhpcyBjb25kaXRpb24uICAqLwogICBzeXNfY29uZF90ICp3YWl0X2NvbmR2YXI7CiAKKyNp
ZmRlZiBIQVZFX0dMSUIKKyAgYm9vbCBob2xkaW5nX2dsaWJfbG9jazsKKyAgR01haW5Db250ZXh0
ICpjb250ZXh0OworI2VuZGlmCiAgIC8qIFRoaXMgdGhyZWFkIG1pZ2h0IGhhdmUgcmVsZWFzZWQg
dGhlIGdsb2JhbCBsb2NrLiAgSWYgc28sIHRoaXMgaXMKICAgICAgbm9uLXplcm8uICBXaGVuIGEg
dGhyZWFkIHJ1bnMgb3V0c2lkZSB0aHJlYWRfc2VsZWN0IHdpdGggdGhpcwogICAgICBmbGFnIG5v
bi16ZXJvLCBpdCBtZWFucyBpdCBoYXMgYmVlbiBpbnRlcnJ1cHRlZCBieSBTSUdJTlQgd2hpbGUK
ZGlmZiAtLWdpdCBhL3NyYy94Z3NlbGVjdC5jIGIvc3JjL3hnc2VsZWN0LmMKaW5kZXggOTk4MmEx
ZjBlOS4uMTIwYjQxMGU0ZCAxMDA2NDQKLS0tIGEvc3JjL3hnc2VsZWN0LmMKKysrIGIvc3JjL3hn
c2VsZWN0LmMKQEAgLTU0LDEyICs1NCwxNiBAQCB4Z19zZWxlY3QgKGludCBmZHNfbGltLCBmZF9z
ZXQgKnJmZHMsIGZkX3NldCAqd2ZkcywgZmRfc2V0ICplZmRzLAogICBHUG9sbEZEICpnZmRzID0g
Z2Zkc19idWY7CiAgIGludCBnZmRzX3NpemUgPSBBUlJBWUVMVFMgKGdmZHNfYnVmKTsKICAgaW50
IG5fZ2ZkcywgcmV0dmFsID0gMCwgb3VyX2ZkcyA9IDAsIG1heF9mZHMgPSBmZHNfbGltIC0gMTsK
LSAgYm9vbCBjb250ZXh0X2FjcXVpcmVkID0gZmFsc2U7CiAgIGludCBpLCBuZmRzLCB0bW9faW5f
bWlsbGlzZWMsIG11c3RfZnJlZSA9IDA7CiAgIGJvb2wgbmVlZF90b19kaXNwYXRjaDsKIAogICBj
b250ZXh0ID0gZ19tYWluX2NvbnRleHRfZGVmYXVsdCAoKTsKLSAgY29udGV4dF9hY3F1aXJlZCA9
IGdfbWFpbl9jb250ZXh0X2FjcXVpcmUgKGNvbnRleHQpOworICAvKiBBY3F1aXJlIHRoZSBsb2Nr
LiAgVGhpcyBpcyBhIGJ1c3kgd2FpdCBmb3IgdGVzdGluZy4gICovCisgIGN1cnJlbnRfdGhyZWFk
LT5jb250ZXh0ID0gY29udGV4dDsKKyAgd2hpbGUgKCFjdXJyZW50X3RocmVhZC0+aG9sZGluZ19n
bGliX2xvY2spCisgICAgeworICAgICAgY3VycmVudF90aHJlYWQtPmhvbGRpbmdfZ2xpYl9sb2Nr
ID0gZ19tYWluX2NvbnRleHRfYWNxdWlyZSAoY29udGV4dCk7CisgICAgfQogICAvKiBGSVhNRTog
SWYgd2UgY291bGRuJ3QgYWNxdWlyZSB0aGUgY29udGV4dCwgd2UganVzdCBzaWxlbnRseSBwcm9j
ZWVkCiAgICAgIGJlY2F1c2UgdGhpcyBmdW5jdGlvbiBoYW5kbGVzIG1vcmUgdGhhbiBqdXN0IGds
aWIgZmlsZSBkZXNjcmlwdG9ycy4KICAgICAgTm90ZSB0aGF0LCBhcyBpbXBsZW1lbnRlZCwgdGhp
cyBmYWlsdXJlIGlzIGNvbXBsZXRlbHkgc2lsZW50OiB0aGVyZSBpcwpAQCAtNzAsNyArNzQsNyBA
QCB4Z19zZWxlY3QgKGludCBmZHNfbGltLCBmZF9zZXQgKnJmZHMsIGZkX3NldCAqd2ZkcywgZmRf
c2V0ICplZmRzLAogICBpZiAod2ZkcykgYWxsX3dmZHMgPSAqd2ZkczsKICAgZWxzZSBGRF9aRVJP
ICgmYWxsX3dmZHMpOwogCi0gIG5fZ2ZkcyA9IChjb250ZXh0X2FjcXVpcmVkCisgIG5fZ2ZkcyA9
IChjdXJyZW50X3RocmVhZC0+aG9sZGluZ19nbGliX2xvY2sKIAkgICAgPyBnX21haW5fY29udGV4
dF9xdWVyeSAoY29udGV4dCwgR19QUklPUklUWV9MT1csICZ0bW9faW5fbWlsbGlzZWMsCiAJCQkJ
ICAgIGdmZHMsIGdmZHNfc2l6ZSkKIAkgICAgOiAtMSk7CkBAIC0xNTEsNyArMTU1LDcgQEAgeGdf
c2VsZWN0IChpbnQgZmRzX2xpbSwgZmRfc2V0ICpyZmRzLCBmZF9zZXQgKndmZHMsIGZkX3NldCAq
ZWZkcywKICNlbHNlCiAgIG5lZWRfdG9fZGlzcGF0Y2ggPSB0cnVlOwogI2VuZGlmCi0gIGlmIChu
ZWVkX3RvX2Rpc3BhdGNoICYmIGNvbnRleHRfYWNxdWlyZWQpCisgIGlmIChuZWVkX3RvX2Rpc3Bh
dGNoICYmIGN1cnJlbnRfdGhyZWFkLT5ob2xkaW5nX2dsaWJfbG9jaykKICAgICB7CiAgICAgICBp
bnQgcHNlbGVjdF9lcnJubyA9IGVycm5vOwogICAgICAgLyogUHJldmVudCBnX21haW5fZGlzcGF0
Y2ggcmVjdXJzaW9uLCB0aGF0IHdvdWxkIG9jY3VyIHdpdGhvdXQKQEAgLTE2NCw4ICsxNjgsMTEg
QEAgeGdfc2VsZWN0IChpbnQgZmRzX2xpbSwgZmRfc2V0ICpyZmRzLCBmZF9zZXQgKndmZHMsIGZk
X3NldCAqZWZkcywKICAgICAgIGVycm5vID0gcHNlbGVjdF9lcnJubzsKICAgICB9CiAKLSAgaWYg
KGNvbnRleHRfYWNxdWlyZWQpCi0gICAgZ19tYWluX2NvbnRleHRfcmVsZWFzZSAoY29udGV4dCk7
CisgIGlmIChjdXJyZW50X3RocmVhZC0+aG9sZGluZ19nbGliX2xvY2spCisgICAgeworICAgICAg
Z19tYWluX2NvbnRleHRfcmVsZWFzZSAoY29udGV4dCk7CisgICAgICBjdXJyZW50X3RocmVhZC0+
aG9sZGluZ19nbGliX2xvY2sgPSBmYWxzZTsKKyAgICB9CiAKICAgLyogVG8gbm90IGhhdmUgdG8g
cmVjYWxjdWxhdGUgdGltZW91dCwgcmV0dXJuIGxpa2UgdGhpcy4gICovCiAgIGlmICgob3VyX2Zk
cyA+IDAgfHwgKG5mZHMgPT0gMCAmJiB0bW9wID09ICZ0bW8pKSAmJiAocmV0dmFsID09IDApKQo=
--000000000000b3a7a4058d80de4f--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 18:34:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 14:34:47 2019
Received: from localhost ([127.0.0.1]:40720 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hm0Na-0001Uy-So
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 14:34:47 -0400
Received: from eggs.gnu.org ([209.51.188.92]:45388)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hm0NY-0001Ul-QU
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 14:34:45 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:45672)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hm0NR-0002SW-Ez; Fri, 12 Jul 2019 14:34:37 -0400
Received: from [176.228.60.248] (port=3121 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hm0NQ-000894-Rn; Fri, 12 Jul 2019 14:34:37 -0400
Date: Fri, 12 Jul 2019 21:34:29 +0300
Message-Id: <834l3r2jbe.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: pipcet@HIDDEN
In-reply-to: <835zo72jmr.fsf@HIDDEN> (message from Eli Zaretskii on Fri, 12
 Jul 2019 21:27:40 +0300)
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <83muhj2zmb.fsf@HIDDEN>
 <CAOqdjBe7RUWUpkW1NPnak_rY4B+3NkWUXYUK7S+kGicxp-q0pQ@HIDDEN>
 <83ims72xcj.fsf@HIDDEN>
 <CAOqdjBe1sVkKMGH4irscrB7orOqUt+80s5HZrB-8orXYUCDAsA@HIDDEN>
 <83a7dj2sz9.fsf@HIDDEN>
 <CAOqdjBdQ7i5TJidczzs+tyN7C7GSMwASrJb5sJmZp2Psq7NwVg@HIDDEN>
 <835zo72jmr.fsf@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Fri, 12 Jul 2019 21:27:40 +0300
> From: Eli Zaretskii <eliz@HIDDEN>
> Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
> 
> Sorry, I don't want to call unwind-protect there.  Call me paranoid,
> if you want.

Maybe I should explain the rationale behind that paranoia.  The main
reason is that you are proposing to do that inside code that can
switch threads.  Switching threads means switching to another stack
and also to another set of handlers.  So using the unwind-protect
machinery in this situation is IMO asking for trouble.

And then there's the TTY frame case, where C-g triggers SIGINT, and we
actually longjmp from wherever we were...




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 18:27:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 14:27:58 2019
Received: from localhost ([127.0.0.1]:40715 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hm0H0-0001Jh-2E
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 14:27:58 -0400
Received: from eggs.gnu.org ([209.51.188.92]:43414)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hm0Gy-0001JU-MA
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 14:27:57 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:45519)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hm0Gr-0006gE-SC; Fri, 12 Jul 2019 14:27:50 -0400
Received: from [176.228.60.248] (port=2709 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hm0Gq-0001EM-Bz; Fri, 12 Jul 2019 14:27:49 -0400
Date: Fri, 12 Jul 2019 21:27:40 +0300
Message-Id: <835zo72jmr.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-reply-to: <CAOqdjBdQ7i5TJidczzs+tyN7C7GSMwASrJb5sJmZp2Psq7NwVg@HIDDEN>
 (message from Pip Cet on Fri, 12 Jul 2019 18:06:29 +0000)
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <83muhj2zmb.fsf@HIDDEN>
 <CAOqdjBe7RUWUpkW1NPnak_rY4B+3NkWUXYUK7S+kGicxp-q0pQ@HIDDEN>
 <83ims72xcj.fsf@HIDDEN>
 <CAOqdjBe1sVkKMGH4irscrB7orOqUt+80s5HZrB-8orXYUCDAsA@HIDDEN>
 <83a7dj2sz9.fsf@HIDDEN>
 <CAOqdjBdQ7i5TJidczzs+tyN7C7GSMwASrJb5sJmZp2Psq7NwVg@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Pip Cet <pipcet@HIDDEN>
> Date: Fri, 12 Jul 2019 18:06:29 +0000
> Cc: politza@HIDDEN, 36609 <at> debbugs.gnu.org
> 
> > Then we should make sure we release it when the thread function exits,
> 
> That's too late, it's legitimate for the thread to have a signal
> handler. We need to release the lock at precisely the time that
> unbind_to would release it.

I had also another proposal:

> > or before we call Fsignal from post_acquire_global_lock.  There's no
> > reason to use the unwind-protect machinery for that, I think.
> 
> If we call Fsignal, surely the unwind-protect machinery is already set
> up and we can safely call it? So unbind_to would work again...

Sorry, I don't want to call unwind-protect there.  Call me paranoid,
if you want.

> I guess I've changed my mind: the unwind-protect machinery does
> precisely what we want, we should simply document that thread_select
> can exit nonlocally and that the select functions need to be written
> to cater to that.
> 
> Two places call xg_select, and they both run long after unbind_to works.
> 
> Doing this without the unwind-protect machinery is difficult: for
> example, a comment in post_acquire_global_lock claims
> unbind_for_thread_switch can exit nonlocally, though I don't think
> that actually happens or we would have seen the bug report.
> 
> What's your proposal for doing this?

Like I said: release the lock before calling Fsignal.  We could do
that before calling unbind_for_thread_switch, if needed.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 18:07:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 14:07:13 2019
Received: from localhost ([127.0.0.1]:40696 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hlzwu-0000o3-O2
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 14:07:13 -0400
Received: from mail-oi1-f170.google.com ([209.85.167.170]:40788)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <pipcet@HIDDEN>) id 1hlzwt-0000nq-3F
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 14:07:11 -0400
Received: by mail-oi1-f170.google.com with SMTP id w196so7929407oie.7
 for <36609 <at> debbugs.gnu.org>; Fri, 12 Jul 2019 11:07:11 -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=CyLNFAqAoxb1aTAgiX1cAXGzhY8r2d5LcZWi5qjkh+s=;
 b=sbF8YYlKFfZz/tg5YR+wsEytD0oZ8KiS5KMVAeEHqnjvFshQqGW3ctqBS4Ndycqvhj
 o0v4Z1CcT2lWHPysIDoghDXzANsnhBhnFEgah0Ar88CKBFihlgdkh02A5XJLoybpuCvV
 OBB9QV+c4meFRr0R52kvMMvr+6mfyN7D0QtyXEmryldVNIV40T4MzSMYMnHd71PkrSnj
 t1wQxWWfPnYruEmef+bfJ/dAkO1yloCydoWLOsgzPhQ8GpAPSRjBNc/muH+GMzyYHhVB
 ql1lQZPKQULg/MJpkY53jtpL8BN1/3oidGIpEo/gMwfAfXtqBRbdkobqrybfKZGXjM/L
 LxNA==
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=CyLNFAqAoxb1aTAgiX1cAXGzhY8r2d5LcZWi5qjkh+s=;
 b=CA7Sz5BkeOqBiSkgIvuGJEYkioOjTwDaNs/ePCPttTk+lT0N1zbVJZrPxsLFPbUgob
 hS8a3lot8/HEHklwBoNJDKAI5M4ffHkZ93JPM3ggMlEze3c8P4nOS0e9RDeklIgIe0h3
 W4hAfjhxdA1RjWp1PgWy2aNUBxQmTLyjH6a0t9wTOdXn575IRPC+GTNLLWciFdcam7Xc
 R75VxdKJMUe6Yv4MfKfJRy/QjPBUszPPokOTMIF1MZsfKMMK+IrofYE8UH7FeRlH6AKa
 iNMmFPPZ/e7+N5kOh8nYk14V6BuzfFdKrhf5lTLIGIZ6JsAbQsCno8u89cN8RJXLk2YZ
 qXEg==
X-Gm-Message-State: APjAAAXWTlMGq/dsQ/TvC0eb9eOGUuyM0qibYgHyGqwoCb8KJ4RhZ5rC
 LwjYCZSQBjgxWGaUs80EEArWcGC7FY+VO7tmTX0=
X-Google-Smtp-Source: APXvYqxpXc0/p1OGiMyvamy9yslWe9+H4tlXbL7WdxGG6j9gu9dYflmXjk6oCiskysSaJ9QFlJSb/HAUlD/xZv7/bs0=
X-Received: by 2002:aca:2303:: with SMTP id e3mr6035516oie.112.1562954825474; 
 Fri, 12 Jul 2019 11:07:05 -0700 (PDT)
MIME-Version: 1.0
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <83muhj2zmb.fsf@HIDDEN>
 <CAOqdjBe7RUWUpkW1NPnak_rY4B+3NkWUXYUK7S+kGicxp-q0pQ@HIDDEN>
 <83ims72xcj.fsf@HIDDEN>
 <CAOqdjBe1sVkKMGH4irscrB7orOqUt+80s5HZrB-8orXYUCDAsA@HIDDEN>
 <83a7dj2sz9.fsf@HIDDEN>
In-Reply-To: <83a7dj2sz9.fsf@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Date: Fri, 12 Jul 2019 18:06:29 +0000
Message-ID: <CAOqdjBdQ7i5TJidczzs+tyN7C7GSMwASrJb5sJmZp2Psq7NwVg@HIDDEN>
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On Fri, Jul 12, 2019 at 3:06 PM Eli Zaretskii <eliz@HIDDEN> wrote:
> > From: Pip Cet <pipcet@HIDDEN>
> > Date: Fri, 12 Jul 2019 13:51:48 +0000
> > Cc: politza@HIDDEN, 36609 <at> debbugs.gnu.org
> >
> > > If this is not the main thread, then the error handlers should be set
> > > so as to log the error in last_thread_error, and then terminate the
> > > thread (via exiting the thread function, AFAIR).
> >
> > Indeed, that's what happens; but the thread now fails to release the
> > GLib lock it had previously acquired, so other threads cannot acquire
> > it again, ever.
>
> Then we should make sure we release it when the thread function exits,

That's too late, it's legitimate for the thread to have a signal
handler. We need to release the lock at precisely the time that
unbind_to would release it.

> or before we call Fsignal from post_acquire_global_lock.  There's no
> reason to use the unwind-protect machinery for that, I think.

If we call Fsignal, surely the unwind-protect machinery is already set
up and we can safely call it? So unbind_to would work again...

I guess I've changed my mind: the unwind-protect machinery does
precisely what we want, we should simply document that thread_select
can exit nonlocally and that the select functions need to be written
to cater to that.

Two places call xg_select, and they both run long after unbind_to works.

Doing this without the unwind-protect machinery is difficult: for
example, a comment in post_acquire_global_lock claims
unbind_for_thread_switch can exit nonlocally, though I don't think
that actually happens or we would have seen the bug report.

What's your proposal for doing this?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 15:06:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 11:06:22 2019
Received: from localhost ([127.0.0.1]:40543 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hlx7u-0002WB-Me
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 11:06:22 -0400
Received: from eggs.gnu.org ([209.51.188.92]:42581)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hlx7q-0002Vv-Me
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 11:06:19 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:41909)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hlx7k-0005GH-V7; Fri, 12 Jul 2019 11:06:13 -0400
Received: from [176.228.60.248] (port=2360 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hlx7c-00013C-OH; Fri, 12 Jul 2019 11:06:12 -0400
Date: Fri, 12 Jul 2019 18:05:46 +0300
Message-Id: <83a7dj2sz9.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-reply-to: <CAOqdjBe1sVkKMGH4irscrB7orOqUt+80s5HZrB-8orXYUCDAsA@HIDDEN>
 (message from Pip Cet on Fri, 12 Jul 2019 13:51:48 +0000)
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <83muhj2zmb.fsf@HIDDEN>
 <CAOqdjBe7RUWUpkW1NPnak_rY4B+3NkWUXYUK7S+kGicxp-q0pQ@HIDDEN>
 <83ims72xcj.fsf@HIDDEN>
 <CAOqdjBe1sVkKMGH4irscrB7orOqUt+80s5HZrB-8orXYUCDAsA@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Pip Cet <pipcet@HIDDEN>
> Date: Fri, 12 Jul 2019 13:51:48 +0000
> Cc: politza@HIDDEN, 36609 <at> debbugs.gnu.org
> 
> > If this is not the main thread, then the error handlers should be set
> > so as to log the error in last_thread_error, and then terminate the
> > thread (via exiting the thread function, AFAIR).
> 
> Indeed, that's what happens; but the thread now fails to release the
> GLib lock it had previously acquired, so other threads cannot acquire
> it again, ever.

Then we should make sure we release it when the thread function exits,
or before we call Fsignal from post_acquire_global_lock.  There's no
reason to use the unwind-protect machinery for that, I think.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 15:03:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 11:03:17 2019
Received: from localhost ([127.0.0.1]:40539 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hlx4v-0002Re-3I
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 11:03:17 -0400
Received: from eggs.gnu.org ([209.51.188.92]:41566)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hlx4t-0002RR-3I
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 11:03:15 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:41860)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hlx4m-00028U-9z; Fri, 12 Jul 2019 11:03:09 -0400
Received: from [176.228.60.248] (port=2185 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hlx4k-00051e-1v; Fri, 12 Jul 2019 11:03:07 -0400
Date: Fri, 12 Jul 2019 18:02:52 +0300
Message-Id: <83blxz2t43.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-reply-to: <CAOqdjBdg4Gkz=Zw+EVwTDNaRjLU0nL8FjQB4nsnOkT7=n4AgHw@HIDDEN>
 (message from Pip Cet on Fri, 12 Jul 2019 14:34:44 +0000)
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <CAOqdjBcNVU0C2TEjbR4UZ4QX-j=oR27YdGHNgL01RPfPUBQdSA@HIDDEN>
 <83k1cn2z0l.fsf@HIDDEN>
 <CAOqdjBeAcNNTwd8YEAkO60RZc34uhYFYXAPpAb8i=hQFGos+0A@HIDDEN>
 <83ftnb2wf9.fsf@HIDDEN>
 <CAOqdjBdg4Gkz=Zw+EVwTDNaRjLU0nL8FjQB4nsnOkT7=n4AgHw@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Pip Cet <pipcet@HIDDEN>
> Date: Fri, 12 Jul 2019 14:34:44 +0000
> Cc: politza@HIDDEN, 36609 <at> 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?

What about it?

You are asking whether, when thread-signal is executed, the thread
which we are signaling is necessarily parked inside thread_select?  If
so, I don't understand your surprise: only one thread can ever be
running, and that is by definition the thread which calls
thread-signal.  All the other threads cannot be running, which means
they are parked either in thread_select or in sys_mutex_lock called
from acquire_global_lock.  Right?

As for thread-yield, I'm not sure I understand how is it related to
the issue we are discussing.

> > 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...

Since the main thread doesn't exit, but just longjmp's to top-level,
and then continues to run, why does it need to release the lock?  Any
thread should hold the lock for as long as it runs.

> > > 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.

OK, and why is it a problem that we continue calling thread_select
regardless of the failure to acquire the Glib lock?  is the problem
this one:

> In both cases, I think we might miss events unless we return
> with errno == EINTR.

?  Or is there something else?  If the problem with missing events,
then which events are those, and what bad things will happen if we
miss them?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 14:35:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 10:35:30 2019
Received: from localhost ([127.0.0.1]:40476 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hlwe1-0007xn-V9
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 10:35:30 -0400
Received: from mail-ot1-f51.google.com ([209.85.210.51]:42309)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <pipcet@HIDDEN>) id 1hlwdz-0007xY-8a
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 10:35:27 -0400
Received: by mail-ot1-f51.google.com with SMTP id l15so9647102otn.9
 for <36609 <at> 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)
MIME-Version: 1.0
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <CAOqdjBcNVU0C2TEjbR4UZ4QX-j=oR27YdGHNgL01RPfPUBQdSA@HIDDEN>
 <83k1cn2z0l.fsf@HIDDEN>
 <CAOqdjBeAcNNTwd8YEAkO60RZc34uhYFYXAPpAb8i=hQFGos+0A@HIDDEN>
 <83ftnb2wf9.fsf@HIDDEN>
In-Reply-To: <83ftnb2wf9.fsf@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Date: Fri, 12 Jul 2019 14:34:44 +0000
Message-ID: <CAOqdjBdg4Gkz=Zw+EVwTDNaRjLU0nL8FjQB4nsnOkT7=n4AgHw@HIDDEN>
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On Fri, Jul 12, 2019 at 1:51 PM Eli Zaretskii <eliz@HIDDEN> wrote:
> > From: Pip Cet <pipcet@HIDDEN>
> > Date: Fri, 12 Jul 2019 13:40:15 +0000
> > Cc: politza@HIDDEN, 36609 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 13:52:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 09:52:35 2019
Received: from localhost ([127.0.0.1]:39405 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hlvyT-0006fe-Mb
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 09:52:35 -0400
Received: from mail-oi1-f196.google.com ([209.85.167.196]:38957)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <pipcet@HIDDEN>) id 1hlvyS-0006fQ-57
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 09:52:32 -0400
Received: by mail-oi1-f196.google.com with SMTP id m202so7328631oig.6
 for <36609 <at> debbugs.gnu.org>; Fri, 12 Jul 2019 06:52:32 -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=+280ro4FM7jUHwvU0erIjWzKO9MvMNZqoANXyWNHPXk=;
 b=HZMoOSBCHBFKu3feliCfIkvO++VQYl8jdYWOBtLf0+160YZoC8LdvF/FyWTmXsvMd9
 txHdOBoguJZ3X8Qa0jr3PYDh/3JWz/MKDS/WxAKitOmfkoSj93mF/bjkbHwMecjTaJGG
 /ZvDI3D40U5TX8soNBmo5P5vy8niN1VXpQroVP9pFYcOAGWwfK1XAYuPh7oHVtZOwT3U
 4XY6WtKKiUEPIJgyyrAMY6QyQoNp8O9Lcn2RuLI5eNXK35eh2qVyPXdhVr19P2KFCCP7
 BgZd/53UVjbXuHbXaHrmCr5yHaAfjVsqTk+scxMNbzs+EDdBoXP7UGoj9IxC86nSctTP
 fDuA==
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=+280ro4FM7jUHwvU0erIjWzKO9MvMNZqoANXyWNHPXk=;
 b=qABLtIQnJpnyaHSlWx5lxhjZJsNQd8duCDFkrmK2OwkOMe53tiVPAcIo5fN59c3+MR
 xPQaZm0/g4yPpsqWr03p1Oalo8n1ZjEeiqzUTVnnGFaE7MCOkNEfCYVpf5rsuJL7/B5z
 3DIn4e2hXvPc6EW1fSKQ8CgOU0TmmUxbWv4xddz7n/QpvBlzM/DVNtlTVhDNXsPvzaj+
 ltOzBITePafdgvBXPDKl7D5EdFHBZsa0UFPU61jRo5jqbrqfG1Hx5jAjT6TuJgYfrIki
 agkKsxc+FnFeiHjrBtXY/6uHqZX1Io+MWb8Cz5ljFtYiLCVq8n+iXQVB5kOXoNEbI81n
 L4hQ==
X-Gm-Message-State: APjAAAXaiD1NSWrEq1EPk6TCgFKhIA45p7waX3C9WJNA+Tv/kWKRfC2+
 yvN3flOJZ3chYtjhtDo7qNi/0KHuSfszxZ4gdg8=
X-Google-Smtp-Source: APXvYqzNFo401ElS2IwIAxrf5Col7vm3Y5X3DbHaTl3yqRv12njrxKXJ+YtIVPVcegggxGBvlc+6UdRntg4v9laKTVQ=
X-Received: by 2002:aca:4790:: with SMTP id u138mr6269678oia.44.1562939545202; 
 Fri, 12 Jul 2019 06:52:25 -0700 (PDT)
MIME-Version: 1.0
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <83muhj2zmb.fsf@HIDDEN>
 <CAOqdjBe7RUWUpkW1NPnak_rY4B+3NkWUXYUK7S+kGicxp-q0pQ@HIDDEN>
 <83ims72xcj.fsf@HIDDEN>
In-Reply-To: <83ims72xcj.fsf@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Date: Fri, 12 Jul 2019 13:51:48 +0000
Message-ID: <CAOqdjBe1sVkKMGH4irscrB7orOqUt+80s5HZrB-8orXYUCDAsA@HIDDEN>
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On Fri, Jul 12, 2019 at 1:31 PM Eli Zaretskii <eliz@HIDDEN> wrote:>
> > From: Pip Cet <pipcet@HIDDEN>
> > Date: Fri, 12 Jul 2019 12:57:51 +0000
> > Cc: politza@HIDDEN, 36609 <at> debbugs.gnu.org
> >
> > Lisp Backtrace:
> > "sleep-for" (0xedf7a530)
> > 0xf6da40 Lisp type 3
> >
> > post_acquire_global_lock () can return abnormally (I didn't know
> > that), so really_call_select() can, too, so thread_select() can, too.
>
> Do you know which code sets current_thread->error_symbol, and what is
> that error symbol?

thread-signal, which my example code calls directly. I passed 'error,
and that's what error_symbol is set to.

last_thread_error is (error) when the Emacs session freezes.

> > > > +  ptrdiff_t count = SPECPDL_INDEX ();
> > >
> > > I don't think we should do that at this low level.
> >
> > You're right, it does stick out. I think we're safe because we're
> > calling Fsignal with the global lock held, but it's not a pretty or
> > well-documented situation.
>
> Is this the main thread which does that?  if so, there should be no
> problem with holding the global lock in this case, is there?
>
> If this is not the main thread, then the error handlers should be set
> so as to log the error in last_thread_error, and then terminate the
> thread (via exiting the thread function, AFAIR).

Indeed, that's what happens; but the thread now fails to release the
GLib lock it had previously acquired, so other threads cannot acquire
it again, ever.

> If this is not what happens, I'd like to know what does happen here,
> and why.

Sure, we should understand what's going on here; even if the fix turns
out to be simple.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 13:51:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 09:51:44 2019
Received: from localhost ([127.0.0.1]:39401 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hlvxg-0006eG-A2
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 09:51:44 -0400
Received: from eggs.gnu.org ([209.51.188.92]:48365)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hlvxd-0006e2-TO
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 09:51:42 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:40633)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hlvxY-0000L2-3u; Fri, 12 Jul 2019 09:51:36 -0400
Received: from [176.228.60.248] (port=1816 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hlvxW-00039q-Jh; Fri, 12 Jul 2019 09:51:35 -0400
Date: Fri, 12 Jul 2019 16:51:22 +0300
Message-Id: <83ftnb2wf9.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-reply-to: <CAOqdjBeAcNNTwd8YEAkO60RZc34uhYFYXAPpAb8i=hQFGos+0A@HIDDEN>
 (message from Pip Cet on Fri, 12 Jul 2019 13:40:15 +0000)
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <CAOqdjBcNVU0C2TEjbR4UZ4QX-j=oR27YdGHNgL01RPfPUBQdSA@HIDDEN>
 <83k1cn2z0l.fsf@HIDDEN>
 <CAOqdjBeAcNNTwd8YEAkO60RZc34uhYFYXAPpAb8i=hQFGos+0A@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Pip Cet <pipcet@HIDDEN>
> Date: Fri, 12 Jul 2019 13:40:15 +0000
> Cc: politza@HIDDEN, 36609 <at> 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.

For the main thread, handling the signal in that situation shouldn't
be a problem, because it is not going to exit.  Right?

> 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?

>   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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 13:41:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 09:41:02 2019
Received: from localhost ([127.0.0.1]:39397 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hlvnJ-0006Od-5I
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 09:41:02 -0400
Received: from mail-oi1-f196.google.com ([209.85.167.196]:34097)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <pipcet@HIDDEN>) id 1hlvnG-0006ON-HK
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 09:40:59 -0400
Received: by mail-oi1-f196.google.com with SMTP id l12so7321587oil.1
 for <36609 <at> debbugs.gnu.org>; Fri, 12 Jul 2019 06:40:58 -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=1DEIH5Jv/CWabnOp3GZ/IY4thuBSAYjd8Ue6uf+1xX0=;
 b=HioYuA5HnZHQYRQ5PWlK/E9sl1eWf1gelBUXgKOgkMMXErsr2HmVkLlzBvyKRPpWDB
 +82b0sbbXJ2QxNVerWoJS7hy6YntoJ9ClNQjjLEN+SsDlaK/J2TbmjoOtmVtlay5uc/M
 8k03keUNc3z0VwvGsz1mYOHRR0Z52gy2WHIuSyrBM6Vmrrh3EQT06ufCd5V0tCIkXP6N
 Wuw4uhB1iiZVfAK89elqqxRViDOqPB/4szdYINBAHDQisNdn9M5lMvKG+NsIt27Coj8T
 zzZw9Pw9EuxhjWj0EozfxtgON1zWS8ekvkPHRDtWxVfyR3ZeiLc4MsuLCaD+5liduyn5
 If4Q==
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=1DEIH5Jv/CWabnOp3GZ/IY4thuBSAYjd8Ue6uf+1xX0=;
 b=PHivDJa5slJr3dvK+coiq1EdhjGWHKqvFBl6LLL7FWxKnpRmu+PDRQCt64axMOyD/j
 1WJlMYHUaUe6RJs5j0aQuZhDJfiPKiEOVCSEGgNutcvhZtegkklGdB6Jnz5R+ldZFRbj
 G1N7r3+im1bDG+DX1z3qZRBW58+OBAGde/zdet8CSJNMFMxfMdbjTMJsBUW/KrfpOtmm
 UsUqvFsZlzEXkgbXqohlex2MDz0eqDFlqAUg1OPXgwtE49SrZ7A5Oszcga16WSVBwrKK
 HeBxjJCDUuXbVHaPW27vwRZwhqwdGYwvo6Ol1aNJ64pf4sOKpgjrTAmMFF7NIpTner1g
 U9wQ==
X-Gm-Message-State: APjAAAXHuw4o6NWVplRk0qLNK03PA4ieFu4PgiBhz1jt1zCel/IHoPiW
 JdebWfvDvH2OhwhuWoVCJMr2f2NQpd7vsKUTPdc=
X-Google-Smtp-Source: APXvYqyb0/lDjpUkSoniKmD+L25oQr2S1dOFs8fovkHPQuJ8p7daxYJEo327MfqWt6Duubv4AT2BTXdwWMobyXMRt4o=
X-Received: by 2002:aca:be88:: with SMTP id o130mr5879868oif.122.1562938852221; 
 Fri, 12 Jul 2019 06:40:52 -0700 (PDT)
MIME-Version: 1.0
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <CAOqdjBcNVU0C2TEjbR4UZ4QX-j=oR27YdGHNgL01RPfPUBQdSA@HIDDEN>
 <83k1cn2z0l.fsf@HIDDEN>
In-Reply-To: <83k1cn2z0l.fsf@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Date: Fri, 12 Jul 2019 13:40:15 +0000
Message-ID: <CAOqdjBeAcNNTwd8YEAkO60RZc34uhYFYXAPpAb8i=hQFGos+0A@HIDDEN>
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On Fri, Jul 12, 2019 at 12:55 PM Eli Zaretskii <eliz@HIDDEN> wrote:
> > From: Pip Cet <pipcet@HIDDEN>
> > Date: Fri, 12 Jul 2019 12:44:35 +0000
> > Cc: 36609 <at> debbugs.gnu.org
> >
> > Okay, I'm still not sure this is really the problem Andreas was
> > seeing, but this code fails to work with xg_select:
> >
> > (let ((thread (make-thread (lambda ()
> >                  (sleep-for 3)))))
> >   (thread-yield)
> >   (thread-signal thread 'error nil))
>
> What do you mean by "fails"?  What do you see when you eval this?

With `emacs -Q', a blinking cursor and an unresponsive emacs (no
response to key presses, not even triple C-g). Sometimes, at least.

Here's a full backtrace of a session where the hang did happen:

Thread 4 (Thread 0x7fffeeb8a700 (LWP 26117)):
#0  0x00007ffff4967819 in __GI___poll (fds=0xd93070, nfds=1, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:29
        resultvar = 18446744073709551100
        sc_cancel_oldtype = 0
#1  0x00007ffff698e136 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff698e25c in g_main_context_iteration ()
    at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007fffeebd7ffd in  ()
    at /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
#4  0x00007ffff69b6415 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007ffff4b38fa3 in start_thread (arg=<optimized out>)
    at pthread_create.c:486
        ret = <optimized out>
        pd = <optimized out>
        now = <optimized out>
        unwind_buf = {
          cancel_jmp_buf = {{
              jmp_buf = {140737198466816, -2332898995959237690,
140737488337566, 140737488337567, 140737198466816, 13933232,
2332932536188793798, 2332875456844002246},
              mask_was_saved = 0
            }},
          priv = {
            pad = {0x0, 0x0, 0x0, 0x0},
            data = {
              prev = 0x0,
              cleanup = 0x0,
              canceltype = 0
            }
          }
        }
        not_first_call = <optimized out>
#6  0x00007ffff49724cf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7fffef59e700 (LWP 26116)):
#0  0x00007ffff4967819 in __GI___poll (fds=0xcb7a20, nfds=2, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:29
        resultvar = 18446744073709551100
        sc_cancel_oldtype = 0
#1  0x00007ffff698e136 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff698e4c2 in g_main_loop_run ()
    at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff6bba0d6 in  () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x00007ffff69b6415 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007ffff4b38fa3 in start_thread (arg=<optimized out>)
    at pthread_create.c:486
        ret = <optimized out>
        pd = <optimized out>
        now = <optimized out>
        unwind_buf = {
          cancel_jmp_buf = {{
              jmp_buf = {140737209034496, -2332898995959237690,
140737488336926, 140737488336927, 140737209034496, 13323152,
2332932821804118982, 2332875456844002246},
              mask_was_saved = 0
            }},
          priv = {
            pad = {0x0, 0x0, 0x0, 0x0},
            data = {
              prev = 0x0,
              cleanup = 0x0,
              canceltype = 0
            }
          }
        }
        not_first_call = <optimized out>
#6  0x00007ffff49724cf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7ffff017d700 (LWP 26115)):
#0  0x00007ffff4967819 in __GI___poll (fds=0xb400d0, nfds=1, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:29
        resultvar = 18446744073709551100
        sc_cancel_oldtype = 0
#1  0x00007ffff698e136 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff698e25c in g_main_context_iteration ()
    at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff698e2a1 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007ffff69b6415 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007ffff4b38fa3 in start_thread (arg=<optimized out>)
    at pthread_create.c:486
        ret = <optimized out>
        pd = <optimized out>
        now = <optimized out>
        unwind_buf = {
          cancel_jmp_buf = {{
              jmp_buf = {140737221482240, -2332898995959237690,
140737488347710, 140737488347711, 140737221482240, 0,
2332865253915489222, 2332875456844002246},
              mask_was_saved = 0
            }},
          priv = {
            pad = {0x0, 0x0, 0x0, 0x0},
            data = {
              prev = 0x0,
              cleanup = 0x0,
              canceltype = 0
            }
          }
        }
        not_first_call = <optimized out>
#6  0x00007ffff49724cf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7ffff0e30e00 (LWP 26108)):
#0  0x00007ffff4b404c6 in pthread_sigmask
    (how=2, newmask=<optimized out>, oldmask=0x0)
    at ../sysdeps/unix/sysv/linux/pthread_sigmask.c:48
        local_newmask = {
          __val = {7, 17697270867008781056, 11498208, 5790296, 0,
140737488342800, 2, 0, 0, 0, 0, 0, 0, 0, 0, 6922490}
        }
        result = 0
#1  0x0000000000585a7d in restore_signal_mask (oldset=0x7fffffffcf10)
    at sysdep.c:876
#2  0x0000000000699292 in really_call_select (arg=0x7fffffffd060) at
thread.c:584
        sa = 0x7fffffffd060
        self = 0xa745c0 <main_thread>
        oldset = {
          __val = {0, 5710159, 8192, 126116988112, 140737488344608,
140737298839344, 7, 0, 11381952, 0, 8192, 1562936528, 140737488342720,
5968906924941129, 0, 16538645}
        }
#3  0x00000000005e5ee0 in flush_stack_call_func
    (func=0x699239 <really_call_select>, arg=0x7fffffffd060) at alloc.c:4969
        end = 0x7fffffffd020
        self = 0xa745c0 <main_thread>
        sentry = {
          o = {
            __max_align_ll = 0,
            __max_align_ld = <invalid float value>
          }
        }
#4  0x0000000000699389 in thread_select
    (func=0x419320 <pselect@plt>, max_fds=6, rfds=0x7fffffffd590,
wfds=0x7fffffffd510, efds=0x0, timeout=0x7fffffffd840, sigmask=0x0) at
thread.c:616
        sa = {
          func = 0x419320 <pselect@plt>,
          max_fds = 6,
          rfds = 0x7fffffffd590,
          wfds = 0x7fffffffd510,
          efds = 0x0,
          timeout = 0x7fffffffd840,
          sigmask = 0x0,
          result = -157757095
        }
#5  0x00000000006bfeac in xg_select
    (fds_lim=6, rfds=0x7fffffffd8e0, wfds=0x7fffffffd860, efds=0x0,
timeout=0x7fffffffd840, sigmask=0x0) at xgselect.c:117
        all_rfds = {
          fds_bits = {32, 0 <repeats 15 times>}
        }
        all_wfds = {
          fds_bits = {0 <repeats 16 times>}
        }
        tmo = {
          tv_sec = 5621546,
          tv_nsec = 15785445
        }
        tmop = 0x7fffffffd840
        context = 0xc1c200
        have_wfds = true
        gfds_buf = {{
            fd = 895,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 8096,
            events = 65535,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 16,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          } <repeats 11 times>, {
            fd = -2057698731,
            events = 39706,
            revents = 28662
          }, {
            fd = 3,
            events = 0,
            revents = 0
          }, {
            fd = -2057698731,
            events = 39706,
            revents = 28662
          }, {
            fd = -161788823,
            events = 32767,
            revents = 0
          }, {
            fd = -2057698731,
            events = 39642,
            revents = 28662
          }, {
            fd = -190624704,
            events = 32767,
            revents = 0
          }, {
            fd = 16,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = -664,
            events = 65535,
            revents = 65535
          }, {
            fd = -504530176,
            events = 22038,
            revents = 62873
          }, {
            fd = 12553216,
            events = 0,
            revents = 0
          }, {
            fd = -1252392363,
            events = 44399,
            revents = 28662
          }, {
            fd = 32,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 12553216,
            events = 0,
            revents = 0
          }, {
            fd = -191458327,
            events = 32767,
            revents = 0
          }, {
            fd = -190624704,
            events = 32767,
            revents = 0
          }, {
            fd = 139264,
            events = 0,
            revents = 0
          }, {
            fd = 17472,
            events = 0,
            revents = 0
          }, {
            fd = -191893943,
            events = 32767,
            revents = 0
          }, {
            fd = 128,
            events = 0,
            revents = 0
          }, {
            fd = -191909562,
            events = 32767,
            revents = 0
          }, {
            fd = 48,
            events = 0,
            revents = 0
          }, {
            fd = 1,
            events = 0,
            revents = 0
          }, {
            fd = 7,
            events = 0,
            revents = 0
          }, {
            fd = 64,
            events = 0,
            revents = 0
          }, {
            fd = 4,
            events = 32767,
            revents = 0
          }, {
            fd = 11649056,
            events = 0,
            revents = 0
          }, {
            fd = 47,
            events = 0,
            revents = 0
          }, {
            fd = 96,
            events = 0,
            revents = 0
          }, {
            fd = -664,
            events = 65535,
            revents = 65535
          }, {
            fd = 1,
            events = 0,
            revents = 0
          }, {
            fd = 4,
            events = 49,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 91,
            events = 110,
            revents = 0
          }, {
            fd = 124,
            events = 119,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 17456,
            events = 0,
            revents = 0
          }, {
            fd = -190624704,
            events = 32767,
            revents = 0
          }, {
            fd = 48,
            events = 0,
            revents = 0
          }, {
            fd = 2,
            events = 0,
            revents = 0
          }, {
            fd = -664,
            events = 65535,
            revents = 65535
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = -191900310,
            events = 32767,
            revents = 0
          }, {
            fd = -664,
            events = 65535,
            revents = 65535
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 48,
            events = 0,
            revents = 0
          }, {
            fd = 187264016,
            events = 0,
            revents = 0
          }, {
            fd = 11498208,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = -11392,
            events = 32767,
            revents = 0
          }, {
            fd = 5621546,
            events = 0,
            revents = 0
          }, {
            fd = 187264016,
            events = 0,
            revents = 0
          }, {
            fd = -11360,
            events = 32767,
            revents = 0
          }, {
            fd = 187280083,
            events = 0,
            revents = 0
          }, {
            fd = -11344,
            events = 32767,
            revents = 0
          }, {
            fd = 5622263,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 187280083,
            events = 0,
            revents = 0
          }, {
            fd = -11280,
            events = 32767,
            revents = 0
          }, {
            fd = 6170867,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 5627325,
            events = 0,
            revents = 0
          }, {
            fd = 6,
            events = 0,
            revents = 0
          }, {
            fd = 1,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 1,
            revents = 0
          }, {
            fd = 11498208,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = -11232,
            events = 32767,
            revents = 0
          }, {
            fd = 5621546,
            events = 0,
            revents = 0
          }, {
            fd = -134398935,
            events = 0,
            revents = 0
          }, {
            fd = -11200,
            events = 32767,
            revents = 0
          }, {
            fd = 187280099,
            events = 0,
            revents = 0
          }, {
            fd = -11184,
            events = 32767,
            revents = 0
          }, {
            fd = 5622263,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 187280099,
            events = 0,
            revents = 0
          }, {
            fd = -11120,
            events = 32767,
            revents = 0
          }, {
            fd = 6170867,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 5627325,
            events = 0,
            revents = 0
          }, {
            fd = 6,
            events = 0,
            revents = 0
          }, {
            fd = 1,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 1,
            revents = 0
          }, {
            fd = 11498208,
            events = 0,
            revents = 0
          }, {
            fd = 187280099,
            events = 0,
            revents = 0
          }, {
            fd = -11072,
            events = 32767,
            revents = 0
          }, {
            fd = 5622263,
            events = 0,
            revents = 0
          }, {
            fd = -11024,
            events = 32767,
            revents = 0
          }, {
            fd = -134398935,
            events = 32767,
            revents = 0
          }, {
            fd = -10944,
            events = 32767,
            revents = 0
          }, {
            fd = 15785445,
            events = 0,
            revents = 0
          }, {
            fd = -11016,
            events = 32767,
            revents = 0
          }, {
            fd = 5623097,
            events = 0,
            revents = 0
          }, {
            fd = 11498208,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          }, {
            fd = -10992,
            events = 32767,
            revents = 0
          }}
        gfds = 0x7fffffffd100
        gfds_size = 128
        n_gfds = -1
        retval = 0
        our_fds = 0
        max_fds = 5
        context_acquired = false
        i = 0
        nfds = 0
        tmo_in_millisec = 0
        must_free = 0
        need_to_dispatch = false
#6  0x000000000066b757 in wait_reading_process_output
    (time_limit=0, nsecs=0, read_kbd=-1, do_display=true,
wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at
process.c:5423
        process_skipped = false
        channel = 6
        nfds = 1
        Available = {
          fds_bits = {32, 0 <repeats 15 times>}
        }
        Writeok = {
          fds_bits = {0 <repeats 16 times>}
        }
        check_write = true
        check_delay = 0
        no_avail = false
        xerrno = 11
        proc = XIL(0xcf7c00)
        timeout = {
          tv_sec = 100000,
          tv_nsec = 0
        }
        end_time = {
          tv_sec = 0,
          tv_nsec = 140737488345168
        }
        timer_delay = {
          tv_sec = 0,
          tv_nsec = -1
        }
        got_output_end_time = {
          tv_sec = 0,
          tv_nsec = -1
        }
        wait = FOREVER
        got_some_output = -1
        prev_wait_proc_nbytes_read = 0
        retry_for_async = false
        count = 4
        now = {
          tv_sec = 0,
          tv_nsec = -1
        }
#7  0x000000000056c31e in kbd_buffer_get_event
    (kbp=0x7fffffffdbd8, used_mouse_menu=0x7fffffffe1bf, end_time=0x0)
    at keyboard.c:3836
        do_display = true
        obj = XIL(0x14bfd3fb)
#8  0x0000000000568706 in read_event_from_main_queue
    (end_time=0x0, local_getcjmp=0x7fffffffdf80, used_mouse_menu=0x7fffffffe1bf)
    at keyboard.c:2138
        c = XIL(0)
        save_jump = {{
            __jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0},
            __mask_was_saved = 0,
            __saved_mask = {
              __val = {0 <repeats 16 times>}
            }
          }}
        kb = 0x55c9f7 <XSETCDR+28>
        count = 3
#9  0x0000000000568970 in read_decoded_event_from_main_queue
    (end_time=0x0, local_getcjmp=0x7fffffffdf80, prev_event=XIL(0),
used_mouse_menu=0x7fffffffe1bf) at keyboard.c:2202
        nextevt = XIL(0x7fffffffde30)
        frame = 0x0
        terminal = 0x0
        events =
          {XIL(0x7fffffffddb0), make_fixnum(1422534), XIL(0xaf72e0),
XIL(0), XIL(0), XIL(0x7fffffffddb0), make_fixnum(1405386),
XIL(0x135b623), XIL(0x7fffffffddf0), make_fixnum(1420782),
XIL(0xaf72e0), XIL(0x100000000), XIL(0), XIL(0x7fffffffddf0),
make_fixnum(1405386), XIL(0)}
        n = 0
#10 0x000000000056a002 in read_char
    (commandflag=1, map=XIL(0xfbaa33), prev_event=XIL(0),
used_mouse_menu=0x7fffffffe1bf, end_time=0x0) at keyboard.c:2810
        c = XIL(0)
        jmpcount = 3
        local_getcjmp = {{
            __jmpbuf = {0, 2332898996579464134, 16538645, 48, 0, 0,
2332898994838827974, -2332899704998988858},
            __mask_was_saved = 0,
            __saved_mask = {
              __val = {140737214405912, 0, 140737225904168, 11498208,
0, 0, 140737488347152, 5621546, 4032516088, 11498208, 0, 0,
140737488347200, 5621546, 12363987, 140737488347296}
            }
          }}
        save_jump = {{
            __jmpbuf = {0, 0, 140737224472304, 0, 0, 11529984, 5621546, 0},
            __mask_was_saved = -8336,
            __saved_mask = {
              __val = {6254137, 140737231486936, 12884893472, 0,
31776, 140737224472304, 140737231486936, 5623453, 51539607552,
140737224472309, 140737224472304, 5632971, 11529984, 11529984, 0,
11498208}
            }
          }}
        tem = XIL(0x7fffefa759f0)
        save = XIL(0)
        previous_echo_area_message = XIL(0)
        also_record = XIL(0)
        reread = false
        recorded = false
        polling_stopped_here = true
        orig_kboard = 0xc863c0
#11 0x0000000000576842 in read_key_sequence
    (keybuf=0x7fffffffe3a0, prompt=XIL(0), dont_downcase_last=false,
can_return_switch_frame=true, fix_current_buffer=true,
prevent_redisplay=false)
    at keyboard.c:9124
        interrupted_kboard = 0xc863c0
        interrupted_frame = 0xf976a0
        key = XIL(0xf97ac0)
        used_mouse_menu = false
        echo_local_start = 0
        last_real_key_start = 0
        keys_local_start = 0
        new_binding = XIL(0xf97ac0)
        count = 3
        t = 0
        echo_start = 0
        keys_start = 0
        current_binding = XIL(0xfbaa33)
        first_unbound = 31
        mock_input = 0
        used_mouse_menu_history = {false <repeats 30 times>}
        fkey = {
          parent = XIL(0xbe3cd3),
          map = XIL(0xbe3cd3),
          start = 0,
          end = 0
        }
        keytran = {
          parent = XIL(0x7ffff0ae0eeb),
          map = XIL(0x7ffff0ae0eeb),
          start = 0,
          end = 0
        }
        indec = {
          parent = XIL(0xbe3cc3),
          map = XIL(0xbe3cc3),
          start = 0,
          end = 0
        }
        shift_translated = false
        delayed_switch_frame = XIL(0)
        original_uppercase = XIL(0)
        original_uppercase_position = -1
        dummyflag = false
        starting_buffer = 0x7ffff04576f0
        fake_prefixed_keys = XIL(0)
        first_event = XIL(0)
        second_event = XIL(0)
#12 0x00000000005667ae in command_loop_1 () at keyboard.c:1348
        cmd = XIL(0x7fffffffe4f0)
        keybuf =
          {XIL(0x7fffffffe420), XIL(0x7ffff0b08008), XIL(0x100000007),
XIL(0), XIL(0), XIL(0x80a0), XIL(0x11f), XIL(0xaff380), XIL(0xaff380),
XIL(0), XIL(0x7fffffffe440), XIL(0x617021), make_fixnum(1073741824),
XIL(0x7fffffffe460), XIL(0xaf72e0), XIL(0), XIL(0),
XIL(0x7fffffffe440), make_fixnum(1405386), XIL(0xf04576f5),
XIL(0x7fffffffe4a0), XIL(0x61729f), XIL(0xaf72e0), XIL(0), XIL(0),
XIL(0x7fffffffe480), make_fixnum(1405386), XIL(0xf04576f5),
XIL(0x7fffffffe4c0), make_fixnum(1591385)}
        i = 0
        prev_modiff = 0
        prev_buffer = 0x0
        already_adjusted = false
#13 0x0000000000611d61 in internal_condition_case
    (bfun=0x566384 <command_loop_1>, handlers=XIL(0x90), hfun=0x565b7d
<cmd_error>) at eval.c:1351
        val = make_fixnum(1405386)
        c = 0xb99e70
#14 0x000000000056607a in command_loop_2 (ignore=XIL(0)) at keyboard.c:1091
        val = XIL(0)
#15 0x000000000061161a in internal_catch
    (tag=XIL(0xd140), func=0x566051 <command_loop_2>, arg=XIL(0)) at eval.c:1112
        val = XIL(0x7fffffffe5c0)
        c = 0xb94fd0
#16 0x000000000056601c in command_loop () at keyboard.c:1070
#17 0x0000000000565752 in recursive_edit_1 () at keyboard.c:714
        count = 1
        val = XIL(0x7fffffffe620)
#18 0x00000000005658d4 in Frecursive_edit () at keyboard.c:786
        count = 0
        buffer = XIL(0)
#19 0x0000000000563961 in main (argc=4, argv=0x7fffffffe878) at emacs.c:2086
        stack_bottom_variable = 0x5e00
        do_initial_setlocale = true
        no_loadup = false
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x0
        original_pwd = 0x0
        dump_mode = 0x0
        skip_args = 0
        temacs = 0x0
        attempt_load_pdump = true
        rlim = {
          rlim_cur = 10022912,
          rlim_max = 18446744073709551615
        }
        sockfd = -1

i thr
  Id   Target Id                                        Frame
* 1    Thread 0x7ffff0e30e00 (LWP 26108) "emacs"        pthread_sigmask (how=0,
    newmask=<optimized out>, oldmask=0x7fffffffcf10)
    at ../sysdeps/unix/sysv/linux/pthread_sigmask.c:48
  2    Thread 0x7ffff017d700 (LWP 26115) "gmain"
0x00007ffff4967819 in __GI___poll (fds=0xb400d0, nfds=1, timeout=-1)
at ../sysdeps/unix/sysv/linux/poll.c:29
  3    Thread 0x7fffef59e700 (LWP 26116) "gdbus"
0x00007ffff4967819 in __GI___poll (fds=0xcb7a20, nfds=2, timeout=-1)
at ../sysdeps/unix/sysv/linux/poll.c:29
  4    Thread 0x7fffeeb8a700 (LWP 26117) "dconf worker"
0x00007ffff4967819 in __GI___poll (fds=0xd93070, nfds=1, timeout=-1)
at ../sysdeps/unix/sysv/linux/poll.c:29

> > Proposed patch attached.
>
> As I said earlier, I don't think it's right to use stack unwinding at
> this level.  (Did you try this in a -nw session?)

Sorry, I didn't see that email until after I'd sent mine. I did try
with an -nw session, now, but I really think thread_select should not
return abnormally.

> I'd appreciate a description of what you think happens here, and why.

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.

When xg_select() fails to acquire the internal GLib lock, it simply
does a select() on the remaining file descriptors:

  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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 13:31:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 09:31:53 2019
Received: from localhost ([127.0.0.1]:39385 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hlveT-0006Bz-Kv
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 09:31:53 -0400
Received: from eggs.gnu.org ([209.51.188.92]:42811)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hlveQ-0006Bk-PZ
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 09:31:51 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:40298)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hlveK-000686-HH; Fri, 12 Jul 2019 09:31:44 -0400
Received: from [176.228.60.248] (port=4353 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hlveE-0008KD-03; Fri, 12 Jul 2019 09:31:43 -0400
Date: Fri, 12 Jul 2019 16:31:24 +0300
Message-Id: <83ims72xcj.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-reply-to: <CAOqdjBe7RUWUpkW1NPnak_rY4B+3NkWUXYUK7S+kGicxp-q0pQ@HIDDEN>
 (message from Pip Cet on Fri, 12 Jul 2019 12:57:51 +0000)
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <83muhj2zmb.fsf@HIDDEN>
 <CAOqdjBe7RUWUpkW1NPnak_rY4B+3NkWUXYUK7S+kGicxp-q0pQ@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Pip Cet <pipcet@HIDDEN>
> Date: Fri, 12 Jul 2019 12:57:51 +0000
> Cc: politza@HIDDEN, 36609 <at> debbugs.gnu.org
> 
> Lisp Backtrace:
> "sleep-for" (0xedf7a530)
> 0xf6da40 Lisp type 3
> 
> post_acquire_global_lock () can return abnormally (I didn't know
> that), so really_call_select() can, too, so thread_select() can, too.

Do you know which code sets current_thread->error_symbol, and what is
that error symbol?

> > > +  ptrdiff_t count = SPECPDL_INDEX ();
> >
> > I don't think we should do that at this low level.
> 
> You're right, it does stick out. I think we're safe because we're
> calling Fsignal with the global lock held, but it's not a pretty or
> well-documented situation.

Is this the main thread which does that?  if so, there should be no
problem with holding the global lock in this case, is there?

If this is not the main thread, then the error handlers should be set
so as to log the error in last_thread_error, and then terminate the
thread (via exiting the thread function, AFAIR).

If this is not what happens, I'd like to know what does happen here,
and why.

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 12:58:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 08:58:36 2019
Received: from localhost ([127.0.0.1]:39366 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hlv8G-0005PE-Dr
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 08:58:36 -0400
Received: from mail-oi1-f173.google.com ([209.85.167.173]:36508)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <pipcet@HIDDEN>) id 1hlv8E-0005P1-G4
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 08:58:35 -0400
Received: by mail-oi1-f173.google.com with SMTP id w7so7199496oic.3
 for <36609 <at> debbugs.gnu.org>; Fri, 12 Jul 2019 05:58:34 -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=FNu3Mbi68by3G5rUEgKAu7KRrqoiBdql1+72xqNJFx0=;
 b=tmV0ZhYgeHTPlkXOXqjOtBrOe9KPlKvyA4+t69q7zbYdBipHQCLPT3rGasHUh1BW6w
 cyPirBAwdWJ+ED0rfmcQEqh86IqlzIuWitpKh2qviQ0gfTpAhr7Bq0ssEy7fnVzi3zgc
 NWQUnnTJuyQL/LyNyL4dVy9t/Rj4OJHoxHY6Xk06OyRlu9njTvMAhuKt3cDxgtvbA04F
 lSEA0fPsBqr9norFwEbejUOqHm0KVpeKWh4mNWbqiOY7084gpGQmawu7Sw2supl1OWG3
 Wb0rsoNfnBDDKE8932lV2DknQD58gTheQtwYHRSiyuTg5lwSvJ4IwQfPJT5sPcGXUDw4
 7Uiw==
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=FNu3Mbi68by3G5rUEgKAu7KRrqoiBdql1+72xqNJFx0=;
 b=NKZBTyceG19clhJ0g7mw/CrokUbeAVlfYwfzpqAhviiFeG/IVHvfkcjXp8PuhjrMgP
 +v9LsBXj9CGCEK3wMl4AAPAF9UoIEjSxK5goxXl3JtCSMPhd79plrOD9y7AE3zY8eM5R
 qKcqtytuKPhRAc1ahpuWrqngmBlImOXqhx/v3zF329hMx4j/sgKYT8rYwYqEqDFK1qRh
 pu9YNAysSFiY1yjvqJx5ZDjbPB69BKWBEP7SKFfmzFfYC2oq9DbyhWf45KNPEyuGhjZ2
 T7NyXtKzHee0g8JmoM4CKytAlUmNit5Y2cdJi2QXCrIOGHbDeShM1Q195JmAzor5BTzL
 tHFw==
X-Gm-Message-State: APjAAAXGi9vyPcIqOEEO39F4TZ18J6btkKPi5yoIyLowSzNNqiOPzDdo
 WLMHGvA1ryMwsxG5WZCzkDU5s4oxVvIezJb2bj0=
X-Google-Smtp-Source: APXvYqx+Knc8NnxqIYypOyc5OuNwpoKWETAMFN3vC+8jOpreHyk1YAUveMGKdRxcK00fUEuAG7Pu/c3ckGhVEXzYfdw=
X-Received: by 2002:aca:aa93:: with SMTP id t141mr5873315oie.128.1562936308527; 
 Fri, 12 Jul 2019 05:58:28 -0700 (PDT)
MIME-Version: 1.0
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <83muhj2zmb.fsf@HIDDEN>
In-Reply-To: <83muhj2zmb.fsf@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Date: Fri, 12 Jul 2019 12:57:51 +0000
Message-ID: <CAOqdjBe7RUWUpkW1NPnak_rY4B+3NkWUXYUK7S+kGicxp-q0pQ@HIDDEN>
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On Fri, Jul 12, 2019 at 12:42 PM Eli Zaretskii <eliz@HIDDEN> wrote:
>
> > From: Pip Cet <pipcet@HIDDEN>
> > Date: Fri, 12 Jul 2019 09:02:22 +0000
> > Cc: 36609 <at> debbugs.gnu.org
> >
> > On Thu, Jul 11, 2019 at 8:52 PM Andreas Politz
> > <politza@HIDDEN> wrote:
> > > I think there is a race-condition in the implementation of threads.  I
> > > tried to find a minimal test-case, without success.  Thus, I've attached
> > > a lengthy source-file.  Loading that file should trigger this bug and
> > > may freeze your session.
> >
> > It does here, so I can provide further debugging information if
> > needed.
>
> Thanks, can you provide the info I asked for?

Yes, albeit not right now.

> > On first glance, it appears that xgselect returns abnormally with
> > g_main_context acquired in one thread, and then other threads fail
> > to acquire it and loop endlessly.
>
> If you can describe what causes this to happen, I think we might be
> half-way to a solution.

Here's the backtrace of the abnormal exit I see with the patch attached:


(gdb) bt full
#0  0x00000000006bf987 in release_g_main_context (ptr=0xc1d070) at xgselect.c:36
        context = 0x7fffedf79710
#1  0x0000000000616f03 in do_one_unbind
    (this_binding=0x7fffedf79770, unwinding=true, bindflag=SET_INTERNAL_UNBIND)
    at eval.c:3446
#2  0x0000000000617245 in unbind_to (count=0, value=XIL(0)) at eval.c:3567
        this_binding = {
          kind = SPECPDL_UNWIND_PTR,
          unwind = {
            kind = SPECPDL_UNWIND_PTR,
            func = 0x6bf97b <release_g_main_context>,
            arg = XIL(0xc1d070),
            eval_depth = 0
          },
          unwind_array = {
            kind = SPECPDL_UNWIND_PTR,
            nelts = 7076219,
            array = 0xc1d070
          },
          unwind_ptr = {
            kind = SPECPDL_UNWIND_PTR,
            func = 0x6bf97b <release_g_main_context>,
            arg = 0xc1d070
          },
          unwind_int = {
            kind = SPECPDL_UNWIND_PTR,
            func = 0x6bf97b <release_g_main_context>,
            arg = 12701808
          },
          unwind_excursion = {
            kind = SPECPDL_UNWIND_PTR,
            marker = XIL(0x6bf97b),
            window = XIL(0xc1d070)
          },
          unwind_void = {
            kind = SPECPDL_UNWIND_PTR,
            func = 0x6bf97b <release_g_main_context>
          },
          let = {
            kind = SPECPDL_UNWIND_PTR,
            symbol = XIL(0x6bf97b),
            old_value = XIL(0xc1d070),
            where = XIL(0),
            saved_value = XIL(0xef26a0)
          },
          bt = {
            kind = SPECPDL_UNWIND_PTR,
            debug_on_exit = false,
            function = XIL(0x6bf97b),
            args = 0xc1d070,
            nargs = 0
          }
        }
        quitf = XIL(0)
#3  0x00000000006116df in unwind_to_catch
    (catch=0x7fffd8000c50, type=NONLOCAL_EXIT_SIGNAL, value=XIL(0x14d3653))
    at eval.c:1162
        last_time = false
#4  0x00000000006126d9 in signal_or_quit
    (error_symbol=XIL(0x90), data=XIL(0), keyboard_quit=false) at eval.c:1674
        unwind_data = XIL(0x14d3653)
        conditions = XIL(0x7ffff05d676b)
        string = XIL(0x5f5e77)
        real_error_symbol = XIL(0x90)
        clause = XIL(0x30)
        h = 0x7fffd8000c50
#5  0x00000000006122e9 in Fsignal (error_symbol=XIL(0x90), data=XIL(0))
    at eval.c:1564
#6  0x0000000000698901 in post_acquire_global_lock (self=0xe09db0) at
thread.c:115
        sym = XIL(0x90)
        data = XIL(0)
        prev_thread = 0xa745c0 <main_thread>
#7  0x000000000069892b in acquire_global_lock (self=0xe09db0) at thread.c:123
#8  0x0000000000699303 in really_call_select (arg=0x7fffedf79a70) at
thread.c:596
        sa = 0x7fffedf79a70
        self = 0xe09db0
        oldset = {
          __val = {0, 0, 7, 0, 80, 140736817269952, 2031, 2080,
18446744073709550952, 32, 343597383808, 4, 0, 472446402655,
511101108348, 0}
        }
#9  0x00000000005e5ee0 in flush_stack_call_func
    (func=0x699239 <really_call_select>, arg=0x7fffedf79a70) at alloc.c:4969
        end = 0x7fffedf79a30
        self = 0xe09db0
        sentry = {
          o = {
            __max_align_ll = 0,
            __max_align_ld = <invalid float value>
          }
        }
#10 0x0000000000699389 in thread_select
    (func=0x419320 <pselect@plt>, max_fds=9, rfds=0x7fffedf79fa0,
wfds=0x7fffedf79f20, efds=0x0, timeout=0x7fffedf7a260, sigmask=0x0) at
thread.c:616
        sa = {
          func = 0x419320 <pselect@plt>,
          max_fds = 9,
          rfds = 0x7fffedf79fa0,
          wfds = 0x7fffedf79f20,
          efds = 0x0,
          timeout = 0x7fffedf7a260,
          sigmask = 0x0,
          result = 1
        }
#11 0x00000000006bfef5 in xg_select
    (fds_lim=9, rfds=0x7fffedf7a300, wfds=0x7fffedf7a280, efds=0x0,
timeout=0x7fffedf7a260, sigmask=0x0) at xgselect.c:130
        all_rfds = {
          fds_bits = {8, 0 <repeats 15 times>}
        }
        all_wfds = {
          fds_bits = {0 <repeats 16 times>}
        }
        tmo = {
          tv_sec = 0,
          tv_nsec = 0
        }
        tmop = 0x7fffedf7a260
        context = 0xc1d070
        have_wfds = true
        gfds_buf = {{
            fd = 5,
            events = 1,
            revents = 0
          }, {
            fd = 6,
            events = 1,
            revents = 0
          }, {
            fd = 8,
            events = 1,
            revents = 0
          }, {
            fd = 0,
            events = 0,
            revents = 0
          } <repeats 125 times>}
        gfds = 0x7fffedf79b10
        gfds_size = 128
        n_gfds = 3
        retval = 0
        our_fds = 0
        max_fds = 8
        context_acquired = true
        i = 3
        nfds = 0
        tmo_in_millisec = -1
        must_free = 0
        need_to_dispatch = false
        count = 3
#12 0x000000000066b757 in wait_reading_process_output
    (time_limit=3, nsecs=0, read_kbd=0, do_display=false,
wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at
process.c:5423
        process_skipped = false
        channel = 0
        nfds = 0
        Available = {
          fds_bits = {8, 0 <repeats 15 times>}
        }
        Writeok = {
          fds_bits = {0 <repeats 16 times>}
        }
        check_write = true
        check_delay = 0
        no_avail = false
        xerrno = 0
        proc = XIL(0x7fffedf7a440)
        timeout = {
          tv_sec = 3,
          tv_nsec = 0
        }
        end_time = {
          tv_sec = 1562935633,
          tv_nsec = 911868453
        }
        timer_delay = {
          tv_sec = 0,
          tv_nsec = -1
        }
        got_output_end_time = {
          tv_sec = 0,
          tv_nsec = -1
        }
        wait = TIMEOUT
        got_some_output = -1
        prev_wait_proc_nbytes_read = 0
        retry_for_async = false
        count = 2
        now = {
          tv_sec = 0,
          tv_nsec = -1
        }
#13 0x0000000000429bf6 in Fsleep_for (seconds=make_fixnum(3),
milliseconds=XIL(0))
    at dispnew.c:5825
        t = {
          tv_sec = 3,
          tv_nsec = 0
        }
        tend = {
          tv_sec = 1562935633,
          tv_nsec = 911868112
        }
        duration = 3
#14 0x0000000000613e99 in eval_sub (form=XIL(0xf6df73)) at eval.c:2273
        i = 2
        maxargs = 2
        args_left = XIL(0)
        numargs = 1
        original_fun = XIL(0x7fffefa9fb98)
        original_args = XIL(0xf6df83)
        count = 1
        fun = XIL(0xa756a5)
        val = XIL(0)
        funcar = make_fixnum(35184372085343)
        argvals =
          {make_fixnum(3), XIL(0), XIL(0), XIL(0), XIL(0), XIL(0),
XIL(0), XIL(0)}
#15 0x0000000000610032 in Fprogn (body=XIL(0)) at eval.c:462
        form = XIL(0xf6df73)
        val = XIL(0)
#16 0x0000000000616102 in funcall_lambda
    (fun=XIL(0xf6da43), nargs=0, arg_vector=0xe09dd8) at eval.c:3065
        val = XIL(0xc0)
        syms_left = XIL(0)
        next = XIL(0x3400000013)
        lexenv = XIL(0)
        count = 1
        i = 0
        optional = false
        rest = false
#17 0x0000000000615542 in Ffuncall (nargs=1, args=0xe09dd0) at eval.c:2813
        fun = XIL(0xf6da43)
        original_fun = XIL(0xf6da43)
        funcar = XIL(0xc0)
        numargs = 0
        val = XIL(0xaf72e0)
        count = 0
#18 0x000000000069956f in invoke_thread_function () at thread.c:702
        count = 0
#19 0x0000000000611d61 in internal_condition_case
    (bfun=0x69953e <invoke_thread_function>, handlers=XIL(0x30),
hfun=0x699596 <record_thread_error>) at eval.c:1351
        val = make_fixnum(1405386)
        c = 0x7fffd8000c50
#20 0x0000000000699697 in run_thread (state=0xe09db0) at thread.c:741
        stack_pos = {
          __max_align_ll = 0,
          __max_align_ld = 0
        }
        self = 0xe09db0
        iter = 0x0
        c = 0x7fffd8000b20
#21 0x00007ffff4b38fa3 in start_thread (arg=<optimized out>)
    at pthread_create.c:486
        ret = <optimized out>
        pd = <optimized out>
        now = <optimized out>
        unwind_buf = {
          cancel_jmp_buf = {{
              jmp_buf = {140737185822464, -1249422724209328276,
140737488341374, 140737488341375, 140737185822464, 0,
1249453444682727276, 1249398985402204012},
              mask_was_saved = 0
            }},
          priv = {
            pad = {0x0, 0x0, 0x0, 0x0},
            data = {
              prev = 0x0,
              cleanup = 0x0,
              canceltype = 0
            }
          }
        }
        not_first_call = <optimized out>
#22 0x00007ffff49724cf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Lisp Backtrace:
"sleep-for" (0xedf7a530)
0xf6da40 Lisp type 3

post_acquire_global_lock () can return abnormally (I didn't know
that), so really_call_select() can, too, so thread_select() can, too.

> > +  ptrdiff_t count = SPECPDL_INDEX ();
>
> I don't think we should do that at this low level.

You're right, it does stick out. I think we're safe because we're
calling Fsignal with the global lock held, but it's not a pretty or
well-documented situation.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 12:55:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 08:55:41 2019
Received: from localhost ([127.0.0.1]:39362 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hlv5Q-0005LK-QS
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 08:55:41 -0400
Received: from eggs.gnu.org ([209.51.188.92]:60393)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hlv5O-0005L6-6R
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 08:55:38 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:39596)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hlv5I-00079S-F8; Fri, 12 Jul 2019 08:55:32 -0400
Received: from [176.228.60.248] (port=2170 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hlv5H-0006cs-Bp; Fri, 12 Jul 2019 08:55:31 -0400
Date: Fri, 12 Jul 2019 15:55:22 +0300
Message-Id: <83k1cn2z0l.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-reply-to: <CAOqdjBcNVU0C2TEjbR4UZ4QX-j=oR27YdGHNgL01RPfPUBQdSA@HIDDEN>
 (message from Pip Cet on Fri, 12 Jul 2019 12:44:35 +0000)
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 <CAOqdjBcNVU0C2TEjbR4UZ4QX-j=oR27YdGHNgL01RPfPUBQdSA@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Pip Cet <pipcet@HIDDEN>
> Date: Fri, 12 Jul 2019 12:44:35 +0000
> Cc: 36609 <at> debbugs.gnu.org
> 
> Okay, I'm still not sure this is really the problem Andreas was
> seeing, but this code fails to work with xg_select:
> 
> (let ((thread (make-thread (lambda ()
>                  (sleep-for 3)))))
>   (thread-yield)
>   (thread-signal thread 'error nil))

What do you mean by "fails"?  What do you see when you eval this?

> Proposed patch attached.

As I said earlier, I don't think it's right to use stack unwinding at
this level.  (Did you try this in a -nw session?)

I'd appreciate a description of what you think happens here, and why.

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 12:45:21 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 08:45:21 2019
Received: from localhost ([127.0.0.1]:39358 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hluvQ-00057X-Lu
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 08:45:20 -0400
Received: from mail-oi1-f172.google.com ([209.85.167.172]:43439)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <pipcet@HIDDEN>) id 1hluvO-00057H-PU
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 08:45:19 -0400
Received: by mail-oi1-f172.google.com with SMTP id w79so7163388oif.10
 for <36609 <at> debbugs.gnu.org>; Fri, 12 Jul 2019 05:45:18 -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=W9Fh52n93BAaOZXJPz2/3ms5OSpST+RP++o0J5Lljzg=;
 b=tnYilC2okzQbS6vZ88wKrfFLlBoT8VL6rswycjoEXe5r+GVyrZQ5NgfKPZSD6t5yzT
 3cu87Zbb7lo+dxJrhTd4YksO4jhvfahhRHdDbWqw0bVe7cbHcKEf54jwk8YKCIMfxhY+
 D441QqdBPRktnUthN1zSC7pyXJ74ev9rz/wW7wQzMXOvpmfOTvlzjhjIrnUNo8LsHMWm
 lQOg6LaWOTTYvq/etzqSIO73z4Gy3D434IQW+gvrUElP6oOkyssh4WhmNfmnpyGCpfcP
 KeEol0PHykVBwSk/dnaNKO1md8fZL5s3Pn9zLWFQmeaLyMlX0byFHPLZYC0U7mMRytDg
 PLDw==
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=W9Fh52n93BAaOZXJPz2/3ms5OSpST+RP++o0J5Lljzg=;
 b=E/6sY8jYDWmMXh67weRMAYJNhSIZdgT/IyurmPJE/a4dNJZME9g5r2E5fjc8DHXBBF
 LXz30kx1iEHrBt0umq0zaOWV2xMspA9SaBIcMTDOYpY38xPoLXo7qiwh2yQd/0N9Nk/Q
 u5E8eZnIiJKqmwCf1nZSysyaCWzzNyQ3NrzUlRod2CNR6iQy8yCiHMTLsivmPv+eQbvc
 Pypch4LzfxHotoJ9TQqDWUqQzVwqH9S4dmpAnipx9b79ibj94AU5OMYrgi8ujeViHMSn
 A/NwvE7j4b8925KSEIHc+3q5qmtDHcU6+ojQUwWOI95KF5Qluy7F45Hc15rmbir0Ysv8
 kNWQ==
X-Gm-Message-State: APjAAAWWV6VpvBSCPusdU+jMZzUl43MFGtsMH7ma9cSioG0puvRpUlWc
 JueXn/Myk+vz6LJImJtpjEnPotn3wLgz4rAp+s8=
X-Google-Smtp-Source: APXvYqwwGkgsiBXtUK7ILtr2AeUfaOD0ArWxcag1Ayb3SUS5SqJb1TZIIYsFOC+vqiqdtdzCd1d9kYfXmmYsG6df/64=
X-Received: by 2002:aca:4790:: with SMTP id u138mr6064676oia.44.1562935513113; 
 Fri, 12 Jul 2019 05:45:13 -0700 (PDT)
MIME-Version: 1.0
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
In-Reply-To: <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Date: Fri, 12 Jul 2019 12:44:35 +0000
Message-ID: <CAOqdjBcNVU0C2TEjbR4UZ4QX-j=oR27YdGHNgL01RPfPUBQdSA@HIDDEN>
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
To: Andreas Politz <politza@HIDDEN>
Content-Type: multipart/mixed; boundary="00000000000011070b058d7b485c"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--00000000000011070b058d7b485c
Content-Type: text/plain; charset="UTF-8"

On Fri, Jul 12, 2019 at 9:02 AM Pip Cet <pipcet@HIDDEN> wrote:
>
> On Thu, Jul 11, 2019 at 8:52 PM Andreas Politz
> <politza@HIDDEN> wrote:
> > I think there is a race-condition in the implementation of threads.  I
> > tried to find a minimal test-case, without success.  Thus, I've attached
> > a lengthy source-file.  Loading that file should trigger this bug and
> > may freeze your session.
>
> It does here, so I can provide further debugging information if
> needed. On first glance, it appears that xgselect returns abnormally
> with g_main_context acquired in one thread, and then other threads
> fail to acquire it and loop endlessly.

Okay, I'm still not sure this is really the problem Andreas was
seeing, but this code fails to work with xg_select:

(let ((thread (make-thread (lambda ()
                 (sleep-for 3)))))
  (thread-yield)
  (thread-signal thread 'error nil))

Proposed patch attached.

--00000000000011070b058d7b485c
Content-Type: text/x-patch; charset="US-ASCII"; 
	name="0001-Protect-against-abnormal-exit-in-xg_select.patch"
Content-Disposition: attachment; 
	filename="0001-Protect-against-abnormal-exit-in-xg_select.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_jy03fdfy0>
X-Attachment-Id: f_jy03fdfy0

RnJvbSAwMTIzNDFhOGE2NzRiMTMwYzMzNWNmZGQ4ZDI0ODg4NDA2ZTk4ZWNlIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBQaXAgQ2V0IDxwaXBjZXRAZ21haWwuY29tPgpEYXRlOiBGcmks
IDEyIEp1bCAyMDE5IDEyOjM5OjI5ICswMDAwClN1YmplY3Q6IFtQQVRDSF0gUHJvdGVjdCBhZ2Fp
bnN0IGFibm9ybWFsIGV4aXQgaW4gYHhnX3NlbGVjdCcKCiogc3JjL3hnc2VsZWN0LmMgKHJlbGVh
c2VfZ19tYWluX2NvbnRleHQpOiBOZXcgZnVuY3Rpb24uCih4Z19zZWxlY3QpOiBVbndpbmQtcHJv
dGVjdCByZWxlYXNlIG9mIHRoZSBHTGliIG1haW4gY29udGV4dC4KLS0tCiBzcmMveGdzZWxlY3Qu
YyB8IDE4ICsrKysrKysrKysrKysrKy0tLQogMSBmaWxlIGNoYW5nZWQsIDE1IGluc2VydGlvbnMo
KyksIDMgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvc3JjL3hnc2VsZWN0LmMgYi9zcmMveGdz
ZWxlY3QuYwppbmRleCA5OTgyYTFmMGU5Li5lMzUzMTBiZTM0IDEwMDY0NAotLS0gYS9zcmMveGdz
ZWxlY3QuYworKysgYi9zcmMveGdzZWxlY3QuYwpAQCAtMjksNiArMjksMTUgQEAgQ29weXJpZ2h0
IChDKSAyMDA5LTIwMTkgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCiAjaW5jbHVkZSAi
YmxvY2tpbnB1dC5oIgogI2luY2x1ZGUgInN5c3RpbWUuaCIKIAorLyogSGVscGVyIGZ1bmN0aW9u
IGZvciBgdW53aW5kX3Byb3RlY3QnLiAgKi8KKworc3RhdGljIHZvaWQgcmVsZWFzZV9nX21haW5f
Y29udGV4dCAodm9pZCAqcHRyKQoreworICBHTWFpbkNvbnRleHQgKmNvbnRleHQgPSAoR01haW5D
b250ZXh0ICopIHB0cjsKKworICBnX21haW5fY29udGV4dF9yZWxlYXNlIChjb250ZXh0KTsKK30K
KwogLyogYHhnX3NlbGVjdCcgaXMgYSBgcHNlbGVjdCcgcmVwbGFjZW1lbnQuICBXaHkgZG8gd2Ug
bmVlZCBhIHNlcGFyYXRlIGZ1bmN0aW9uPwogICAgMS4gVGltZW91dHMuICBHbGliIGFuZCBHdGsg
cmVseSBvbiB0aW1lciBldmVudHMuICBJZiB3ZSBkaWQgcHNlbGVjdAogICAgICAgd2l0aCBhIGdy
ZWF0ZXIgdGltZW91dCB0aGVuIHRoZSBvbmUgc2NoZWR1bGVkIGJ5IEdsaWIsIHdlIHdvdWxkCkBA
IC01OCw4ICs2NywxMiBAQCB4Z19zZWxlY3QgKGludCBmZHNfbGltLCBmZF9zZXQgKnJmZHMsIGZk
X3NldCAqd2ZkcywgZmRfc2V0ICplZmRzLAogICBpbnQgaSwgbmZkcywgdG1vX2luX21pbGxpc2Vj
LCBtdXN0X2ZyZWUgPSAwOwogICBib29sIG5lZWRfdG9fZGlzcGF0Y2g7CiAKKyAgcHRyZGlmZl90
IGNvdW50ID0gU1BFQ1BETF9JTkRFWCAoKTsKICAgY29udGV4dCA9IGdfbWFpbl9jb250ZXh0X2Rl
ZmF1bHQgKCk7CiAgIGNvbnRleHRfYWNxdWlyZWQgPSBnX21haW5fY29udGV4dF9hY3F1aXJlIChj
b250ZXh0KTsKKworICBpZiAoY29udGV4dF9hY3F1aXJlZCkKKyAgICByZWNvcmRfdW53aW5kX3By
b3RlY3RfcHRyIChyZWxlYXNlX2dfbWFpbl9jb250ZXh0LCAodm9pZCAqKWNvbnRleHQpOwogICAv
KiBGSVhNRTogSWYgd2UgY291bGRuJ3QgYWNxdWlyZSB0aGUgY29udGV4dCwgd2UganVzdCBzaWxl
bnRseSBwcm9jZWVkCiAgICAgIGJlY2F1c2UgdGhpcyBmdW5jdGlvbiBoYW5kbGVzIG1vcmUgdGhh
biBqdXN0IGdsaWIgZmlsZSBkZXNjcmlwdG9ycy4KICAgICAgTm90ZSB0aGF0LCBhcyBpbXBsZW1l
bnRlZCwgdGhpcyBmYWlsdXJlIGlzIGNvbXBsZXRlbHkgc2lsZW50OiB0aGVyZSBpcwpAQCAtMTY0
LDkgKzE3Nyw2IEBAIHhnX3NlbGVjdCAoaW50IGZkc19saW0sIGZkX3NldCAqcmZkcywgZmRfc2V0
ICp3ZmRzLCBmZF9zZXQgKmVmZHMsCiAgICAgICBlcnJubyA9IHBzZWxlY3RfZXJybm87CiAgICAg
fQogCi0gIGlmIChjb250ZXh0X2FjcXVpcmVkKQotICAgIGdfbWFpbl9jb250ZXh0X3JlbGVhc2Ug
KGNvbnRleHQpOwotCiAgIC8qIFRvIG5vdCBoYXZlIHRvIHJlY2FsY3VsYXRlIHRpbWVvdXQsIHJl
dHVybiBsaWtlIHRoaXMuICAqLwogICBpZiAoKG91cl9mZHMgPiAwIHx8IChuZmRzID09IDAgJiYg
dG1vcCA9PSAmdG1vKSkgJiYgKHJldHZhbCA9PSAwKSkKICAgICB7CkBAIC0xNzQsNiArMTg0LDgg
QEAgeGdfc2VsZWN0IChpbnQgZmRzX2xpbSwgZmRfc2V0ICpyZmRzLCBmZF9zZXQgKndmZHMsIGZk
X3NldCAqZWZkcywKICAgICAgIGVycm5vID0gRUlOVFI7CiAgICAgfQogCisgIHVuYmluZF90byAo
Y291bnQsIFFuaWwpOworCiAgIHJldHVybiByZXR2YWw7CiB9CiAjZW5kaWYgLyogSEFWRV9HTElC
ICovCi0tIAoyLjIwLjEKCg==
--00000000000011070b058d7b485c--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 12:42:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 08:42:47 2019
Received: from localhost ([127.0.0.1]:39354 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hlusu-00053E-Fa
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 08:42:46 -0400
Received: from eggs.gnu.org ([209.51.188.92]:56822)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hlusr-00052y-JQ
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 08:42:42 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:39469)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hlusf-0004xT-NW; Fri, 12 Jul 2019 08:42:30 -0400
Received: from [176.228.60.248] (port=1368 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hluse-0005ZJ-9p; Fri, 12 Jul 2019 08:42:29 -0400
Date: Fri, 12 Jul 2019 15:42:20 +0300
Message-Id: <83muhj2zmb.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-reply-to: <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
 (message from Pip Cet on Fri, 12 Jul 2019 09:02:22 +0000)
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
References: <87muhks3b5.fsf@HIDDEN>
 <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org, politza@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Pip Cet <pipcet@HIDDEN>
> Date: Fri, 12 Jul 2019 09:02:22 +0000
> Cc: 36609 <at> debbugs.gnu.org
> 
> On Thu, Jul 11, 2019 at 8:52 PM Andreas Politz
> <politza@HIDDEN> wrote:
> > I think there is a race-condition in the implementation of threads.  I
> > tried to find a minimal test-case, without success.  Thus, I've attached
> > a lengthy source-file.  Loading that file should trigger this bug and
> > may freeze your session.
> 
> It does here, so I can provide further debugging information if
> needed.

Thanks, can you provide the info I asked for?

> On first glance, it appears that xgselect returns abnormally with
> g_main_context acquired in one thread, and then other threads fail
> to acquire it and loop endlessly.

If you can describe what causes this to happen, I think we might be
half-way to a solution.

> +  ptrdiff_t count = SPECPDL_INDEX ();

I don't think we should do that at this low level.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 09:03:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 05:03:06 2019
Received: from localhost ([127.0.0.1]:39262 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hlrSL-0006AM-Tr
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 05:03:06 -0400
Received: from mail-ot1-f45.google.com ([209.85.210.45]:41116)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <pipcet@HIDDEN>) id 1hlrSK-00069q-Ow
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 05:03:05 -0400
Received: by mail-ot1-f45.google.com with SMTP id o101so8756205ota.8
 for <36609 <at> debbugs.gnu.org>; Fri, 12 Jul 2019 02:03:04 -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=zHNRHJZaWTM5dTYtOB/B5Za/6ari5HWZ1jXI1ST8Yjw=;
 b=pCWJnDp/bLStE+HqQE3vLbgo54LG3Fax/vfmD2jBtGlVt+vyb8gbHNeTTg9i02fMI1
 kX+HizPuW3jPTmnuLh2Z7AUMt/PdL3+9H6oUiDKJVlRB6XRu6wJ0XEQYvchGoxYdySmi
 mqr+wq2+i6qyd9OocSQv62vj9vg+j0DjBQgB30rF41Tj3q9YJSTv3OMLdDUwcFZbf8PD
 ja6OK3OfRqotfc528Zpn6asQxLlh/7/Ww30t2fk+DftyqFCRcsl+kJSI/wZQ/woIcFCp
 4/TD/0hymryAnpTL9amfrrSux5nL4Oo0OloSnu7ApulkQ7d3H+SlfR+sVRKrAZmRetcX
 ubqA==
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=zHNRHJZaWTM5dTYtOB/B5Za/6ari5HWZ1jXI1ST8Yjw=;
 b=NVELFlAWlsy9H0o2GjBVKEA474yMHersLU/R0enbz9HAR7bBFiqTL1SDb4FxiGoF+d
 4MPfjS7M4pZd2+RwIqzkisrgR/hxguO9m14XOta3oZ7GxRC+IW89I0uyLf24gbheKVIc
 MHQqRogymQiN/DBlJ3CFLQf6h78+g/Kz3F9Y8LA5gRn+0lV0z52iSC3JZcr90dW3SvC/
 4p/EX8PwQOTekoOFDCe7LNLH4jD3cVnhuBxPdJk6FUVM/ib+p3YjmvFMYWynv9Gqq+AU
 t4dw8QGS2E0p7rJ0bUeYVVmQznt4LFQq9h65FOVbq8pjwFh2x1PwbDCupKMlWimxKdiG
 6k6Q==
X-Gm-Message-State: APjAAAUCj336JHxdkVZgJTxT/znCi2BkSOiiXHxwWezIqsjl5nCTESiq
 gZY1iZGiZcsNg415xhh95mxS3WfPBacb4kD3kZQ=
X-Google-Smtp-Source: APXvYqwzbQ1xMNFHmIESl33pt2Lh3LFxcxHMkHdU195gFNfW5yUwK6G5mlCGpczahJ11ZC5otLWzof2Hy54tP5/qmrY=
X-Received: by 2002:a9d:6014:: with SMTP id h20mr7548994otj.210.1562922179063; 
 Fri, 12 Jul 2019 02:02:59 -0700 (PDT)
MIME-Version: 1.0
References: <87muhks3b5.fsf@HIDDEN>
In-Reply-To: <87muhks3b5.fsf@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Date: Fri, 12 Jul 2019 09:02:22 +0000
Message-ID: <CAOqdjBcQfjX-kZqimq7xUOk+oq+cNCf_1hiOfCFHL37dY9WaWg@HIDDEN>
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
To: Andreas Politz <politza@HIDDEN>
Content-Type: multipart/mixed; boundary="0000000000004bed0f058d782d6c"
X-Spam-Score: 1.3 (+)
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 Thu, Jul 11, 2019 at 8:52 PM Andreas Politz wrote: > I
 think there is a race-condition in the implementation of threads. I > tried
 to find a minimal test-case, without success. Thus, I've attache [...] 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was
 blocked.  See
 http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
 for more information. [URIs: hochschule-trier.de]
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (pipcet[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [209.85.210.45 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [209.85.210.45 listed in wl.mailspike.net]
 1.3 PDS_NO_HELO_DNS        High profile HELO but no A record
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

--0000000000004bed0f058d782d6c
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 11, 2019 at 8:52 PM Andreas Politz
<politza@HIDDEN> wrote:
> I think there is a race-condition in the implementation of threads.  I
> tried to find a minimal test-case, without success.  Thus, I've attached
> a lengthy source-file.  Loading that file should trigger this bug and
> may freeze your session.

It does here, so I can provide further debugging information if
needed. On first glance, it appears that xgselect returns abnormally
with g_main_context acquired in one thread, and then other threads
fail to acquire it and loop endlessly.

Can you confirm that this very dirty patch avoids (it's not a fix by
any means!) the problem?

--0000000000004bed0f058d782d6c
Content-Type: text/x-patch; charset="US-ASCII"; name="Avoid-glib-issue.patch"
Content-Disposition: attachment; filename="Avoid-glib-issue.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_jxzvh69j0>
X-Attachment-Id: f_jxzvh69j0

ZGlmZiAtLWdpdCBhL3NyYy94Z3NlbGVjdC5jIGIvc3JjL3hnc2VsZWN0LmMKaW5kZXggOTk4MmEx
ZjBlOS4uOWZmZWI2YzY2YyAxMDA2NDQKLS0tIGEvc3JjL3hnc2VsZWN0LmMKKysrIGIvc3JjL3hn
c2VsZWN0LmMKQEAgLTU4LDggKzU4LDE2IEBAIHhnX3NlbGVjdCAoaW50IGZkc19saW0sIGZkX3Nl
dCAqcmZkcywgZmRfc2V0ICp3ZmRzLCBmZF9zZXQgKmVmZHMsCiAgIGludCBpLCBuZmRzLCB0bW9f
aW5fbWlsbGlzZWMsIG11c3RfZnJlZSA9IDA7CiAgIGJvb2wgbmVlZF90b19kaXNwYXRjaDsKIAor
ICBwdHJkaWZmX3QgY291bnQgPSBTUEVDUERMX0lOREVYICgpOwogICBjb250ZXh0ID0gZ19tYWlu
X2NvbnRleHRfZGVmYXVsdCAoKTsKLSAgY29udGV4dF9hY3F1aXJlZCA9IGdfbWFpbl9jb250ZXh0
X2FjcXVpcmUgKGNvbnRleHQpOworICBjb250ZXh0X2FjcXVpcmVkID0gdHJ1ZTsKKworICBhdXRv
IHZvaWQgcmVsZWFzZV9nX21haW5fY29udGV4dCAodm9pZCkKKyAgeworICB9CisKKyAgaWYgKGNv
bnRleHRfYWNxdWlyZWQpCisgICAgcmVjb3JkX3Vud2luZF9wcm90ZWN0X3ZvaWQgKHJlbGVhc2Vf
Z19tYWluX2NvbnRleHQpOwogICAvKiBGSVhNRTogSWYgd2UgY291bGRuJ3QgYWNxdWlyZSB0aGUg
Y29udGV4dCwgd2UganVzdCBzaWxlbnRseSBwcm9jZWVkCiAgICAgIGJlY2F1c2UgdGhpcyBmdW5j
dGlvbiBoYW5kbGVzIG1vcmUgdGhhbiBqdXN0IGdsaWIgZmlsZSBkZXNjcmlwdG9ycy4KICAgICAg
Tm90ZSB0aGF0LCBhcyBpbXBsZW1lbnRlZCwgdGhpcyBmYWlsdXJlIGlzIGNvbXBsZXRlbHkgc2ls
ZW50OiB0aGVyZSBpcwpAQCAtMTY0LDkgKzE3Miw2IEBAIHhnX3NlbGVjdCAoaW50IGZkc19saW0s
IGZkX3NldCAqcmZkcywgZmRfc2V0ICp3ZmRzLCBmZF9zZXQgKmVmZHMsCiAgICAgICBlcnJubyA9
IHBzZWxlY3RfZXJybm87CiAgICAgfQogCi0gIGlmIChjb250ZXh0X2FjcXVpcmVkKQotICAgIGdf
bWFpbl9jb250ZXh0X3JlbGVhc2UgKGNvbnRleHQpOwotCiAgIC8qIFRvIG5vdCBoYXZlIHRvIHJl
Y2FsY3VsYXRlIHRpbWVvdXQsIHJldHVybiBsaWtlIHRoaXMuICAqLwogICBpZiAoKG91cl9mZHMg
PiAwIHx8IChuZmRzID09IDAgJiYgdG1vcCA9PSAmdG1vKSkgJiYgKHJldHZhbCA9PSAwKSkKICAg
ICB7CkBAIC0xNzQsNiArMTc5LDYgQEAgeGdfc2VsZWN0IChpbnQgZmRzX2xpbSwgZmRfc2V0ICpy
ZmRzLCBmZF9zZXQgKndmZHMsIGZkX3NldCAqZWZkcywKICAgICAgIGVycm5vID0gRUlOVFI7CiAg
ICAgfQogCi0gIHJldHVybiByZXR2YWw7CisgIHJldHVybiB1bmJpbmRfdG8gKGNvdW50LCBRbmls
KSwgcmV0dmFsOwogfQogI2VuZGlmIC8qIEhBVkVfR0xJQiAqLwo=
--0000000000004bed0f058d782d6c--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 08:05:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 04:05:25 2019
Received: from localhost ([127.0.0.1]:39236 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hlqYW-0004qe-Q5
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 04:05:25 -0400
Received: from eggs.gnu.org ([209.51.188.92]:35239)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hlqYV-0004qT-IS
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 04:05:24 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:51518)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hlqYQ-0002gu-18; Fri, 12 Jul 2019 04:05:18 -0400
Received: from [176.228.60.248] (port=4400 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hlqYO-0002F2-UF; Fri, 12 Jul 2019 04:05:17 -0400
Date: Fri, 12 Jul 2019 11:05:08 +0300
Message-Id: <83o91z3cgb.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: politza@HIDDEN
In-reply-to: <83sgrb3d9i.fsf@HIDDEN> (message from Eli Zaretskii on Fri, 12
 Jul 2019 10:47:37 +0300)
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
References: <87muhks3b5.fsf@HIDDEN> <83sgrb3d9i.fsf@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Fri, 12 Jul 2019 10:47:37 +0300
> From: Eli Zaretskii <eliz@HIDDEN>
> Cc: 36609 <at> debbugs.gnu.org
> 
> Please describe what this program tries to accomplish, and how.  It's
> not easy to reverse-engineer that from 200 lines of non-trivial code.
> It's possible that the reason(s) for the freeze will be apparent from
> describing your implementation ideas.

Oh, and one more question: does the value of the global variable
last_thread_error tell something interesting at that point?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at 36609 <at> debbugs.gnu.org:


Received: (at 36609) by debbugs.gnu.org; 12 Jul 2019 07:47:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 12 03:47:54 2019
Received: from localhost ([127.0.0.1]:39209 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hlqHa-0004QE-9P
	for submit <at> debbugs.gnu.org; Fri, 12 Jul 2019 03:47:54 -0400
Received: from eggs.gnu.org ([209.51.188.92]:58219)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1hlqHZ-0004Q1-1T
 for 36609 <at> debbugs.gnu.org; Fri, 12 Jul 2019 03:47:53 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:51268)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hlqHT-0003HY-5Y; Fri, 12 Jul 2019 03:47:47 -0400
Received: from [176.228.60.248] (port=3167 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1hlqHS-0001aW-J9; Fri, 12 Jul 2019 03:47:47 -0400
Date: Fri, 12 Jul 2019 10:47:37 +0300
Message-Id: <83sgrb3d9i.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Andreas Politz <politza@HIDDEN>
In-reply-to: <87muhks3b5.fsf@HIDDEN> (message from Andreas Politz
 on Thu, 11 Jul 2019 22:51:10 +0200)
Subject: Re: bug#36609: 27.0.50;
 Possible race-condition in threading implementation
References: <87muhks3b5.fsf@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 36609
Cc: 36609 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Andreas Politz <politza@HIDDEN>
> Date: Thu, 11 Jul 2019 22:51:10 +0200
> 
> I think there is a race-condition in the implementation of threads.

Not sure what you mean by "race condition".  Since only one Lisp
thread can run at any given time, where could this race happen, and
between what threads?

> I tried to find a minimal test-case, without success.  Thus, I've
> attached a lengthy source-file.  Loading that file should trigger
> this bug and may freeze your session.

FWIW, it doesn't freeze my Emacs here, neither on GNU/Linux nor on
MS-Windows (with today's master).  Are you getting freezes with 100%
reproducibility?  If so, please show all the details of your build, as
collected by report-emacs-bug.

> Indications:
> 
> 1. The main-thread has the name of one of created threads (XEmacs in
>    this case), instead of "emacs".

I don't think this is related to the problem.  I think we have a bug
in the implementation of the 'name' attribute of threads: we call
prctl(PR_SET_NAME), which AFAIU changes the name of the _calling_
thread, and the calling thread at that point is the main thread, see
sys_thread_create.  If I evaluate this:

  (make-thread 'ignore "XEmacs")

and then attach a debugger, I see that the name of the main thread has
changed to "XEmacs".

> 2. Emacs stops processing all keyboard/mouse input while looping in
>    wait_reading_process_output.  Sending commands via emacsclient still
>    works.
> 
> GDB output:
> 
> (gdb) info threads
>   Id   Target Id                                        Frame 
> * 1    Thread 0x7ffff17f5d40 (LWP 26264) "XEmacs"       0x000055555576eac0 in XPNTR (a=XIL(0x7ffff1312533)) at alloc.c:535
>   2    Thread 0x7ffff0ac4700 (LWP 26265) "gmain"        0x00007ffff50d1667 in poll () from /usr/lib/libc.so.6
>   3    Thread 0x7fffebd1a700 (LWP 26266) "gdbus"        0x00007ffff50d1667 in poll () from /usr/lib/libc.so.6
>   4    Thread 0x7fffeb519700 (LWP 26267) "dconf worker" 0x00007ffff50d1667 in poll () from /usr/lib/libc.so.6
> 
> (gdb) bt full

This "bt full" is not enough, because it shows the backtrace of one
thread only, the main thread.  Please show the backtrace of the other
3 threads by typing "thread apply all bt full" instead.

> #5  0x0000555555802a78 in wait_reading_process_output (time_limit=0, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at process.c:5423
>         process_skipped = false
>         channel = 6
>         nfds = 1
>         Available = {
>           fds_bits = {32, 0 <repeats 15 times>}
>         }

Is the keyboard descriptor's bit in Available set or not?  What is the
contents of the fd_callback_info array at this point?

> ;; -*- lexical-binding: t -*-
> 
> (require 'threads)
> (require 'eieio)
> (require 'cl-lib)
> (require 'ring)
> 
> (defun debug (fmt &rest args)
>   (princ (apply #'format fmt args) #'external-debugging-output)
>   (terpri #'external-debugging-output))

Please describe what this program tries to accomplish, and how.  It's
not easy to reverse-engineer that from 200 lines of non-trivial code.
It's possible that the reason(s) for the freeze will be apparent from
describing your implementation ideas.

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 11 Jul 2019 20:51:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 11 16:51:29 2019
Received: from localhost ([127.0.0.1]:38869 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hlg2J-0007gl-CP
	for submit <at> debbugs.gnu.org; Thu, 11 Jul 2019 16:51:28 -0400
Received: from lists.gnu.org ([209.51.188.17]:59292)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <politza@HIDDEN>) id 1hlg2G-0007gU-UW
 for submit <at> debbugs.gnu.org; Thu, 11 Jul 2019 16:51:26 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:40206)
 by lists.gnu.org with esmtp (Exim 4.86_2)
 (envelope-from <politza@HIDDEN>) id 1hlg2E-00053k-Am
 for bug-gnu-emacs@HIDDEN; Thu, 11 Jul 2019 16:51:24 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_MED,
 URIBL_BLOCKED autolearn=disabled version=3.3.2
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <politza@HIDDEN>) id 1hlg2A-00065P-Ak
 for bug-gnu-emacs@HIDDEN; Thu, 11 Jul 2019 16:51:21 -0400
Received: from gateway-a.fh-trier.de ([143.93.54.181]:54341)
 by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <politza@HIDDEN>)
 id 1hlg29-0005yw-CE
 for bug-gnu-emacs@HIDDEN; Thu, 11 Jul 2019 16:51:18 -0400
X-Virus-Scanned: by Amavisd-new + Sophos + ClamAV [Rechenzentrum Hochschule
 Trier (RZ/HT)]
Received: from localhost (x4db620d5.dyn.telefonica.de [77.182.32.213])
 (using TLSv1 with cipher AES256-SHA (256/256 bits))
 (No client certificate requested) (Authenticated sender: politza)
 by gateway-a.fh-trier.de (Postfix) with ESMTPSA id 66AD81871025
 for <bug-gnu-emacs@HIDDEN>; Thu, 11 Jul 2019 22:51:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=hochschule-trier.de;
 s=default; t=1562878271; bh=qnSNCUGUemvWSuEgtb8ZRHp0aC4=;
 h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type;
 b=WhZyrWX+pA5/+f8avRJmMYOeB8cHhcHVAjXk18QrzXRbj8ypbLEUZjITUr0ZVXlSN
 NGe4RssFYiry81j46DmN11GLQSTjZQh3tWLWSfxJkHBOxtbnhWleQm3FSE5xoKblt+
 zgiPxlJeVkxXzKMuKTDHbs33HMdbpKbCprg5FIH8=
From: Andreas Politz <politza@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 27.0.50; Possible race-condition in threading implementation
Date: Thu, 11 Jul 2019 22:51:10 +0200
Message-ID: <87muhks3b5.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 143.93.54.181
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

--=-=-=
Content-Type: text/plain


I think there is a race-condition in the implementation of threads.  I
tried to find a minimal test-case, without success.  Thus, I've attached
a lengthy source-file.  Loading that file should trigger this bug and
may freeze your session.  

Indications:

1. The main-thread has the name of one of created threads (XEmacs in
   this case), instead of "emacs".

2. Emacs stops processing all keyboard/mouse input while looping in
   wait_reading_process_output.  Sending commands via emacsclient still
   works.

GDB output:

(gdb) info threads
  Id   Target Id                                        Frame 
* 1    Thread 0x7ffff17f5d40 (LWP 26264) "XEmacs"       0x000055555576eac0 in XPNTR (a=XIL(0x7ffff1312533)) at alloc.c:535
  2    Thread 0x7ffff0ac4700 (LWP 26265) "gmain"        0x00007ffff50d1667 in poll () from /usr/lib/libc.so.6
  3    Thread 0x7fffebd1a700 (LWP 26266) "gdbus"        0x00007ffff50d1667 in poll () from /usr/lib/libc.so.6
  4    Thread 0x7fffeb519700 (LWP 26267) "dconf worker" 0x00007ffff50d1667 in poll () from /usr/lib/libc.so.6

(gdb) bt full
#0  0x00007ffff50d3f76 in pselect () at /usr/lib/libc.so.6
#1  0x0000555555832e48 in really_call_select (arg=0x7fffffffd150) at thread.c:586
        sa = 0x7fffffffd150
        self = 0x555555c154e0 <main_thread>
        oldset = {
          __val = {0, 93825011232085, 140737488343064, 31632, 31632, 51840, 140737488343136, 93824994672716, 4294967298, 140737488343184, 93824999850720, 0, 0, 140737488343136, 93824993869565, 4041340661}
        }
#2  0x0000555555774449 in flush_stack_call_func (func=0x555555832d81 <really_call_select>, arg=0x7fffffffd150) at alloc.c:4969
        end = 0x7fffffffd100
        self = 0x555555c154e0 <main_thread>
        sentry = {
          o = {
            __max_align_ll = 140737488343296, 
            __max_align_ld = <invalid float value>
          }
        }
#3  0x0000555555832f40 in thread_select (func=0x7ffff50d3eb0 <pselect>, max_fds=6, rfds=0x7fffffffd260, wfds=0x7fffffffd2e0, efds=0x0, timeout=0x7fffffffd8b0, sigmask=0x0) at thread.c:616
        sa = {
          func = 0x7ffff50d3eb0 <pselect>, 
          max_fds = 6, 
          rfds = 0x7fffffffd260, 
          wfds = 0x7fffffffd2e0, 
          efds = 0x0, 
          timeout = 0x7fffffffd8b0, 
          sigmask = 0x0, 
          result = 210347336
        }
#4  0x000055555585fea3 in xg_select (fds_lim=6, rfds=0x7fffffffd920, wfds=0x7fffffffd9a0, efds=0x0, timeout=0x7fffffffd8b0, sigmask=0x0) at xgselect.c:117
        all_rfds = {
          fds_bits = {32, 0 <repeats 15 times>}
        }
        all_wfds = {
          fds_bits = {0 <repeats 16 times>}
        }
        tmo = {
          tv_sec = 7, 
          tv_nsec = 140737488343264
        }
        tmop = 0x7fffffffd8b0
        context = 0x555555dae320
        have_wfds = true
        gfds_buf = {{
            fd = 0, 
            events = 0, 
            revents = 0
          }, {
            fd = 32, 
            events = 0, 
            revents = 0
          }, {
            fd = 0, 
            events = 0, 
            revents = 0
          }, {
            fd = 7, 
            events = 0, 
            revents = 0
          }, {
            fd = 8, 
            events = 0, 
            revents = 0
          }, {
            fd = 15, 
            events = 0, 
            revents = 0
          }, {
            fd = -11072, 
            events = 32767, 
            revents = 0
          }, {
            fd = 1460278864, 
            events = 21845, 
            revents = 0
          }, {
            fd = 64, 
            events = 0, 
            revents = 0
          }, {
            fd = 0, 
            events = 0, 
            revents = 0
          }, {
            fd = 2, 
            events = 48, 
            revents = 0
          }, {
            fd = 0, 
            events = 0, 
            revents = 0
          }, {
            fd = 91, 
            events = 124, 
            revents = 0
          }, {
            fd = -397131776, 
            events = 35414, 
            revents = 11125
          }, {
            fd = 1460278864, 
            events = 21845, 
            revents = 0
          }, {
            fd = 1, 
            events = 0, 
            revents = 0
          }, {
            fd = 2, 
            events = 0, 
            revents = 0
          }, {
            fd = -11072, 
            events = 32767, 
            revents = 0
          }, {
            fd = 1439161536, 
            events = 21845, 
            revents = 0
          }, {
            fd = -11024, 
            events = 32767, 
            revents = 0
          }, {
            fd = -11088, 
            events = 32767, 
            revents = 0
          }, {
            fd = -182671191, 
            events = 32767, 
            revents = 0
          }, {
            fd = 1, 
            events = 0, 
            revents = 0
          }, {
            fd = -182670875, 
            events = 32767, 
            revents = 0
          }, {
            fd = 194871296, 
            events = 59160, 
            revents = 48198
          }, {
            fd = -1175563804, 
            events = 19, 
            revents = 0
          }, {
            fd = 24, 
            events = 0, 
            revents = 0
          }, {
            fd = 1460278864, 
            events = 21845, 
            revents = 0
          }, {
            fd = 2, 
            events = 0, 
            revents = 0
          }, {
            fd = 1439882448, 
            events = 21845, 
            revents = 0
          }, {
            fd = 2, 
            events = 0, 
            revents = 0
          }, {
            fd = 2, 
            events = 0, 
            revents = 0
          }, {
            fd = 1, 
            events = 2, 
            revents = 0
          }, {
            fd = 1460278864, 
            events = 21845, 
            revents = 0
          }, {
            fd = 0, 
            events = 0, 
            revents = 0
          }, {
            fd = -397131776, 
            events = 35414, 
            revents = 11125
          }, {
            fd = 24, 
            events = 0, 
            revents = 0
          }, {
            fd = 1439161536, 
            events = 21845, 
            revents = 0
          }, {
            fd = 2, 
            events = 0, 
            revents = 0
          }, {
            fd = 1, 
            events = 0, 
            revents = 0
          }, {
            fd = 1439161536, 
            events = 21845, 
            revents = 0
          }, {
            fd = -182606722, 
            events = 32767, 
            revents = 0
          }, {
            fd = -10960, 
            events = 32767, 
            revents = 0
          }, {
            fd = 1433487750, 
            events = 21845, 
            revents = 0
          }, {
            fd = -10976, 
            events = 32767, 
            revents = 0
          }, {
            fd = 1439161536, 
            events = 21845, 
            revents = 0
          }, {
            fd = -30, 
            events = 0, 
            revents = 0
          }, {
            fd = 1, 
            events = 0, 
            revents = 0
          }, {
            fd = 1, 
            events = 64, 
            revents = 0
          }, {
            fd = 1562877925, 
            events = 0, 
            revents = 0
          }, {
            fd = 31, 
            events = 0, 
            revents = 0
          }, {
            fd = 1562877925, 
            events = 0, 
            revents = 0
          }, {
            fd = -10960, 
            events = 32767, 
            revents = 0
          }, {
            fd = 1434542700, 
            events = 21845, 
            revents = 0
          }, {
            fd = -10912, 
            events = 32767, 
            revents = 0
          }, {
            fd = 1439161536, 
            events = 21845, 
            revents = 0
          }, {
            fd = 1562877925, 
            events = 0, 
            revents = 0
          }, {
            fd = -397131776, 
            events = 35414, 
            revents = 11125
          }, {
            fd = -10848, 
            events = 32767, 
            revents = 0
          }, {
            fd = 1434543288, 
            events = 21845, 
            revents = 0
          }, {
            fd = 1460274293, 
            events = 21845, 
            revents = 0
          }, {
            fd = 1385447426, 
            events = 931, 
            revents = 0
          }, {
            fd = 95390, 
            events = 0, 
            revents = 0
          }, {
            fd = 1433865373, 
            events = 7256, 
            revents = 10134
          }, {
            fd = 1562877925, 
            events = 0, 
            revents = 0
          }, {
            fd = 1439161536, 
            events = 21845, 
            revents = 0
          }, {
            fd = 664149, 
            events = 0, 
            revents = 0
          }, {
            fd = 80000, 
            events = 0, 
            revents = 0
          }, {
            fd = 1562877925, 
            events = 0, 
            revents = 0
          }, {
            fd = 664149080, 
            events = 0, 
            revents = 0
          }, {
            fd = 1562877925, 
            events = 0, 
            revents = 0
          }, {
            fd = 664149080, 
            events = 0, 
            revents = 0
          }, {
            fd = -10752, 
            events = 32767, 
            revents = 0
          }, {
            fd = 1434543494, 
            events = 21845, 
            revents = 0
          }, {
            fd = 0, 
            events = 0, 
            revents = 0
          }, {
            fd = -10544, 
            events = 32767, 
            revents = 0
          }, {
            fd = 499622378, 
            events = 0, 
            revents = 0
          }, {
            fd = 0, 
            events = 0, 
            revents = 0
          }, {
            fd = 0, 
            events = 0, 
            revents = 0
          }, {
            fd = 499622378, 
            events = 0, 
            revents = 0
          }, {
            fd = -10688, 
            events = 32767, 
            revents = 0
          }, {
            fd = 1434939197, 
            events = 21845, 
            revents = 0
          }, {
            fd = 1562877925, 
            events = 0, 
            revents = 0
          }, {
            fd = 164526702, 
            events = 0, 
            revents = 0
          }, {
            fd = 1562877925, 
            events = 0, 
            revents = 0
          }, {
            fd = 664149080, 
            events = 0, 
            revents = 0
          }, {
            fd = -10544, 
            events = 32767, 
            revents = 0
          }, {
            fd = 499622378, 
            events = 41450, 
            revents = 7623
          }, {
            fd = 0, 
            events = 0, 
            revents = 0
          }, {
            fd = 1562877925, 
            events = 0, 
            revents = 0
          }, {
            fd = 0, 
            events = 0, 
            revents = 0
          }, {
            fd = -1, 
            events = 65535, 
            revents = 65535
          }, {
            fd = -10432, 
            events = 32767, 
            revents = 0
          }, {
            fd = 1433359581, 
            events = 21845, 
            revents = 0
          }, {
            fd = 0, 
            events = 0, 
            revents = 0
          }, {
            fd = 0, 
            events = 0, 
            revents = 0
          }, {
            fd = 0, 
            events = 0, 
            revents = 0
          }, {
            fd = 1443725184, 
            events = 85, 
            revents = 0
          }, {
            fd = 1450650965, 
            events = 21845, 
            revents = 0
          }, {
            fd = 1450650965, 
            events = 21845, 
            revents = 0
          }, {
            fd = 0, 
            events = 0, 
            revents = 0
          }, {
            fd = 16384, 
            events = 0, 
            revents = 0
          }, {
            fd = 5, 
            events = 0, 
            revents = 0
          }, {
            fd = -10496, 
            events = 32767, 
            revents = 0
          }, {
            fd = 0, 
            events = 0, 
            revents = 0
          }, {
            fd = -1, 
            events = 65535, 
            revents = 65535
          }, {
            fd = 1562877925, 
            events = 0, 
            revents = 0
          }, {
            fd = 164526702, 
            events = 0, 
            revents = 0
          }, {
            fd = 719, 
            events = 0, 
            revents = 0
          }, {
            fd = 893997157, 
            events = 0, 
            revents = 0
          }, {
            fd = 1439269600, 
            events = 21845, 
            revents = 0
          }, {
            fd = 0, 
            events = 0, 
            revents = 0
          }, {
            fd = 0, 
            events = 0, 
            revents = 0
          }, {
            fd = -10496, 
            events = 32767, 
            revents = 0
          }, {
            fd = 1433288445, 
            events = 21845, 
            revents = 0
          }, {
            fd = 0, 
            events = 0, 
            revents = 0
          }, {
            fd = 164532384, 
            events = 0, 
            revents = 0
          }, {
            fd = 1562977925, 
            events = 0, 
            revents = 0
          }, {
            fd = 1562977925, 
            events = 0, 
            revents = 0
          }, {
            fd = 164532384, 
            events = 0, 
            revents = 0
          }, {
            fd = -10368, 
            events = 32767, 
            revents = 0
          }, {
            fd = 1434938909, 
            events = 21845, 
            revents = 0
          }, {
            fd = 100000, 
            events = 0, 
            revents = 0
          }, {
            fd = 0, 
            events = 0, 
            revents = 0
          }, {
            fd = 1562877925, 
            events = 0, 
            revents = 0
          }, {
            fd = 164532384, 
            events = 0, 
            revents = 0
          }, {
            fd = -1, 
            events = 65535, 
            revents = 65535
          }, {
            fd = 0, 
            events = 0, 
            revents = 0
          }}
        gfds = 0x7fffffffd360
        gfds_size = 128
        n_gfds = -1
        retval = 0
        our_fds = 0
        max_fds = 5
        context_acquired = false
        i = 0
        nfds = 135
        tmo_in_millisec = 1030
        must_free = 0
        need_to_dispatch = false
#5  0x0000555555802a78 in wait_reading_process_output (time_limit=0, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at process.c:5423
        process_skipped = false
        channel = 6
        nfds = 1
        Available = {
          fds_bits = {32, 0 <repeats 15 times>}
        }
        Writeok = {
          fds_bits = {0 <repeats 16 times>}
        }
        check_write = true
        check_delay = 0
        no_avail = false
        xerrno = 11
        proc = XIL(0x7fffffffd9a0)
        timeout = {
          tv_sec = 0, 
          tv_nsec = 499622378
        }
        end_time = {
          tv_sec = 93824993869565, 
          tv_nsec = 0
        }
        timer_delay = {
          tv_sec = 0, 
          tv_nsec = 499622378
        }
        got_output_end_time = {
          tv_sec = 1562977205, 
          tv_nsec = 270561059
        }
        wait = FOREVER
        got_some_output = -1
        prev_wait_proc_nbytes_read = 0
        retry_for_async = false
        count = 4
        now = {
          tv_sec = 0, 
          tv_nsec = -1
        }
#6  0x00005555556f4718 in kbd_buffer_get_event (kbp=0x7fffffffdc70, used_mouse_menu=0x7fffffffe235, end_time=0x0) at keyboard.c:3836
        do_display = true
        obj = make_fixnum(1073741816)
#7  0x00005555556f06c5 in read_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffe040, used_mouse_menu=0x7fffffffe235) at keyboard.c:2138
        c = XIL(0)
        save_jump = {{
            __jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, 
            __mask_was_saved = 0, 
            __saved_mask = {
              __val = {0 <repeats 16 times>}
            }
          }}
        kb = 0x7fffffffdcd0
        count = 3
#8  0x00005555556f099b in read_decoded_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffe040, prev_event=XIL(0), used_mouse_menu=0x7fffffffe235) at keyboard.c:2202
        nextevt = XIL(0)
        frame = 0x1dcd30d9
        terminal = 0x9
        events = {XIL(0), XIL(0x1dcd30d9), XIL(0xca80), XIL(0x2b758a56e8544000), XIL(0), XIL(0x555556772ff5), XIL(0x7fffffffde50), XIL(0x5555556f57d8), XIL(0x555555c982e0), XIL(0), XIL(0), XIL(0x7fffffffde50), XIL(0x5555556e3efd), XIL(0x1dcd30d9), XIL(0x7fffffffde90), XIL(0x5555556f3b29)}
        n = 0
#9  0x00005555556f2236 in read_char (commandflag=1, map=XIL(0x5555567756e3), prev_event=XIL(0), used_mouse_menu=0x7fffffffe235, end_time=0x0) at keyboard.c:2810
        c = XIL(0)
        jmpcount = 3
        local_getcjmp = {{
            __jmpbuf = {0, -245616553674816983, 93825011232757, 51840, 0, 0, -245616553305718231, -6214351577293929943}, 
            __mask_was_saved = 0, 
            __saved_mask = {
              __val = {0, 0, 140737488347312, 93824993869565, 0, 140737488347424, 93824994673374, 93825011242707, 3, 0, 0, 140737488347424, 93824994446493, 93824999850720, 0, 0}
            }
          }}
        save_jump = {{
            __jmpbuf = {93824993869565, 0, 140737488347584, 93824994020698, 0, 51840, -1, 0}, 
            __mask_was_saved = 1450661587, 
            __saved_mask = {
              __val = {93825011242723, 140737488347520, 93824993870282, 93825011242707, 93825011242723, 140737488347584, 93824994446493, 93824999885184, 34464, 34464, 140737488347584, 93824993869565, 40105367251, 93825004306304, 140737488347624, 93824999850720}
            }
          }}
        tem = XIL(0x2aaa9b29c970)
        save = XIL(0)
        previous_echo_area_message = XIL(0)
        also_record = XIL(0)
        reread = false
        recorded = false
        polling_stopped_here = true
        orig_kboard = 0x555555dfa570
#10 0x00005555556ff6c8 in read_key_sequence (keybuf=0x7fffffffe440, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9124
        interrupted_kboard = 0x555555dfa570
        interrupted_frame = 0x5555560d7f80
        key = XIL(0x5555557a7eff)
        used_mouse_menu = false
        echo_local_start = 0
        last_real_key_start = 0
        keys_local_start = 0
        new_binding = XIL(0x7fffffffe310)
        count = 3
        t = 0
        echo_start = 0
        keys_start = 0
        current_binding = XIL(0x5555567756e3)
        first_unbound = 31
        mock_input = 0
        used_mouse_menu_history = {false <repeats 30 times>}
        fkey = {
          parent = XIL(0x555555d6ce03), 
          map = XIL(0x555555d6ce03), 
          start = 0, 
          end = 0
        }
        keytran = {
          parent = XIL(0x7ffff14a7dbb), 
          map = XIL(0x7ffff14a7dbb), 
          start = 0, 
          end = 0
        }
        indec = {
          parent = XIL(0x555555d6cdf3), 
          map = XIL(0x555555d6cdf3), 
          start = 0, 
          end = 0
        }
        shift_translated = false
        delayed_switch_frame = XIL(0)
        original_uppercase = XIL(0)
        original_uppercase_position = -1
        dummyflag = false
        starting_buffer = 0x7ffff0e1f6f0
        fake_prefixed_keys = XIL(0)
        first_event = XIL(0)
        second_event = XIL(0)
#11 0x00005555556ee5fb in command_loop_1 () at keyboard.c:1348
        cmd = XIL(0)
        keybuf = {XIL(0x7fffffffe490), XIL(0x5555557a804c), make_fixnum(11545945833472), XIL(0x7fffffffe4c0), XIL(0x555555c982e0), XIL(0), XIL(0), XIL(0x7fffffffe490), XIL(0x5555556e3efd), XIL(0xf0e1f6f5), XIL(0x7fffffffe500), make_fixnum(23456248668343), XIL(0x555555d18953), XIL(0x3), XIL(0x555555c982e0), XIL(0), XIL(0), XIL(0x7fffffffe4e0), XIL(0x5555556e3efd), XIL(0xf0e1f6f5), XIL(0x7fffffffe520), XIL(0x5555557a2e69), XIL(0x1556e3efd), XIL(0x5760), XIL(0x7fffffffe540), XIL(0x555555d53470), XIL(0), XIL(0), XIL(0x7fffffffe550), make_fixnum(23456248662876)}
        i = 32767
        prev_modiff = 0
        prev_buffer = 0x0
        already_adjusted = false
#12 0x00005555557a2a64 in internal_condition_case (bfun=0x5555556ee1b3 <command_loop_1>, handlers=XIL(0x5760), hfun=0x5555556ed968 <cmd_error>) at eval.c:1351
        val = XIL(0x5555556e3efd)
        c = 0x555555d53470
#13 0x00005555556ede9b in command_loop_2 (ignore=XIL(0)) at keyboard.c:1091
        val = XIL(0)
#14 0x00005555557a22d5 in internal_catch (tag=XIL(0xd110), func=0x5555556ede6e <command_loop_2>, arg=XIL(0)) at eval.c:1112
        val = XIL(0x45b00000000)
        c = 0x555555d53340
#15 0x00005555556ede39 in command_loop () at keyboard.c:1070
#16 0x00005555556ed537 in recursive_edit_1 () at keyboard.c:714
        count = 1
        val = make_fixnum(23456248667937)
#17 0x00005555556ed6bb in Frecursive_edit () at keyboard.c:786
        count = 0
        buffer = XIL(0)
#18 0x00005555556eb49d in main (argc=4, argv=0x7fffffffe8b8) at emacs.c:2086
        stack_bottom_variable = 0x20
        do_initial_setlocale = true
        no_loadup = false
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x0
        original_pwd = 0x0
        dump_mode = 0x0
        skip_args = 0
        temacs = 0x0
        attempt_load_pdump = true
        rlim = {
          rlim_cur = 10022912, 
          rlim_max = 18446744073709551615
        }
        sockfd = -1


--=-=-=
Content-Type: text/plain
Content-Disposition: attachment; filename=thread-bug-2.el
Content-Description: thread-bug-2.el

;; -*- lexical-binding: t -*-

(require 'threads)
(require 'eieio)
(require 'cl-lib)
(require 'ring)

(defun debug (fmt &rest args)
  (princ (apply #'format fmt args) #'external-debugging-output)
  (terpri #'external-debugging-output))

(define-error 'thread-utils-thread-interrupted
  "Thread was interrupted" 'error)

(defun thread-utils-main-thread-p (&optional object)
  (let ((object (or object (current-thread))))
    (and (threadp object)
         (eq object (car (all-threads))))))

(defun thread-utils-quitable-apply (fn &rest args)
  (let* ((this-thread (current-thread))
         (quit-thread
          (make-thread
           (lambda nil
             (condition-case nil
                 (cl-loop (sleep-for 3))
               (quit
                (thread-signal this-thread 'quit nil))
               (thread-utils-thread-interrupted nil))))))
    (unwind-protect
        (apply fn args)
      (thread-signal
       quit-thread 'thread-utils-thread-interrupted nil))))

(defun thread-utils-condition-quitable-wait (condition)
  (cl-check-type condition condition-variable)
  (thread-utils-quitable-apply #'condition-wait condition))

(defun thread-utils-condition-wait (condition)
  (if (thread-utils-main-thread-p)
      (thread-utils-condition-quitable-wait condition)
    (condition-wait condition)))

(defconst channel-default-capacity 16)

(defclass channel-terminal nil
  ((mutex :initarg :mutex :type mutex)
   (condition :initarg :condition :type condition-variable)
   (msg-queue :initarg :msg-queue :type ring)
   (closed-p :initform nil)
   (other-terminal :type (or null channel-terminal))))

(defclass channel-source (channel-terminal) nil)
(defclass channel-sink (channel-terminal) nil)

(define-error 'channel-closed
  "Trying to send/recv from a closed channel")

(defun make-channel (&optional capacity)
  (unless capacity
    (setq capacity channel-default-capacity))
  (cl-check-type capacity (integer 1 *))
  (let* ((mutex (make-mutex "channel"))
         (condition (make-condition-variable mutex "channel"))
         (msg-queue (make-ring capacity))
         (source
          (channel-source :mutex mutex
                          :condition condition
                          :msg-queue msg-queue))
         (sink
          (channel-sink :mutex mutex
                        :condition condition
                        :msg-queue msg-queue)))
    (oset source other-terminal sink)
    (oset sink other-terminal source)
    (cons source sink)))

(cl-defgeneric channel-send ((source channel-source) message)
  (with-mutex (oref source mutex)
    (with-slots (condition msg-queue) source
      (while (and (not (channel-closed-p source))
                  (= (ring-size msg-queue)
                     (ring-length msg-queue)))
        (thread-utils-condition-wait condition))
      (when (channel-closed-p source)
        (signal 'channel-closed (list source)))
      (let ((inhibit-quit t))
        (ring-insert msg-queue message)
        (when (= 1 (ring-length msg-queue))
          (condition-notify condition t)))
      nil)))

(cl-defgeneric channel-recv ((sink channel-terminal))
  (with-mutex (oref sink mutex)
    (with-slots (condition msg-queue) sink
      (while (and (not (channel-closed-p sink))
                  (ring-empty-p msg-queue))
        (thread-utils-condition-wait condition))
      (when (channel-closed-p sink)
        (signal 'channel-closed (list sink)))
      (let ((inhibit-quit t))
        (prog1 (ring-remove msg-queue)
          (when (= 1 (- (ring-size msg-queue)
                        (ring-length msg-queue)))
            (condition-notify condition t)))))))

(cl-defgeneric channel-peek ((sink channel-terminal))
  (with-mutex (oref sink mutex)
    (with-slots (condition msg-queue) sink
      (while (and (not (channel-closed-p sink))
                  (ring-empty-p msg-queue))
        (thread-utils-condition-wait condition))
      (when (channel-closed-p sink)
        (signal 'channel-closed (list sink)))
      (ring-ref msg-queue -1))))

(cl-defgeneric channel-close ((terminal channel-terminal))
  (with-mutex (oref terminal mutex)
    (with-slots (closed-p condition) terminal
      (setq closed-p t)
      (condition-notify condition t))
    nil))

(cl-defmethod channel-closed-p ((source channel-source))

  (with-mutex (oref source mutex)
    (with-slots (closed-p other-terminal) source
      (or closed-p
          (oref other-terminal closed-p)))))

(cl-defmethod channel-closed-p ((sink channel-sink))
  (with-mutex (oref sink mutex)
    (with-slots (closed-p other-terminal msg-queue) sink
      (or closed-p
          (and (oref other-terminal closed-p)
               (ring-empty-p msg-queue))))))

(defclass future nil
  ((channel :initform (make-channel 1))))

(defun make-future ()
  (make-instance 'future))

(cl-defgeneric future-set ((future future) value)
  (with-slots (channel) future
    (let ((inhibit-quit t))
      (condition-case nil
          (progn
            (debug "Sending future")
            (channel-send (car channel) value)
            (debug "Future send"))
        (channel-closed
         (signal 'error (list future))))
      (debug "Closing future")
      (channel-close (car channel))
      (debug "Future closed"))))

(cl-defgeneric future-get ((future future))
  (with-slots (channel) future
    (debug "Getting future")
    (channel-peek (cdr channel))
    (debug "Future got")))

(defclass future-deferred (future)
  ((producer :initarg :producer :type function)
   (value-produced-p :initform nil)
   (mutex :initform (make-mutex "future-deferred"))))

(defun make-deferred-future (producer)
  (make-instance 'future-deferred :producer producer))

(cl-defmethod future-get :before ((future future-deferred))
  (with-slots (mutex value-produced-p producer) future
    (with-mutex mutex
      (unless value-produced-p
        (unwind-protect
            (make-thread
             (lambda nil
               (debug "Setting Future")
               (future-set future (funcall producer))
               (debug "Future set"))
             "XEmacs")
          (setq value-produced-p t))))))

(let ((future (make-deferred-future (lambda nil 42))))
  (future-get future))

--=-=-=--




Acknowledgement sent to Andreas Politz <politza@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#36609; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Sat, 13 Jul 2019 16:15:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.