GNU bug report logs - #45518
Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile in Emacs 27.1

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45518 in the body.
You can then email your comments to 45518 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Duncan Greatwood <dgbulk <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile in Emacs 27.1
Date: Mon, 28 Dec 2020 17:10:58 -0800

[Message part 1 (text/plain, inline)]

Using tramp, I had a remote cpp file open in a window.

I pressed "C-c c", which invokes a function in my .emacs called
compile-hereish, which (in this case) invokes the compile command with
the remote directory containing the remote cpp.

Compilation begins as expected.

The cpp file contains a number of syntax errors. There is what I understand
to be a longstanding Tramp bug such that, if a lot of outputs (syntax
errors) are sent at high speed to the compile window, Tramp hangs.

In emacs 26.2, Ctrl-G (usually ctrl-g three times) would interrupt the hung
Tramp window, and indeed cause the errors to be displayed in the window as
best as Tramp is able.

In emacs 27.1, Ctrl-G does nothing in this "tramp-hung-while-compiling"
situation. I also tried ctrl-c ctrl-c, but that also does nothing. It
appears that the only way to kill the hung Tramp compile is to force-quit
emacs as a whole at the OS level.

Machine running emacs: MacBook Pro (2015), macos Big Sur v11.1. I am using
emacs 27.1 installed via brew-cask on macos.
On the Macbook: ssh -V
    OpenSSH_8.1p1, LibreSSL 2.7.3

Remote host for compile: Ubuntu Linux 20.04.1 LTS (GNU/Linux
5.4.0-54-generic x86_64)
On remote host: ssh -V
  OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f  31 Mar 2020
Also on remote host: gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

If I revert back to emacs 26.2 on the Macbook, ctrl-G once again works as
expected in the event of a Tramp hang.

I am attaching to the remote host using Tramp-ssh mode, but I also tried
Tramp-scp and saw the same behaviour. My .emacs includes:
(setq tramp-default-method "ssh")
(setq tramp-chunksize 500)

