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

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

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

dgbulk
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))








Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
Duncan Greatwood <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

dgbulk
In reply to this post by dgbulk
Hi Michael,

On Wed, Dec 30, 2020 at 2:36 AM Michael Albinus <[hidden email]> wrote:
Duncan Greatwood <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
Duncan Greatwood <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
Michael Albinus <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

dgbulk
In reply to this post by dgbulk
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@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 <[hidden email]> wrote:
Michael Albinus <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
Duncan Greatwood <[hidden email]> 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* (208K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

dgbulk
In reply to this post by dgbulk
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.
Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
Duncan Greatwood <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

dgbulk
In reply to this post by dgbulk
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!



Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
Duncan Greatwood <[hidden email]> 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@host:")
                   "direct-async-process" t))

on a fresh Emacs instance, before you connect to
remote. "/ssh:user@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.



Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
In reply to this post by dgbulk
Duncan Greatwood <[hidden email]> 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.


attachment0 (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

dgbulk
In reply to this post by dgbulk
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 <[hidden email]> wrote:
Duncan Greatwood <[hidden email]> 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.

test.cpp (41K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
Duncan Greatwood <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

dgbulk
In reply to this post by dgbulk
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.


Reply | Threaded
Open this post in threaded view
|

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

dgbulk
In reply to this post by dgbulk
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.



Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
Duncan Greatwood <[hidden email]> 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.


attachment0 (2K) Download Attachment