From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Saulius Menkevicius Newsgroups: gmane.emacs.devel Subject: Re: master 2c79a8f 2/2: Use posix_spawn if possible. Date: Mon, 31 Jan 2022 22:48:33 +0200 Message-ID: <3db6c69c-0c08-3f92-491b-0b715b18eb40@fastmail.com> References: <7CFD5E28-8266-4004-BF66-255146D72722@gnu.org> <83r18whunp.fsf@gnu.org> <36bbd45c-0a87-13b7-1589-afe943329e20@fastmail.com> <83ee4whqpf.fsf@gnu.org> <87v8y33hu1.fsf@rfc20.org> <83sft7aqxd.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------Rb99hVdNTuHU08KqUQFPxkJw" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9526"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Cc: p.stephani2@gmail.com, alan@idiocy.org, mituharu@math.s.chiba-u.ac.jp, emacs-devel@gnu.org To: Eli Zaretskii , Matt Armstrong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Feb 01 04:22:28 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nEjkR-0002I6-K0 for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Feb 2022 04:22:28 +0100 Original-Received: from localhost ([::1]:33664 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nEjkQ-0005J7-B8 for ged-emacs-devel@m.gmane-mx.org; Mon, 31 Jan 2022 22:22:26 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55774) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEdbR-00028K-KU for emacs-devel@gnu.org; Mon, 31 Jan 2022 15:48:45 -0500 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:42343) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEdbP-00029S-3b; Mon, 31 Jan 2022 15:48:45 -0500 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 343D35C0199; Mon, 31 Jan 2022 15:48:40 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 31 Jan 2022 15:48:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; bh=Yi/xjoSW/I6FRwoGISejodsrfS/huq+XOABKU2 wQt8U=; b=YS8k5LjGAJVXLTaHHPHZm6+fDnEVvk1DeJ3fbqo04TYsZur6ZGUKs5 yFRQpCo2DFZcz4R59eyPMoqUbQr7WUP8hNbnRvE413xVJhLamVA1MN73NG8+NQn6 HxSOHJscdO8WGmOYEB1J2uAYmfA5atm4By4oi3MX8l4f41OK6HFNuNd2VhSokZFf O7N55mbYU0yIzH6sFn65mhK5VX56EL6UjzDNa7HT/v3sAdxxGDcJCAd87F09yDxC fOS52ZZDw2GxIXKJPwSQ5/wOtLEo5a2yqG4zA4B12pW0nGMY9yE3wdPTqcni9IAB EwLCQmmp+AtETRqWYIsm6Cek/hQdWwPQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Yi/xjoSW/I6FRwoGI SejodsrfS/huq+XOABKU2wQt8U=; b=DPensJRb3IXgdM2eMqsZhPfdTUjjK4yjI t1OY3udrmUhrrVmC0MaUeoXnvQrPXw/FF5sWsSUrpvMlcG1ddbPEHzGh+SN2+gSW WbKJZNGbaP34wMjR6rTVHjCop3emMyP6ltPoXtJVfzha8OxSAZv5ANaWtHm+e/1O n4cWsoBtvXJACM/lh0OlQ2QP8SlxGw9C01V6K1nPnU8aAru2ifMnYXy5Q3Bz9dFC czh/IWGG08BsPrW2vRERHGxse3UtFX3a4lNSD4DMAHvcoin7f5JFivHRsaYo9fMm x6+EgiB/dyKWfUUTMg5BxmQReULnHuYUNjR8Ui1YpaHFHAldm+IoA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrgedugddugeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptgfkffggfgfuvfhfhfgjsegrtderredtfeejnecuhfhrohhmpefurghulhhi uhhsucfovghnkhgvvhhitghiuhhsuceoshgruhhlihhushhmvghnkhgvvhhitghiuhhsse hfrghsthhmrghilhdrtghomheqnecuggftrfgrthhtvghrnhepgeevhfelkefftdefuedu ieevgeehkeffvdehheetgeegjeffkeelffejgfeiveeunecuffhomhgrihhnpehphihthh honhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehsrghulhhiuhhsmhgvnhhkvghvihgtihhushesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 31 Jan 2022 15:48:36 -0500 (EST) Content-Language: en-US In-Reply-To: <83sft7aqxd.fsf@gnu.org> Received-SPF: pass client-ip=66.111.4.28; envelope-from=sauliusmenkevicius@fastmail.com; helo=out4-smtp.messagingengine.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 31 Jan 2022 22:19:41 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:285713 Archived-At: This is a multi-part message in MIME format. --------------Rb99hVdNTuHU08KqUQFPxkJw Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I did a bit more investigation (and still don't have a reproduction vehicle) but it seems the problem has to do with signals (SIGCHLD in particular) rather than stdio redirection. Stack trace in the child process shows it has launched a subprocess which has since exited but the child did not receive (?) SIGCHLD and appears to be blocked. Dotnet stack trace is |[bob@fedora emacs]$ dotnet stack report -p 53193 Thread (0xCFC9): [Native Frames] System.Private.CoreLib!System.Threading.WaitHandle.WaitOneNoCheck(int32) System.Private.CoreLib!System.Threading.WaitHandle.WaitOne(int32) System.Diagnostics.Process!System.Diagnostics.ProcessWaitState.WaitForExit(int32) System.Diagnostics.Process!System.Diagnostics.Process.WaitForExitCore(int32) Microsoft.Build.Locator!Microsoft.Build.Locator.DotNetSdkLocationHelper+d__5.MoveNext() Microsoft.Build.Locator!Microsoft.Build.Locator.DotNetSdkLocationHelper+d__4.MoveNext() Microsoft.Build.Locator!Microsoft.Build.Locator.MSBuildLocator+d__20.MoveNext() System.Linq!System.Linq.Enumerable.TryGetFirst(class System.Collections.Generic.IEnumerable`1,bool&) System.Linq!System.Linq.Enumerable.FirstOrDefault(class System.Collections.Generic.IEnumerable`1) Microsoft.Build.Locator!Microsoft.Build.Locator.MSBuildLocator.RegisterDefaults() CSharpLanguageServer!CSharpLanguageServer.Program.entry(class System.String[]) | Where "ps axl" shows there is a zombie process waiting to be collected but is not. |0 1000 53193 53129 20 0 3437284 59416 - Ssl ? 0:00 /home/bob/src/csharp-language-server/src/CSharpLanguageServer/bin/Debug/net6.0/CSharpLanguageServer 0 1000 53203 53193 20 0 0 0 - Z ? 0:00 [dotnet] | Related emacs src/callproc.cs has code that has this comment: /* Stop blocking SIGCHLD in the child.  */ But I really don't know what should I do to attempt to fix this/find the cause. -Saulius Am 29.01.22 um 10:26 schrieb Eli Zaretskii: >> From: Matt Armstrong >> Cc:p.stephani2@gmail.com,alan@idiocy.org,mituharu@math.s.chiba-u.ac.jp, >> emacs-devel@gnu.org >> Date: Fri, 28 Jan 2022 09:12:22 -0800 >> >> Eli Zaretskii writes: >> >>>> To actually figure that out I would need to build a minimal test fixture >>>> for this bug/issue and submit to dotnet/runtime repo on github for them >>>> to check and/or fix it. >>> I think there's no way around this. We need at least to understand >>> what part of posix_spawn code interferes with pipe-based I/O used by >>> these LSP servers, and why. >> I don't find an emacs bug filed for this issue. Saulius, it would be >> good to file one. >> >> This issue tickled a memory I had of Python moving away from posix_spawn >> due to various portability issues:https://bugs.python.org/issue35823. >> The issues they ran into and solved may inform this investigation. > Thanks. > > I see nothing there about C#, nor even about problems with stdio > redirection in subprocesses. There's some reference to closing file > descriptors above 2, but AFAIU the problems in this bug report are > related to descriptors that aren't above 2. --------------Rb99hVdNTuHU08KqUQFPxkJw Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

I did a bit more investigation (and still don't have a reproduction vehicle) but it seems the problem has to do with signals (SIGCHLD in particular) rather than stdio redirection.

Stack trace in the child process shows it has launched a subprocess which has since exited but the child did not receive (?) SIGCHLD and appears to be blocked.

Dotnet stack trace is

[bob@fedora emacs]$ dotnet stack report -p 53193
Thread (0xCFC9):
  [Native Frames]
  System.Private.CoreLib!System.Threading.WaitHandle.WaitOneNoCheck(int32)
  System.Private.CoreLib!System.Threading.WaitHandle.WaitOne(int32)
  System.Diagnostics.Process!System.Diagnostics.ProcessWaitState.WaitForExit(int32)
  System.Diagnostics.Process!System.Diagnostics.Process.WaitForExitCore(int32)
  Microsoft.Build.Locator!Microsoft.Build.Locator.DotNetSdkLocationHelper+<GetDotNetBasePaths>d__5.MoveNext()
  Microsoft.Build.Locator!Microsoft.Build.Locator.DotNetSdkLocationHelper+<GetInstances>d__4.MoveNext()
  Microsoft.Build.Locator!Microsoft.Build.Locator.MSBuildLocator+<GetInstances>d__20.MoveNext()
  System.Linq!System.Linq.Enumerable.TryGetFirst(class System.Collections.Generic.IEnumerable`1<!!0>,bool&)
  System.Linq!System.Linq.Enumerable.FirstOrDefault(class System.Collections.Generic.IEnumerable`1<!!0>)
  Microsoft.Build.Locator!Microsoft.Build.Locator.MSBuildLocator.RegisterDefaults()
  CSharpLanguageServer!CSharpLanguageServer.Program.entry(class System.String[])

Where "ps axl" shows there is a zombie process waiting to be collected but is not.

0  1000   53193   53129  20   0 3437284 59416 -     Ssl  ?          0:00 /home/bob/src/csharp-language-server/src/CSharpLanguageServer/bin/Debug/net6.0/CSharpLanguageServer
0  1000   53203   53193  20   0      0     0 -      Z    ?          0:00 [dotnet] <defunct>


Related emacs src/callproc.cs has code that has this comment:

/* Stop blocking SIGCHLD in the child.  */

But I really don't know what should I do to attempt to fix this/find the cause.

-Saulius

Am 29.01.22 um 10:26 schrieb Eli Zaretskii:
From: Matt Armstrong <matt@rfc20.org>
Cc: p.stephani2@gmail.com, alan@idiocy.org, mituharu@math.s.chiba-u.ac.jp,
 emacs-devel@gnu.org
Date: Fri, 28 Jan 2022 09:12:22 -0800

Eli Zaretskii <eliz@gnu.org> writes:


To actually figure that out I would need to build a minimal test fixture 
for this bug/issue and submit to dotnet/runtime repo on github for them 
to check and/or fix it.

I think there's no way around this.  We need at least to understand
what part of posix_spawn code interferes with pipe-based I/O used by
these LSP servers, and why.

I don't find an emacs bug filed for this issue.  Saulius, it would be
good to file one.

This issue tickled a memory I had of Python moving away from posix_spawn
due to various portability issues: https://bugs.python.org/issue35823.
The issues they ran into and solved may inform this investigation.

Thanks.

I see nothing there about C#, nor even about problems with stdio
redirection in subprocesses.  There's some reference to closing file
descriptors above 2, but AFAIU the problems in this bug report are
related to descriptors that aren't above 2.
--------------Rb99hVdNTuHU08KqUQFPxkJw--