From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jostein_Kj=c3=b8nigsen?= Newsgroups: gmane.emacs.devel Subject: Re: gdb fails to flush output (msys2) Date: Tue, 15 Mar 2022 12:48:17 +0100 Message-ID: <77bec550-18e8-bcb9-0d32-b023f01eb3a4@secure.kjonigsen.net> References: <86y21caikh.fsf@csic.es> <83o828k6a7.fsf@gnu.org> <867d8wa05w.fsf@csic.es> <837d8wjsur.fsf@gnu.org> <834k40js23.fsf@gnu.org> <86h77zwn9b.fsf@csic.es> Reply-To: jostein@kjonigsen.net Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------lZ0gFw6bki6dddyK9dtCCRER" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18240"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 To: =?UTF-8?Q?Juan_Jos=c3=a9_Garc=c3=ada-Ripoll?= , emacs-devel@gnu.org, =?UTF-8?Q?Saulius_Menkevi=c4=8dius?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 15 12:52:54 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 1nU5jR-0004Qe-97 for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Mar 2022 12:52:54 +0100 Original-Received: from localhost ([::1]:46072 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nU5jQ-0006m3-8f for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Mar 2022 07:52:52 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46168) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nU5f9-0004Ju-Dg for emacs-devel@gnu.org; Tue, 15 Mar 2022 07:48:27 -0400 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]:54125) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nU5f6-0004cJ-H4 for emacs-devel@gnu.org; Tue, 15 Mar 2022 07:48:26 -0400 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id D24DC5C0298; Tue, 15 Mar 2022 07:48:21 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 15 Mar 2022 07:48:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= secure.kjonigsen.net; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:sender:subject:subject:to:to; s=fm3; bh=RUDNo 69ByyFiNvBpEVTpHTICPf+osI6Zr2jkwjL2qVM=; b=MTrMx/wANLDrVEBE6dIay 6hgehQEnBMW7A6op5/kpifSpStpEIvxuQx/TtZr/Sli71pVTe4DJyBbJzcJONrHd eODYymIz4+g5JjSUUWum7Nuo8S6bkZy/D1KFB30F9clhVPMWj9fNrm7VTfG0BwyX pm4SLNfrVjvi8IHN4u4pkBsAvqhWfPlrjHQicZRwlsTyIzy4WruIK2KKp/HEl6Bj 9T/BGHaku1SY1PotTAZ5DlgYmdyX5D8Zn5hYHQbjGfoEYzme750icmNVEO1FSaL5 j5boqwJMCMGoDa02cV8viN6Na3OSkfriiL4YfiENVx+VMum2dBvk5lE0LfQua0dl w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=RUDNo6 9ByyFiNvBpEVTpHTICPf+osI6Zr2jkwjL2qVM=; b=WyuVEbwOKny0TFXCz0PmTM ZUGR3rcUlVQHUVuWQjXgMhBqTT28nxIvEEd/e89sfCb+H4RxbbZ6HMPgOsI9lOit jhZxOXGUcixU4Zc6sa3f00rT4254uq/Av+4RCgzCsWZXgR/Sw43ML6ol13Akwvbn 8lq+2rWN2j0Kcg4Pe0G+09ly63id7YZpHFYzxkpeSicS5vuzaFTrLYDE+3tT/V+u bfHhzZp1FlvyfoF5IINy4GMwEJbqiOpCvdRoDX6YW5JLQkT1Og1a0oQty6xl741Z 4SYcHMlX0QCDA87er07ayiVF1n8ehFiL6AcLCbNQLpd5g1UHHr/rled48Vk9MdrQ == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudeftddgfeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptgfkffggfghruffvfhfhjgesrgdtreertdefjeenucfhrhhomheplfhoshht vghinhgpmfhjpphnihhgshgvnhcuoehjohhsthgvihhnsehsvggtuhhrvgdrkhhjohhnih hgshgvnhdrnhgvtheqnecuggftrfgrthhtvghrnhepheekgfejtdeuffdvteeitddvkeeh gfffkeegffduudduffetjeevheefueegudehnecuffhomhgrihhnpehsphgvtghifhhitg grlhhlhidrnhgvthdpfihithhhrdhnvghtpdhgnhhurdhorhhgpdhkjhhnihhgshgvnhdr nhhonecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepjh hoshhtvghinhesshgvtghurhgvrdhkjhhonhhighhsvghnrdhnvght X-ME-Proxy: Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Mar 2022 07:48:21 -0400 (EDT) Content-Language: nb-NO In-Reply-To: <86h77zwn9b.fsf@csic.es> Received-SPF: pass client-ip=66.111.4.29; envelope-from=jostein@secure.kjonigsen.net; helo=out5-smtp.messagingengine.com X-Spam_score_int: -26 X-Spam_score: -2.7 X-Spam_bar: -- X-Spam_report: (-2.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=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-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:287180 Archived-At: This is a multi-part message in MIME format. --------------lZ0gFw6bki6dddyK9dtCCRER Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 15.03.2022 10:58, Juan José García-Ripoll wrote: > Eli Zaretskii writes: >> Can you show how that program behaves when invoked from the system >> shell, not under the debugger? Also, if you invoke "M-x shell" inside >> Emacs, and then run that program from the inferior shell, does it >> behave correctly, or does it also hangs until you type Enter? > Let me summarize all the questions in this single post. What is related > to MSYS2 is the use of MSYS2's toolchains for building and debugging the > software. There is nothing specific to MSYS2 other than specifying to > Emacs that the debugger is c:/msys64/ucrt64/bin/gdb.exe or some other > program from the toolchain I choose. > > Your paragraph abore is quite on spot. As I stated before, if I use M-x > shell and invoke the debugger from the shell (still within Emacs) > everything works just fine, so it is not a buffering issue. Also, to be > more precise, within the debugger the program runs to completion, which > means the output is completely unbuffered. It therefore should have been > shown by Emacs' gdb already when I copied the text. > > Another indication that there is some problem with Emacs' GDB/GUD > packages is that the output _is_ there. If I type a command right after > the last shown output, gdb executes that command, and any following one, > but re-displays the original output of the program again and again. It > is somehow as if it had reinterpreted the program's output as a prompt. > > Is there a way I can debug how GUD is behaving or interfacing with gdb's > output? I know some other major modes keep debugging information or > intermediate buffers if requested. But I still have not found it for > GUD. > > Best, > Could this error in any way be related to the previous issue with had with "use posix_spawn"? [1] For those who need a reminder, as far as I understood it, the key issue there was that  a required bugfix for Mac (but also generally an optimization) was made into a default optimization for platforms, and the idea was that unless it was proven troublesome one could decide to keep it. Well, on Linux it did cause some issues with triggering external processes. Specifically .NET-based tooling, made especially painful with .NET-based Language Server implementations no longer working (C# and F#). If this is another instance of such a bug (and I'm deliberately qualifing that with an "if"), would it make sense to reverse this optimization on all platforms not Mac? There seems to be several unintended side-effects, and could possibly be more? [1] https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01561.html -- Kind regards *Jostein Kjønigsen* jostein@kjonigsen.net 🍵 jostein@gmail.com https://jostein.kjønigsen.no --------------lZ0gFw6bki6dddyK9dtCCRER Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 15.03.2022 10:58, Juan José García-Ripoll wrote:
Eli Zaretskii <eliz@gnu.org> writes:

Can you show how that program behaves when invoked from the system
shell, not under the debugger?  Also, if you invoke "M-x shell" inside
Emacs, and then run that program from the inferior shell, does it
behave correctly, or does it also hangs until you type Enter?

Let me summarize all the questions in this single post. What is related
to MSYS2 is the use of MSYS2's toolchains for building and debugging the
software. There is nothing specific to MSYS2 other than specifying to
Emacs that the debugger is c:/msys64/ucrt64/bin/gdb.exe or some other
program from the toolchain I choose.

Your paragraph abore is quite on spot. As I stated before, if I use M-x
shell and invoke the debugger from the shell (still within Emacs)
everything works just fine, so it is not a buffering issue. Also, to be
more precise, within the debugger the program runs to completion, which
means the output is completely unbuffered. It therefore should have been
shown by Emacs' gdb already when I copied the text.

Another indication that there is some problem with Emacs' GDB/GUD
packages is that the output _is_ there. If I type a command right after
the last shown output, gdb executes that command, and any following one,
but re-displays the original output of the program again and again. It
is somehow as if it had reinterpreted the program's output as a prompt.

Is there a way I can debug how GUD is behaving or interfacing with gdb's
output? I know some other major modes keep debugging information or
intermediate buffers if requested. But I still have not found it for
GUD.

Best,
Could this error in any way be related to the previous issue with had with "use posix_spawn"? [1]

For those who need a reminder, as far as I understood it, the key issue there was that  a required bugfix for Mac (but also generally an optimization) was made into a default optimization for platforms, and the idea was that unless it was proven troublesome one could decide to keep it.

Well, on Linux it did cause some issues with triggering external processes. Specifically .NET-based tooling, made especially painful with .NET-based Language Server implementations no longer working (C# and F#).

If this is another instance of such a bug (and I'm deliberately qualifing that with an "if"), would it make sense to reverse this optimization on all platforms not Mac? There seems to be several unintended side-effects, and could possibly be more?

[1] https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01561.html

--
Kind regards
Jostein Kjønigsen

jostein@kjonigsen.net 🍵 jostein@gmail.com
https://jostein.kjønigsen.no
--------------lZ0gFw6bki6dddyK9dtCCRER--