The following cpp file (on Ubuntu machine) is sufficient to generate a
large number of syntax errors and hang Tramp, blocking ctrl-G (crashing
emacs) in emacs 27.1 for me.
// test.cpp
  DummyClass(
  DummyClass(
  DummyClass(
  DummyClass(
  DummyClass(
  DummyClass(
  DummyClass(
  DummyClass(
  DummyClass(
  DummyClass(
int validstuff();
int validstuff()
{
    return(0);
}
// end test.cpp

Thanks as always.
D.

Following was generated via: M-x report-emacs-bug

In GNU Emacs 27.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60
Version 10.14.6 (Build 18G95))
 of 2020-08-11 built on builder10-14.porkrind.org
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.1

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Package cl is deprecated
Mark set

Configured using:
 'configure --with-ns '--enable-locallisppath=/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application
 Support/Emacs/site-lisp' --with-modules'

Configured features:
NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES
THREADS JSON PDUMPER

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  global-undo-tree-mode: t
  undo-tree-mode: t
  global-auto-complete-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/Users/dgreatwood/.emacs.d/lisp/linum hides
/Applications/Emacs.app/Contents/Resources/lisp/linum

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search seq
byte-opt bytecomp byte-compile cconv mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils linum easy-mmode
time-date subr-x server persistent-todo special-scratch tango-theme
advice undo-tree diff auto-complete-config auto-complete popup
string-inflection paren desktop frameset unbound cl-macs cl gv delsel
edmacro kmacro cl-loaddefs cl-lib tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads kqueue cocoa ns
multi-tty make-network-process emacs)

Memory information:
((conses 16 70462 8546)
 (symbols 48 8556 1)
 (strings 32 22334 1877)
 (string-bytes 1 713421)
 (vectors 16 12259)
 (vector-slots 8 156248 17226)
 (floats 8 39 36)
 (intervals 56 248 0)
 (buffers 1000 14))

[Message part 2 (text/html, inline)]

Message #8 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Duncan Greatwood <dgbulk <at> gmail.com>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile
 in Emacs 27.1
Date: Wed, 30 Dec 2020 11:36:30 +0100

Duncan Greatwood <dgbulk <at> gmail.com> writes:

Hi Duncan,

> In emacs 26.2, Ctrl-G (usually ctrl-g three times) would interrupt the
> hung Tramp window, and indeed cause the errors to be displayed in the
> window as best as Tramp is able.
>
> In emacs 27.1, Ctrl-G does nothing in this
> "tramp-hung-while-compiling" situation. I also tried ctrl-c ctrl-c,
> but that also does nothing. It appears that the only way to kill the
> hung Tramp compile is to force-quit emacs as a whole at the OS level.

Well, in this area several changes have been applied since Emacs 27.1
has been released. Could you, pls, try the Tramp ELPA version (2.5.0)?
Even if it still blocks Emacs, there is a new option to write Tramp
traces to file. This would help us to find the culprit, if still
evident.

> Thanks as always.
> D.

Best regards, Michael.

Message #11 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Duncan Greatwood <dgbulk <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile in
 Emacs 27.1
Date: Wed, 30 Dec 2020 13:13:31 -0800

[Message part 1 (text/plain, inline)]

Hi Michael,

On Wed, Dec 30, 2020 at 2:36 AM Michael Albinus <michael.albinus <at> gmx.de>
> wrote:
> Duncan Greatwood <dgbulk <at> gmail.com> writes:
> Hi Duncan,
> > In emacs 26.2, Ctrl-G (usually ctrl-g three times) would interrupt the
> > hung Tramp window, and indeed cause the errors to be displayed in the
> > window as best as Tramp is able.
> >
> > In emacs 27.1, Ctrl-G does nothing in this
> > "tramp-hung-while-compiling" situation. I also tried ctrl-c ctrl-c,
> > but that also does nothing. It appears that the only way to kill the
> > hung Tramp compile is to force-quit emacs as a whole at the OS level.
> Well, in this area several changes have been applied since Emacs 27.1
> has been released. Could you, pls, try the Tramp ELPA version (2.5.0)?
>
[DG] I note in passing that in my emacs 27.1 build, I already have Tramp
2.5.0 installed as per:
    M-x list-packages
    ...
      tramp              2.5.0         available

Nonetheless, I downloaded from this page:
https://elpa.gnu.org/packages/tramp.html
    tramp-2.5.0.tar, 2020-Dec-29, 1.61 MiB
I expanded the tar to a local directory, call it ~/.../tramp-2.5.0

I then added the following to my .emacs file:
    (add-to-list 'load-path (expand-file-name "~/.../tramp-2.5.0"))
    (require 'tramp)

Happy news - with this addition to .emacs, pressing ctrl-g three times once
again interrupts the hung Tramp window, and .emacs as a whole does not
crash.

I tried adding and removing the .emacs lines several times, and the matter
produces perfectly: ctrl-gx3 always works when the .emacs lines are
present, and never works when they are not in emacs 27.1.

The only slight wrinkle I noticed with this newest version of tramp (vs.
emacs 26.2 tramp) is that, after pressing ctrl-gx3, it feels I have to
click around to another window and back in order to see the error output
from the compile appear in the tramp compile window, wheres in emacs 26.2
the error output would start appearing in the tramp compile window as soon
as ctrl-gx3 was pressed. No terrible hardship but JFYI.

Is there anything I can do that would help diagnose / pinpoint or whatever?
Either with the ctrl-gx3 matter, or indeed with the underlying hang in the
tramp compile window which requires the use of ctrl-gx3.

Best regards,
Duncan


> Even if it still blocks Emacs, there is a new option to write Tramp
> traces to file. This would help us to find the culprit, if still
> evident.
> > Thanks as always.
> > D.
> Best regards, Michael.

[Message part 2 (text/html, inline)]

Message #14 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Duncan Greatwood <dgbulk <at> gmail.com>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile
 in Emacs 27.1
Date: Thu, 31 Dec 2020 09:42:15 +0100

Duncan Greatwood <dgbulk <at> gmail.com> writes:

> Hi Michael,

Hi Duncan,

> [DG] I note in passing that in my emacs 27.1 build, I already have
> Tramp 2.5.0 installed as per:
>     M-x list-packages
>     ...
>       tramp              2.5.0         available

Well, this doe NOT mean it is installed already. It is available in the
package archive.

> Nonetheless, I downloaded from this page:
> https://elpa.gnu.org/packages/tramp.html
>     tramp-2.5.0.tar, 2020-Dec-29, 1.61 MiB
> I expanded the tar to a local directory, call it ~/.../tramp-2.5.0
>
> I then added the following to my .emacs file:
>     (add-to-list 'load-path (expand-file-name "~/.../tramp-2.5.0"))
>     (require 'tramp)

That's one way to do it. The more natural way is "M-x package-install
RET tramp". Or, in the *Packages* buffer, mark the package with "i", and
install it via "x".

> Happy news - with this addition to .emacs, pressing ctrl-g three times
> once again interrupts the hung Tramp window, and .emacs as a whole
> does not crash.
>
> I tried adding and removing the .emacs lines several times, and the
> matter produces perfectly: ctrl-gx3 always works when the .emacs lines
> are present, and never works when they are not in emacs 27.1.

Great!

> The only slight wrinkle I noticed with this newest version of tramp
> (vs. emacs 26.2 tramp) is that, after pressing ctrl-gx3, it feels I
> have to click around to another window and back in order to see the
> error output from the compile appear in the tramp compile window,
> wheres in emacs 26.2 the error output would start appearing in the
> tramp compile window as soon as ctrl-gx3 was pressed. No terrible
> hardship but JFYI.
>
> Is there anything I can do that would help diagnose / pinpoint or
> whatever? Either with the ctrl-gx3 matter, or indeed with the
> underlying hang in the tramp compile window which requires the use of
> ctrl-gx3.

I will try to reproduce it locally. Since I don't know where to start
with debugging, I cant give you instructions for this yet.

> Best regards,
> Duncan

Best regards, Michael.

Message #19 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Duncan Greatwood <dgbulk <at> gmail.com>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile
 in Emacs 27.1
Date: Sun, 03 Jan 2021 11:27:21 +0100

Michael Albinus <michael.albinus <at> gmx.de> writes:

Hi Duncan,

>> Is there anything I can do that would help diagnose / pinpoint or
>> whatever? Either with the ctrl-gx3 matter, or indeed with the
>> underlying hang in the tramp compile window which requires the use of
>> ctrl-gx3.
>
> I will try to reproduce it locally. Since I don't know where to start
> with debugging, I cant give you instructions for this yet.

I've tried to trigger this error, but I cannot. Calling "M-x compile",
and invoking "gcc test.cpp" then, returns immediately with one error
message:

--8<---------------cut here---------------start------------->8---
-*- mode: compilation; default-directory: "/ssh:detlef:/home/albinus/tmp/" -*-
Compilation started at Sun Jan  3 11:23:16

gcc test.cpp
test.cpp:2:13: error: expected constructor, destructor, or type conversion before ‘(’ token
    2 |   DummyClass(
      |             ^

Compilation exited abnormally with code 1 at Sun Jan  3 11:23:16
--8<---------------cut here---------------end--------------->8---

What does it need to hang Emacs/Tramp, compiling this file?

>> Best regards,
>> Duncan

Best regards, Michael.

Message #22 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Duncan Greatwood <dgbulk <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile in
 Emacs 27.1
Date: Sun, 3 Jan 2021 11:27:17 -0800

[Message part 1 (text/plain, inline)]

Firstly, my apologies. The test.cpp I supplied was an attempt at a quick
simplification, and as you said it doesn't produce "enough" syntax errors
actually.

I am pasting below a test.cpp that I have verified on my setup does hang
the tramp window.

I'm afraid that there is another complication for reproducability. I cannot
get the issue to reproduce when I do "M-x compile" then invoking "gcc
test.cpp". It appears to reproduce only when doing "make" on a larger /
more complex project containing test.cpp. This is true even when test.cpp
is the first file that compiles in the project upon "make".

I attempted to make a small autotools project containing test.cpp, but even
that doesn't seem to reproduce the tramp hang. Only by including test.cpp
in a large preexisting project does the hang occur, at least for me.

I would suggest that you take a favorite large C++ autotools project, add
test.cpp to the source tree and Makefile.am, and see if the hang reproduces
for you.

For your reference, I am also pasting the output from the hung tramp window
when I added test.cpp to a library within one of my own larger projects.

Regards,
D.
======= Hung Tramp Window ==========

-*- mode: compilation; default-directory:
"/ssh:username <at> TWR1HM:/home/username/Dropbox/progs/thisprog/sbshared/src/"
-*-
Compilation started at Sun Jan  3 11:02:36

make -k
make  all-am
make[1]: Entering directory
'/home/username/Dropbox/progs/thisprog/sbshared/src'
/bin/bash ../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I.
 -std=c++11 -Wall -Werror -Wclobbered -Wempty-body -Wignored-qualifiers
-Wmissing-field-initializers -Wsign-compare -Wtype-limits -Wuninitialized
-Winit-self -Wcast-align -Wfloat-equal -Wformat=2 -Wno-psabi
 -I/usr/include/libxml2 -I../../../kilo  -I../../../rapidxml  -g3 -Og
-DDEBUG=1 -MT test.lo -MD -MP -MF .deps/test.Tpo -c -o test.lo test.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -std=c++11 -Wall -Werror
-Wclobbered -Wempty-body -Wignored-qualifiers -Wmissing-field-initializers
-Wsign-compare -Wtype-limits -Wuninitialized -Winit-self -Wcast-align
-Wfloat-equal -Wformat=2 -Wno-psabi -I/usr/include/libxml2 -I../../../kilo
-I../../../rapidxml -g3 -Og -DDEBUG=1 -MT test.lo -MD -MP -MF
.deps/test.Tpo -c test.cpp  -fPIC -DPIC -o .libs/test.o

==================================
// test.cpp - for lots of syntax errors

#include <mutex>
#include <string>
#include <vector>
#include <memory>

class A1
{
    int f1();
    int f2();
    int f3();
    int f4();
    int f5();
    int f6();
    int f7();
    int f8();
    int f9();
};

class Nested
{
class Nested
{
class Nested
{
class Nested
{
class Nested
{
class Nested
{
class Nested
{
class Nested
{
class Nested
{
class Nested
{
class Nested
{
class Nested
{
class Nested
{
class Nested
{
class Nested
{
class Nested
{
class Nested
{
class Nested
{
class Nested
{
class Nested
{
class Nested
{
class Nested
{
class Nested
{
    A1 m1;
};
};
};
};
};
};
};
};
};
};
};
};
};
};
};
};
};
};
};
};
};
};
};


class A2
{
    std::shared_ptr<A1> a1ptr;
    A2() {A1 a1; a1ptr = &a1;}
};

#define AN_BODY                                                    \
    A1 x1;                                                         \
    A1 x2;                                                         \
    std::string s1(x1);                                            \
    std::string s2(x2);                                            \
Nested n1;                                                              \
const std::vector<std::string> v1(1, a1);                               \
const std::vector<std::string> v1(1, n1);                               \
std::vector<std::string> * v1_cptr(&v1);                                \
return(s1+s2);

int A1::f1()
{
    AN_BODY;
}

int A1::f2()
{
    AN_BODY;
}

int A1::f3()
{
    AN_BODY;
}

int A1::f4()
{
    AN_BODY;
}

int A1::f5()
{
    AN_BODY;
}

int A1::f6()
{
    AN_BODY;
}

int A1::f7()
{
    AN_BODY;
}

int A1::f8()
{
    AN_BODY;
}

int A1::f9()
{
    AN_BODY;
}

int A1::f10()
{
    AN_BODY;
}


int main(int argc, char* argv[])
{
    AN_BODY;
}
// end test.cpp

==================================
On Sun, Jan 3, 2021 at 2:27 AM Michael Albinus <michael.albinus <at> gmx.de>
wrote:

> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
> Hi Duncan,
>
> >> Is there anything I can do that would help diagnose / pinpoint or
> >> whatever? Either with the ctrl-gx3 matter, or indeed with the
> >> underlying hang in the tramp compile window which requires the use of
> >> ctrl-gx3.
> >
> > I will try to reproduce it locally. Since I don't know where to start
> > with debugging, I cant give you instructions for this yet.
>
> I've tried to trigger this error, but I cannot. Calling "M-x compile",
> and invoking "gcc test.cpp" then, returns immediately with one error
> message:
>
> --8<---------------cut here---------------start------------->8---
> -*- mode: compilation; default-directory: "/ssh:detlef:/home/albinus/tmp/"
> -*-
> Compilation started at Sun Jan  3 11:23:16
>
> gcc test.cpp
> test.cpp:2:13: error: expected constructor, destructor, or type conversion
> before ‘(’ token
>     2 |   DummyClass(
>       |             ^
>
> Compilation exited abnormally with code 1 at Sun Jan  3 11:23:16
> --8<---------------cut here---------------end--------------->8---
>
> What does it need to hang Emacs/Tramp, compiling this file?
>
> >> Best regards,
> >> Duncan
>
> Best regards, Michael.

[Message part 2 (text/html, inline)]

Message #25 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Duncan Greatwood <dgbulk <at> gmail.com>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile
 in Emacs 27.1
Date: Wed, 06 Jan 2021 14:37:36 +0100

[Message part 1 (text/plain, inline)]

Duncan Greatwood <dgbulk <at> gmail.com> writes:

Hi Duncan,

> I would suggest that you take a favorite large C++ autotools project,
> add test.cpp to the source tree and Makefile.am, and see if the hang
> reproduces for you.

I don't work with C++, so I haven't.

> For your reference, I am also pasting the output from the hung tramp
> window when I added test.cpp to a library within one of my own larger
> projects.

I tried to mimic that, but it still just shows all errors, and no hung
window. Tested with recent Tramp 2.5.0 and all Emacs versions 26, 27,
28. See appended compile output.

> Regards,
> D.

Best regards, Michael.

[*compilation* (text/plain, attachment)]

Message #28 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Duncan Greatwood <dgbulk <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile in
 Emacs 27.1
Date: Wed, 6 Jan 2021 14:54:39 -0800

[Message part 1 (text/plain, inline)]

Michael -

On Wed, Jan 6, 2021 at 5:37 AM Michael Albinus <michael.albinus <at> gmx.de>
wrote:

> Duncan Greatwood <dgbulk <at> gmail.com> writes:
>
> Hi Duncan,
>
> > I would suggest that you take a favorite large C++ autotools project,
> > add test.cpp to the source tree and Makefile.am, and see if the hang
> > reproduces for you.
>
> I don't work with C++, so I haven't.
>
[DG] Oh, no worries. Let me try and give a more explicit recipe.

This is what I did:

Download the autotools "hello world" program, and modify it as follows.

Go to https://github.com/shanecelis/amhello (or *many* other places), and
download the "hello world" code (click Code button on the github page,
choose "Download zip" for simplicity).

Expand the zip file, and cd into amhello-master directory. This is on a
linux machine, an ubuntu machine in my case.

Open configure.ac in a text editor. You'll see a section headed:
    # Checks for programs.
We need to add AC_PROG_CXX and AM_PROG_AR, so this section will look like:
    # Checks for programs.

    AC_PROG_CC
    AC_PROG_CXX
    AM_PROG_AR
    AC_PROG_LIBTOOL
Save configure.ac, and exit the text editor.

Copy my test.cpp file into the src subdirectory of amhello-master.

Open src/Makefile.am in a text editor.
Added test.cpp to the sources line, so that line looks like:
    hello_SOURCES = main.c test.cpp
Save src/Makefile.am and exit the editor.

I presume you already have the autotools toolset installed, but if not,
install them.
    sudo apt-get install -y autotools-dev autoconf

Now at the shell command line (*not* in emacs) on the target linux machine,
in the amhello-master directory:
    autoreconf --install
    ./configure
    make

You should see the many syntax errors of test.cpp spewing out in the shell.

Now *in gui emacs*, from a mac machine using Tramp,
open amhello-master/src/test.cpp remotely (using tramp) on the remote linux
machine.
With that remote test.cpp open, In emacs, do
    M-compile
    Use the compile command: make -k

Tramp window hangs

As you noted prior, if you use compile command "gcc test.cpp", tramp does
not hang. Only if you use compile command "make" does it hang.

I was using my macbook laptop for the GUI-emacs-with-tramp, and ubuntu for
the target linux machine. I was using emacs 26.2 gui-mode, but no reason to
suppose it varies with other emacs versions.

I did try it with a Linux laptop, running emacs-gui (26.3) and tramp to
connect to the remote Linux host. However, in that case the issue did *not*
reproduce for me, at least using this method. Perhaps emacs/tramp must be
running from a mac for the issue to show up.

Hope this helps.
Thanks once more.
Duncan



>
> > For your reference, I am also pasting the output from the hung tramp
> > window when I added test.cpp to a library within one of my own larger
> > projects.
>
> I tried to mimic that, but it still just shows all errors, and no hung
> window. Tested with recent Tramp 2.5.0 and all Emacs versions 26, 27,
> 28. See appended compile output.
>
> > Regards,
> > D.
>
> Best regards, Michael.

[Message part 2 (text/html, inline)]

Message #31 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Duncan Greatwood <dgbulk <at> gmail.com>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile
 in Emacs 27.1
Date: Mon, 11 Jan 2021 11:58:25 +0100

Duncan Greatwood <dgbulk <at> gmail.com> writes:

> Michael -

Hi Duncan,

> This is what I did:

Thanks for the recipe. Today, I found the time to apply.

> Now *in gui emacs*, from a mac machine using Tramp, open
> amhello-master/src/test.cpp remotely (using tramp) on the remote linux
> machine.
> With that remote test.cpp open, In emacs, do
>     M-compile
>     Use the compile command: make -k
>
> Tramp window hangs
>
> I was using my macbook laptop for the GUI-emacs-with-tramp, and ubuntu
> for the target linux machine. I was using emacs 26.2 gui-mode, but no
> reason to suppose it varies with other emacs versions.
>
> I did try it with a Linux laptop, running emacs-gui (26.3) and tramp
> to connect to the remote Linux host. However, in that case the issue
> did *not* reproduce for me, at least using this method. Perhaps
> emacs/tramp must be running from a mac for the issue to show up.

Well my local machine running Emacs is Fedora 33. And, as expected, make -k
didn't hang :-(

Since I have no macOS machine, I fear I cannot debug the problem.

> Hope this helps.
> Thanks once more.
> Duncan

Best regards, Michael.

Message #34 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Duncan Greatwood <dgbulk <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile in
 Emacs 27.1
Date: Mon, 11 Jan 2021 08:52:27 -0800

[Message part 1 (text/plain, inline)]

Hi Michael -

Thanks for trying.

Is there a way for me to capture any trace, call-stack or similar when the
emacs window is in the tramp-hung state? I could share that back to you, if
practical.

Alternatively, if you had time and could spend the few $s (it's "pay as you
go"), you could try from a Mac on Amazon.
https://aws.amazon.com/ec2/instance-types/mac/

Finally, presuming we can't fix the underlying issue on mac, do you know
approximately when the version of tramp that fixes the "Ctrl-G x3 Fails to
Interrupt Hung Tramp" issue will make it to release? The December 29th
version I tried coupled with emacs 27.1 seemed to fix the ctrl-g issue but
otherwise was quite inclined to crash-and-exit emacs. I know the tramp
version I tried is an alpha so no problem, just wondering when it may reach
general release?

Regards,
Duncan.

[Message part 2 (text/html, inline)]

Message #37 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Duncan Greatwood <dgbulk <at> gmail.com>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile
 in Emacs 27.1
Date: Mon, 11 Jan 2021 18:56:17 +0100

Duncan Greatwood <dgbulk <at> gmail.com> writes:

> Hi Michael -

Hi Duncan,

> Is there a way for me to capture any trace, call-stack or similar when
> the emacs window is in the tramp-hung state? I could share that back
> to you, if practical.

Good News: I have a FreeBSD 12.1 VM hanging around. Installing Emacs 28
on that machine, trying your recipe with my remote Ubuntu machine, and
voilà - it hangs. Great :-)

Well, C-g several times doesn't kill the compile process, but so what: I
can test now. Will play with this next days, as time permits.

> Alternatively, if you had time and could spend the few $s (it's "pay
> as you go"), you could try from a Mac on Amazon.
> https://aws.amazon.com/ec2/instance-types/mac/

Ah, I didn't know. Good to have it as fallback, I don't care to share
some few $s ...  But I haven't used this type of OS ever, so I would
need to learn how to install Emacs there.

> Finally, presuming we can't fix the underlying issue on mac, do you
> know approximately when the version of tramp that fixes the "Ctrl-G x3
> Fails to Interrupt Hung Tramp" issue will make it to release? The
> December 29th version I tried coupled with emacs 27.1 seemed to fix
> the ctrl-g issue but otherwise was quite inclined to crash-and-exit
> emacs. I know the tramp version I tried is an alpha so no problem,
> just wondering when it may reach general release?

It is Tramp 2.5.0, which I have released meanwhile via GNU ELPA. So you
might try to install it from there. Emacs 28, which will carry it
built-in, is still months away from a release. I wouldn't even bet that
this will happen this year; currently Emacs 27.2 has started its
pretest. However, I plan regular Tramp 2.5 releases via GNU ELPA (once a
month or so).

What do you mean with "crash-and-exit emacs"? Is it just because of the
changed Tramp version?

There have been bug reports that Tramp could crash Emacs on macOS. But
finally, it wasn't a Tramp issue, but rather a bug in Emacs which was
uncovered by Tramp. This is fixed now in the Emacs repository, see
bug#24472, bug#37299, bug#37557. The bugs are merged, so it seems to be
the same problem.

If you see other problems related to Tramp 2.5.0, pls report. I'll
happily try to fix them.

> Regards,
> Duncan.

Best regards, Michael.

Message #40 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Duncan Greatwood <dgbulk <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile in
 Emacs 27.1
Date: Mon, 11 Jan 2021 20:34:42 -0800

[Message part 1 (text/plain, inline)]

I hadn't thought of FreeBSD, but, since it's said that parts of macos
originated with FreeBSD it was a smart idea... glad it worked!

Regarding the crashes with the newest tramp I tried, I didn't look at them
with precision, sorry. From the bugs you mentioned:

   - bug#24472, bug#37299 (menu bar) - I did see a menu bar crash, maybe
   the same thing(s)
   - bug#37557 scrolling - I didn't notice this one, but perhaps the keys I
   pressed that seemed to "cause" a crash were scrolling the window.

If crashing remains an issue in a little while, I can try and recreate, and
will file a new bug.

Meanwhile, good luck with debugging these bug#45518 issues.

Thanks again!

[Message part 2 (text/html, inline)]

Message #43 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Duncan Greatwood <dgbulk <at> gmail.com>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile
 in Emacs 27.1
Date: Tue, 12 Jan 2021 10:02:44 +0100

Duncan Greatwood <dgbulk <at> gmail.com> writes:

Hi Duncan,

> I hadn't thought of FreeBSD, but, since it's said that parts of macos
> originated with FreeBSD it was a smart idea... glad it worked!

I'm still fighting with FreeBSD Emacs to get it debugged after
blocking. But Tramp 2.5.0 has a new feature called "direct async
processes", which is an optimization for process calls in some
environments. I've tried it here, and indeed, Emacs does not block when
compiling the remote example.

You could try it yourself. Eval

(add-to-list 'tramp-connection-properties
             (list (regexp-quote "/ssh:user <at> host:")
                   "direct-async-process" t))

on a fresh Emacs instance, before you connect to
remote. "/ssh:user <at> host:" must be adapted, of course. See

(info "(tramp) Improving performance of asynchronous remote processes")

for details (this require the info file from Tramp 2.5.0).

> Thanks again!

Best regards, Michael.

Message #46 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Duncan Greatwood <dgbulk <at> gmail.com>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile
 in Emacs 27.1
Date: Tue, 12 Jan 2021 16:02:32 +0100

[Message part 1 (text/plain, inline)]

Duncan Greatwood <dgbulk <at> gmail.com> writes:

Hi Duncan,

> Meanwhile, good luck with debugging these bug#45518 issues.

Finally, I nailed it down. In the (remote) compilation process, there is
a process filter, which calls `file-truename' if it detects an
error. This works one or two times, but then the (remote) compilation
process comes in conflict with the (remote) Tramp process responsible
for `file-truename'.

The following patch has fixed the issue for me on my FreeBSD machine. It
is on top of Emacs' git master; but likely it works also for your Emacs
27 (not tested by me). Could you check, whether this helps you?

> Thanks again!

Best regards, Michael.

[Message part 2 (text/x-patch, attachment)]

Message #49 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Duncan Greatwood <dgbulk <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile in
 Emacs 27.1
Date: Thu, 28 Jan 2021 21:15:38 -0800

[Message part 1 (text/plain, inline)]

Hi Michael -

Got back to this.

Good news! The patch for compile.el, applied to Emacs 27.1, fixes the issue
of the tramp window hanging in my test cases, running tramp from MAC.

There is still one tramp hanging issue I saw in my testing. This is a much
less serious issue (pressing ctrl-G once "unhangs"), but thought I'd
mention it here. LMK if you'd prefer a separate bug report and I'll create
one.

If, during a "make" via tramp with many syntax errors, you click on one of
the early errors produced in the tramp window, the compile pauses and the
source window does not move to the error. Emacs appears to hang.

If you press ctrl-G, then the compile continues, no problem, until
eventually exiting.

I also noticed the same effect if I just try and type a few characters into
the source file while the make is going on - the compile hangs, and emacs
appears to hang, until I press ctrl-G to allow it to continue.

When I perform this operation directly in emacs on the ubuntu machine (i.e.
without using tramp), clicking on an early error message while "make"
continues to run does not hang anything - the "make" process continues and
meanwhile (even before make completes) the source window moves to the error
that I clicked on. Likewise I can type characters into the test.cpp source
file during make without causing a hang.

I am enclosing another test.cpp with even more errors to make it easier to
catch this issue (you can just drop it into the src directory you were
using for the last setup, overwriting the prior test.cpp).

By the way, this time, the issue reproduces for me regardless of whether I
am running the emacs-tramp on a Mac or on an ubuntu client; as you'll
recall, the target host is ubuntu in both cases.

Thanks again for fixing the main hanging issue!
Duncan.

On Tue, Jan 12, 2021 at 7:02 AM Michael Albinus <michael.albinus <at> gmx.de>
wrote:

> Duncan Greatwood <dgbulk <at> gmail.com> writes:
>
> Hi Duncan,
>
> > Meanwhile, good luck with debugging these bug#45518 issues.
>
> Finally, I nailed it down. In the (remote) compilation process, there is
> a process filter, which calls `file-truename' if it detects an
> error. This works one or two times, but then the (remote) compilation
> process comes in conflict with the (remote) Tramp process responsible
> for `file-truename'.
>
> The following patch has fixed the issue for me on my FreeBSD machine. It
> is on top of Emacs' git master; but likely it works also for your Emacs
> 27 (not tested by me). Could you check, whether this helps you?
>
> > Thanks again!
>
> Best regards, Michael.
>

[Message part 2 (text/html, inline)]

[test.cpp (application/octet-stream, attachment)]

Message #52 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Duncan Greatwood <dgbulk <at> gmail.com>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile
 in Emacs 27.1
Date: Fri, 29 Jan 2021 09:53:02 +0100

Duncan Greatwood <dgbulk <at> gmail.com> writes:

> Hi Michael -

Hi Duncan,

> Good news! The patch for compile.el, applied to Emacs 27.1, fixes the
> issue of the tramp window hanging in my test cases, running tramp from
> MAC.

Thanks for the feedback. I've pushed the patch to Emacs' master branch
(aka Emacs 28.0.50). For Emacs 27.2 it is too late, it is already in
pretest, and only fixes for serious regression bugs are possible.

> There is still one tramp hanging issue I saw in my testing. This is a
> much less serious issue (pressing ctrl-G once "unhangs"), but thought
> I'd mention it here. LMK if you'd prefer a separate bug report and
> I'll create one.

I will have a look on this next days, as time permits. No, I don't need
a new bug report.

> Thanks again for fixing the main hanging issue!
> Duncan.

Best regards, Michael.

Message #55 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Duncan Greatwood <dgbulk <at> gmail.com>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile
 in Emacs 27.1
Date: Wed, 10 Feb 2021 16:40:37 +0100

Duncan Greatwood <dgbulk <at> gmail.com> writes:

> Hi Michael -

Hi Duncan,

> There is still one tramp hanging issue I saw in my testing. This is a
> much less serious issue (pressing ctrl-G once "unhangs"), but thought
> I'd mention it here. LMK if you'd prefer a separate bug report and
> I'll create one.

Just an update. I've played with this for a while. I could reproduce,
and I also know where it hangs. It is accept-process-output of the Tramp
process which tries to view the file you have clicked on, vs
accept-process-output of the compile process. Both don't cooperate
sufficiently, and both hang.

I have no idea (yet) how to solve. One idea would be to start the
compilation process in another thread, but this will raise other
problems. There is some WIP to make Tramp thread-safe, but this is
stalled ATM.

> Thanks again for fixing the main hanging issue!
> Duncan.

Best regards, Michael.

Message #58 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Duncan Greatwood <dgbulk <at> gmail.com>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile
 in Emacs 27.1
Date: Thu, 11 Feb 2021 16:22:26 +0100

[Message part 1 (text/plain, inline)]

Michael Albinus <michael.albinus <at> gmx.de> writes:

Hi Duncan,

>> There is still one tramp hanging issue I saw in my testing. This is a
>> much less serious issue (pressing ctrl-G once "unhangs"), but thought
>> I'd mention it here. LMK if you'd prefer a separate bug report and
>> I'll create one.
>
> Just an update. I've played with this for a while. I could reproduce,
> and I also know where it hangs. It is accept-process-output of the Tramp
> process which tries to view the file you have clicked on, vs
> accept-process-output of the compile process. Both don't cooperate
> sufficiently, and both hang.
>
> I have no idea (yet) how to solve. One idea would be to start the
> compilation process in another thread, but this will raise other
> problems. There is some WIP to make Tramp thread-safe, but this is
> stalled ATM.

Since I don't know a general solution yet, I have prepared a small
patch, which suppresses visting remote files as result of a
compilation. Silently. When compilation has finished, everything is back
to normal.

See the appended patch, whether it makes the situation better for you.

>> Thanks again for fixing the main hanging issue!
>> Duncan.

Best regards, Michael.

[Message part 2 (text/x-patch, attachment)]

Message #61 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Duncan Greatwood <dgbulk <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>, 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile in
 Emacs 27.1
Date: Sat, 13 Feb 2021 17:38:06 -0800

[Message part 1 (text/plain, inline)]

Hi Michael -

On Thu, Feb 11, 2021 at 7:22 AM Michael Albinus <michael.albinus <at> gmx.de>
wrote:

> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
> Hi Duncan,
>
> >> There is still one tramp hanging issue I saw in my testing. This is a
> >> much less serious issue (pressing ctrl-G once "unhangs"), but thought
> >> I'd mention it here. LMK if you'd prefer a separate bug report and
> >> I'll create one.
> >
> > Just an update. I've played with this for a while. I could reproduce,
> > and I also know where it hangs. It is accept-process-output of the Tramp
> > process which tries to view the file you have clicked on, vs
> > accept-process-output of the compile process. Both don't cooperate
> > sufficiently, and both hang.
> >
> > I have no idea (yet) how to solve. One idea would be to start the
> > compilation process in another thread, but this will raise other
> > problems. There is some WIP to make Tramp thread-safe, but this is
> > stalled ATM.
>
> Since I don't know a general solution yet, I have prepared a small
> patch, which suppresses visting remote files as result of a
> compilation. Silently. When compilation has finished, everything is back
> to normal.
>
> See the appended patch, whether it makes the situation better for you.
>
[DG] I have applied the patch to tramp-integration.el. The earlier patch in
this thread (to compile.el, fixing the main hang) was also applied.

Unfortunately, the symptoms for this secondary "minor" hang are unchanged
for me.
This is on an Intel Mac running macos 11.2.
GNU Emacs 27.1 (build 1, x86_64-apple-darwin20.3.0, NS appkit-2022.30
Version 11.2 (Build 20D64))  of 2021-02-13
I looked at ./Contents/Resources/lisp/net/tramp-integration.elc
inside /Applications/Emacs.app and it seemed to contain the patch as
expected - at least it contains the string:
    Don't allow remote file operations while compiling
I'm not sure what's up, but LMK if there's anything I can do.

[Message part 2 (text/html, inline)]

Message #64 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Duncan Greatwood <dgbulk <at> gmail.com>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile
 in Emacs 27.1
Date: Sun, 14 Feb 2021 15:15:34 +0100

Duncan Greatwood <dgbulk <at> gmail.com> writes:

> Hi Michael -

Hi Duncan,

> [DG] I have applied the patch to tramp-integration.el. The earlier
> patch in this thread (to compile.el, fixing the main hang) was also
> applied.
>
> Unfortunately, the symptoms for this secondary "minor" hang are
> unchanged for me.

I've tried it with a modified Emacs 27.1 (compile.el), it works for me.

> I looked at ./Contents/Resources/lisp/net/tramp-integration.elc inside
> /Applications/Emacs.app and it seemed to contain the patch as expected
> - at least it contains the string:
>     Don't allow remote file operations while compiling
> I'm not sure what's up, but LMK if there's anything I can do.

You might check, whether the patch has applied at runtime. Check,
whether the two functions are defined: 'C-h f tramp-compile-advice-add'
and 'C-h f tramp-compile-advice-remove'. Well, the function names are
silly; I shall give them better names when pushing the patch.

Check, whether the two hook variables have changed: 'C-h v
compilation-start-hook' (should contain tramp-compile-advice-add) and
'C-h v compilation-finish-functions' (should contain
tramp-compile-advice-remove).

Best regards, Michael.

Message #67 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Duncan Greatwood <dgbulk <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile in
 Emacs 27.1
Date: Mon, 15 Feb 2021 12:21:34 -0800

[Message part 1 (text/plain, inline)]

Michael -

You might check, whether the patch has applied at runtime.

[DG] Thanks for the pointers.

C-h f tramp-compile-advice-add looks fine:

tramp-compile-advice-add is a compiled Lisp function in
‘tramp-integration.el’.

(tramp-compile-advice-add PROC)

Don’t allow remote file operations while compiling.

Remove looks fine also.

'C-h v compilation-start-hook' looks fine:

compilation-start-hook is a variable defined in ‘compile.el’.
Its value is (tramp-compile-advice-add)
Original value was nil

  This variable may be risky if used as a file-local variable.
  You can customize this variable.

Documentation:
Hook run after starting a new compilation process.
The hook is run with one argument, the new process.

and compilation-finish-functions also looks as expected.

Unfortunately, I am still seeing the hang upon clicking on an error
message while the compilation continues. Sorry to report, but it may
actually be worse than before, in that I am seeing some outright crashes of
emacs, i.e. hangs where I cannot recover by pressing ctrl-G multiple times.
I didn't see that previously with this issue, though of course it's
possibly just a coincidence that I did not.

JFYI, I am also seeing this error message displayed immediately after
compilation commences:

Error adjusting window size: (wrong number of arguments (0 . 1) 2)

Best regards as always.
Duncan.

[Message part 2 (text/html, inline)]

Message #70 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Duncan Greatwood <dgbulk <at> gmail.com>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile
 in Emacs 27.1
Date: Tue, 16 Feb 2021 21:09:24 +0100

Duncan Greatwood <dgbulk <at> gmail.com> writes:

> Michael -

Hi Duncan,

> Unfortunately, I am still seeing the hang upon clicking on an error
> message while the compilation continues. Sorry to report, but it may
> actually be worse than before, in that I am seeing some outright
> crashes of emacs, i.e. hangs where I cannot recover by pressing ctrl-G
> multiple times. I didn't see that previously with this issue, though
> of course it's possibly just a coincidence that I did not.

Hmm, just to be sure: you run Emacs 27.1 with the patched compile.el,
and you run Tramp 2.5.0.1 from GNU ELPA, with the patch in tramp-integration.el?

> JFYI, I am also seeing this error message displayed immediately after
> compilation commences:
>
>     Error adjusting window size: (wrong number of arguments (0 . 1) 2)

That seems to be unrelated, but who knows ...

> Best regards as always.
> Duncan.

Best regards, Michael.

Message #73 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Duncan Greatwood <dgbulk <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile in
 Emacs 27.1
Date: Tue, 16 Feb 2021 21:41:39 -0800

[Message part 1 (text/plain, inline)]

Michael -

> Hmm, just to be sure: you run Emacs 27.1 with the patched compile.el,
> and you run Tramp 2.5.0.1 from GNU ELPA, with the patch in
> tramp-integration.el?

Actually, I was running Emacs 27.1 with the patched compile.el, and tramp
*as it comes in 27.1* with the patch applied to tramp-integration.el.

Prompted by your question, I downloaded Tramp 2.5.0.1 from GNU ELPA and
copied those .el files over the tramp files in .../lisp/net, applied
the patch in tramp-integration.el and recompiled the macos application. I
have the patched compile.el included as well, just to be clear.

I checked in run time, tramp-compile-advice-add and compilation-start-hook
are defined as we'd wish.

Unfortunately, I see no change in behaviour. If I click on a syntax error
message while compiling test.cpp in the autotools project via tramp, the
compile hangs until I ctrl-g out.

Not sure why the difference vs. your setup, sorry.

Best regards,
Duncan.

[Message part 2 (text/html, inline)]

Message #76 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Duncan Greatwood <dgbulk <at> gmail.com>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile
 in Emacs 27.1
Date: Wed, 17 Feb 2021 16:39:43 +0100

[Message part 1 (text/plain, inline)]

Duncan Greatwood <dgbulk <at> gmail.com> writes:

> Michael -

Hi Duncan,

> Prompted by your question, I downloaded Tramp 2.5.0.1 from GNU ELPA
> and copied those .el files over the tramp files in .../lisp/net,
> applied the patch in tramp-integration.el and recompiled the macos
> application. I have the patched compile.el included as well, just to
> be clear.

I seriously recommend to use Emacs' package manager for installation,
and NOT to overwrite files in Emacs' installation dir. Experience tells,
that this is always good for trouble in the long run.

> I checked in run time, tramp-compile-advice-add and
> compilation-start-hook are defined as we'd wish.
>
> Unfortunately, I see no change in behaviour. If I click on a syntax
> error message while compiling test.cpp in the autotools project via
> tramp, the compile hangs until I ctrl-g out.
>
> Not sure why the difference vs. your setup, sorry.

Strange. I've reworked the Tramp patch a little bit. Function names have
changed, and more important, it has traces now. Could you please apply
this patch instead of the previous patch in tramp-integration.el? Rerun
your test with tramp-verbose set to 6, and send the Tramp debug buffer
if it still doesn't work as expected.

> Best regards,
> Duncan.

Best regards, Michael.

[Message part 2 (text/x-patch, attachment)]

Message #79 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Duncan Greatwood <dgbulk <at> gmail.com>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile
 in Emacs 27.1
Date: Thu, 25 Feb 2021 19:33:59 +0100

Duncan Greatwood <dgbulk <at> gmail.com> writes:

Hi Duncan,

> Any case, one thing at a time.
>
> I did manage to collect a traces file with emacs -Q.
> I clicked on error message during compile, and compile-in-tramp
> session hung. I ctrl-G-ed out, compilation continued for a while until
> emacs as a whole crashed, with compilation ongoing until that moment.
>
> Traces enclosed.

Just an interim report. I've worked over the last days on the problem.

I gave up the idea to instrument compile-goto-error. The point is that
other packages trust on this function as well, like rgrep. Disabling it
while rgrep runs is a much too heavy limitation.

Tests have shown, that Emacs 25 with the built-in Tramp 2.2.3 does not
show the problem. I'm bisecting Tramp in order to find what has
triggered the regression. That's not so easy, because not all Emacs and
Tramp versions do cooperate. Compatibility issues.

However, I believe the problem didn't exist in Tramp 2.3.1; Tramp 2.3.2
shows the regression. Compatibility issues hinder me to bisect better,
so I have started to compare both code bases. I hope to find the problem
this way, and I hope to fix it then for you and the other Tramp users.

> Duncan.

Stay tuned, and best regards, Michael.

Message #82 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Duncan Greatwood <dgbulk <at> gmail.com>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile
 in Emacs 27.1
Date: Mon, 15 Mar 2021 21:49:01 +0100

Michael Albinus <michael.albinus <at> gmx.de> writes:

Hi Duncan,

> However, I believe the problem didn't exist in Tramp 2.3.1; Tramp 2.3.2
> shows the regression. Compatibility issues hinder me to bisect better,
> so I have started to compare both code bases. I hope to find the problem
> this way, and I hope to fix it then for you and the other Tramp users.

Bisecting has been harder than expected, due to several reasons. At
least I have found the first problematic commit in Emacs, it is
6de77cfa9da18c5e3765c6202b61cef86409e130.

I will still need some time to find a final solution, but for the time
being you could set tramp-use-ssh-controlmaster-options to nil before
you open a remote connection. This shall prevent the problem. I would
appreciate if you could confirm this.

Now I have nailed the problem, I'm quite optmistic to solve it until
release of Tramp 2.5.0.3, scheduled for end of the month.

>> Duncan.

Best regards, Michael.

Message #85 received at 45518 <at> debbugs.gnu.org (full text, mbox):

From: Duncan Greatwood <dgbulk <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 45518 <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile in
 Emacs 27.1
Date: Mon, 15 Mar 2021 18:36:16 -0700

[Message part 1 (text/plain, inline)]

Michael -

> I will still need some time to find a final solution, but for the time
> being you could set tramp-use-ssh-controlmaster-options to nil before
> you open a remote connection. This shall prevent the problem. I would
> appreciate if you could confirm this.
[DG] Happy to.

I checked that I still see the issue (clicking on an error message suspends
compilation until ctrl-G) without this variable being reset.

I then restarted emacs and changed the variable, as confirmed by this
help-variable output:

tramp-use-ssh-controlmaster-options is a variable defined in ‘tramp-sh.el’.
Its value is nil
Original value was t


As you predicted, the issue does *not* show-up
once tramp-use-ssh-controlmaster-options has been reset to nil like this.

This was using the version of tramp that ships with emacs 27.1. The
compile.el patch we discussed earlier is applied. JFYI, the version of ssh
on my mac is:

$ ssh -V
OpenSSH_8.1p1, LibreSSL 2.7.3


Best regards,
Duncan.

[Message part 2 (text/html, inline)]

Message #90 received at 45518-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Duncan Greatwood <dgbulk <at> gmail.com>
Cc: 45518-done <at> debbugs.gnu.org
Subject: Re: bug#45518: Ctrl-G Fails to Interrupt Hung Tramp Remote-Compile
 in Emacs 27.1
Date: Tue, 16 Mar 2021 19:30:27 +0100

Version: 28.1

Duncan Greatwood <dgbulk <at> gmail.com> writes:

> Michael -

Hi Duncan,

> As you predicted, the issue does *not* show-up once
> tramp-use-ssh-controlmaster-options has been reset to nil like this.

Thanks for confirmation! I've pushed a respective patch to Tramp, as
promised it will appear with Tramp 2.5.0.3. If you are curious, you can
check it here: <https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=6c60ecd2d632ad41851e91cc53036a679c391194>.

Until Tramp 2.5.0.3 is released, you can still use the workaround
(setting tramp-use-ssh-controlmaster-options to nil), or you can apply
the patch, as you like.

> This was using the version of tramp that ships with emacs 27.1. The
> compile.el patch we discussed earlier is applied.

Thanks for the reminder: this patch isn't needed anymore.

I'm closing the bug.

> Best regards,
> Duncan.

Best regards, Michael.

Previous Next

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