New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Helm is hanging forever on Emacs 24.5.1 on Archlinux and others when loading tramp #1000

Closed
oppenlander opened this Issue Apr 23, 2015 · 25 comments

Comments

Projects
None yet
10 participants
@oppenlander

oppenlander commented Apr 23, 2015

Emacs hangs when a helm command is issued until the command is canceled (hitting C-g) in Emacs, version 24.5.1, on Archlinux.

I've also tried using the emacs-helm.sh script, with the same result: Emacs starts, than hangs until I issue C-g.

Installing through MELPA and through the git method in the README results in the same thing.

@thierryvolpiatto

This comment has been minimized.

Show comment
Hide comment
@thierryvolpiatto

thierryvolpiatto Apr 24, 2015

Member

Don't think this is related to helm but to the emacs version builded by Archlinux.
I have heard about a similar issue on emacs-dev, with emacs on arch, it was not related to helm though.

Member

thierryvolpiatto commented Apr 24, 2015

Don't think this is related to helm but to the emacs version builded by Archlinux.
I have heard about a similar issue on emacs-dev, with emacs on arch, it was not related to helm though.

@jeroentbt

This comment has been minimized.

Show comment
Hide comment
@jeroentbt

jeroentbt Apr 27, 2015

I ran M-x toggle-debug-on-error and my problem was fixed. Even after toggling it back off.
Even after a server restart. Did not try a reboot yet.

jeroentbt commented Apr 27, 2015

I ran M-x toggle-debug-on-error and my problem was fixed. Even after toggling it back off.
Even after a server restart. Did not try a reboot yet.

@thierryvolpiatto

This comment has been minimized.

Show comment
Hide comment
@thierryvolpiatto

thierryvolpiatto Apr 27, 2015

Member

jeroen tiebout notifications@github.com writes:

I ran M-x toggle-debug-on-error and my problem was fixed. Even after toggling it back off.
Even after a server restart. Did not try a reboot yet.

Perhaps try to reinstall completely helm.

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

Member

thierryvolpiatto commented Apr 27, 2015

jeroen tiebout notifications@github.com writes:

I ran M-x toggle-debug-on-error and my problem was fixed. Even after toggling it back off.
Even after a server restart. Did not try a reboot yet.

Perhaps try to reinstall completely helm.

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

@jeroentbt

This comment has been minimized.

Show comment
Hide comment
@jeroentbt

jeroentbt Apr 27, 2015

It was fixed, no change after reinstall.
@oppenlander can you verify that toggling debug-on-error, or reinstalling fixes the issue for you?

jeroentbt commented Apr 27, 2015

It was fixed, no change after reinstall.
@oppenlander can you verify that toggling debug-on-error, or reinstalling fixes the issue for you?

@oppenlander

This comment has been minimized.

Show comment
Hide comment
@oppenlander

oppenlander Apr 28, 2015

Toggling debug-on-error or reinstalling does not fix the issue for me.
Downgrading packages to use 24.4 works, but other applications that build against gnutils break unless they're also downgraded.
Building/using Emacs 25 works, but not all extensions work with 25.

oppenlander commented Apr 28, 2015

Toggling debug-on-error or reinstalling does not fix the issue for me.
Downgrading packages to use 24.4 works, but other applications that build against gnutils break unless they're also downgraded.
Building/using Emacs 25 works, but not all extensions work with 25.

@oppenlander

This comment has been minimized.

Show comment
Hide comment
@oppenlander

oppenlander Apr 28, 2015

I haven't completely solved the issue, but I have an update:

Helm is working, but is taking around 250 seconds for the initial load (I was killing it when it didn't load within 5s).
Going to look in to debugging this once I get some more free time.

oppenlander commented Apr 28, 2015

I haven't completely solved the issue, but I have an update:

Helm is working, but is taking around 250 seconds for the initial load (I was killing it when it didn't load within 5s).
Going to look in to debugging this once I get some more free time.

@cig0

This comment has been minimized.

Show comment
Hide comment
@cig0

cig0 May 4, 2015

FWIW, and I hope this isn't taken as noise, Helm works as expected on Emacs 24.5.1 on Fedora 21.

cig0 commented May 4, 2015

FWIW, and I hope this isn't taken as noise, Helm works as expected on Emacs 24.5.1 on Fedora 21.

@bard

This comment has been minimized.

Show comment
Hide comment
@bard

bard May 4, 2015

Came across a similar problem and in my case it was caused by tramp, which Helm loads. See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20015 (fix: http://lists.gnu.org/archive/html/emacs-diffs/2015-03/msg00137.html)

bard commented May 4, 2015

Came across a similar problem and in my case it was caused by tramp, which Helm loads. See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20015 (fix: http://lists.gnu.org/archive/html/emacs-diffs/2015-03/msg00137.html)

@oppenlander

This comment has been minimized.

Show comment
Hide comment
@oppenlander

oppenlander May 5, 2015

@bard Thanks! Tramp timing out on connections seems to be the issue.
I temporarily solved my problem by setting ConenctTimeout=1 in ~/.ssh/config until I get a chance to figure out what it's actually timing out on.

oppenlander commented May 5, 2015

@bard Thanks! Tramp timing out on connections seems to be the issue.
I temporarily solved my problem by setting ConenctTimeout=1 in ~/.ssh/config until I get a chance to figure out what it's actually timing out on.

@oppenlander oppenlander closed this May 5, 2015

@bard

This comment has been minimized.

Show comment
Hide comment
@bard

bard May 5, 2015

@oppenlander try ping host.does.not.exist (literally), that's the address tramp tries to connect to in order to get a failed connection. If you get anything other than "unknown host" then your ISP's DNS might be catching resolve failures and directing them at its own servers (like OpenDNS used to do, and like my ISP is doing).

bard commented May 5, 2015

@oppenlander try ping host.does.not.exist (literally), that's the address tramp tries to connect to in order to get a failed connection. If you get anything other than "unknown host" then your ISP's DNS might be catching resolve failures and directing them at its own servers (like OpenDNS used to do, and like my ISP is doing).

@giordano

This comment has been minimized.

Show comment
Hide comment
@giordano

giordano Jul 5, 2015

This happens also on Debian, with Emacs 24.5, and also there ConenctTimeout=1 works the problem around, but this breaks ssh elsewhere.

giordano commented Jul 5, 2015

This happens also on Debian, with Emacs 24.5, and also there ConenctTimeout=1 works the problem around, but this breaks ssh elsewhere.

@thierryvolpiatto

This comment has been minimized.

Show comment
Hide comment
@thierryvolpiatto

thierryvolpiatto Jul 6, 2015

Member

Please report this bug on emacs-bug, as it is a tramp bug not helm.

Member

thierryvolpiatto commented Jul 6, 2015

Please report this bug on emacs-bug, as it is a tramp bug not helm.

@giordano

This comment has been minimized.

Show comment
Hide comment
@giordano

giordano Jul 6, 2015

Please report this bug on emacs-bug, as it is a tramp bug not helm.

I would do that, but I can reproduce this bug only through helm (just issue M-x helm-M-x RET and Emacs hangs), but not directly with tramp, I can access files over ssh or sudo flawless.

giordano commented Jul 6, 2015

Please report this bug on emacs-bug, as it is a tramp bug not helm.

I would do that, but I can reproduce this bug only through helm (just issue M-x helm-M-x RET and Emacs hangs), but not directly with tramp, I can access files over ssh or sudo flawless.

@thierryvolpiatto

This comment has been minimized.

Show comment
Hide comment
@thierryvolpiatto

thierryvolpiatto Jul 6, 2015

Member

Mosè Giordano notifications@github.com writes:

Please report this bug on emacs-bug, as it is a tramp bug not
helm.  I would do that, but I can reproduce this bug only through
helm (just issue M-x helm-M-x RET and Emacs hangs), but not
directly with tramp, I can access files over ssh or sudo flawless.

So turn on tramp-verbose to 6 and look at the tramp debug buffer to see
what is calling tramp.

This is not reproductible here on Xubuntu-14.04 (which is similar to
debian)

Also have you compiled your emacs yourself or using the one bundled by
your OS ?

Did you try to reproduce from ./emacs-helm.sh ?

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

Member

thierryvolpiatto commented Jul 6, 2015

Mosè Giordano notifications@github.com writes:

Please report this bug on emacs-bug, as it is a tramp bug not
helm.  I would do that, but I can reproduce this bug only through
helm (just issue M-x helm-M-x RET and Emacs hangs), but not
directly with tramp, I can access files over ssh or sudo flawless.

So turn on tramp-verbose to 6 and look at the tramp debug buffer to see
what is calling tramp.

This is not reproductible here on Xubuntu-14.04 (which is similar to
debian)

Also have you compiled your emacs yourself or using the one bundled by
your OS ?

Did you try to reproduce from ./emacs-helm.sh ?

Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

@fvaresi

This comment has been minimized.

Show comment
Hide comment
@fvaresi

fvaresi Jul 7, 2015

In my case, the delay was caused by a VPN client using a different DNS server while trying to solve the host provided by tramp (host.does.not.exist).

Mapping host.does.not.exist to 127.0.0.1 fixed the issue for me.

fvaresi commented Jul 7, 2015

In my case, the delay was caused by a VPN client using a different DNS server while trying to solve the host provided by tramp (host.does.not.exist).

Mapping host.does.not.exist to 127.0.0.1 fixed the issue for me.

@giordano

This comment has been minimized.

Show comment
Hide comment
@giordano

giordano Jul 7, 2015

So turn on tramp-verbose to 6 and look at the tramp debug buffer to see what is calling tramp.

With the following init file

(setq package-enable-at-startup nil)
(package-initialize)
(setq tramp-verbose 6)
(require 'helm)
(require 'helm-config)
(helm-mode 1)

Emacs takes 135 seconds to start (source: (emacs-init-time)) and I don't get any tramp message nor there is any TRAMP buffer.

As suggested by @fvaresi, mapping host.does.not.exist to 127.0.0.1 fixes the issue for me too. For what is worth, before mapping host.does.not.exist to 127.0.0.1 it does exist but doesn't reply to ping:

$ ping -c 10 host.does.not.exist
PING host.does.not.exist (54.72.52.58) 56(84) bytes of data.

--- host.does.not.exist ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9071ms

Actually, I cannot reproduce the problem from another place with a different Internet connection (that's why I delayed replying), I have to check what happens with ping there.

This is not reproductible here on Xubuntu-14.04 (which is similar to debian) Also have you compiled your emacs yourself or using the one bundled by your OS ?

I use the Emacs package provided by Debian repository.

Did you try to reproduce from ./emacs-helm.sh ?

Yes, same very looong startup.

giordano commented Jul 7, 2015

So turn on tramp-verbose to 6 and look at the tramp debug buffer to see what is calling tramp.

With the following init file

(setq package-enable-at-startup nil)
(package-initialize)
(setq tramp-verbose 6)
(require 'helm)
(require 'helm-config)
(helm-mode 1)

Emacs takes 135 seconds to start (source: (emacs-init-time)) and I don't get any tramp message nor there is any TRAMP buffer.

As suggested by @fvaresi, mapping host.does.not.exist to 127.0.0.1 fixes the issue for me too. For what is worth, before mapping host.does.not.exist to 127.0.0.1 it does exist but doesn't reply to ping:

$ ping -c 10 host.does.not.exist
PING host.does.not.exist (54.72.52.58) 56(84) bytes of data.

--- host.does.not.exist ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9071ms

Actually, I cannot reproduce the problem from another place with a different Internet connection (that's why I delayed replying), I have to check what happens with ping there.

This is not reproductible here on Xubuntu-14.04 (which is similar to debian) Also have you compiled your emacs yourself or using the one bundled by your OS ?

I use the Emacs package provided by Debian repository.

Did you try to reproduce from ./emacs-helm.sh ?

Yes, same very looong startup.

@fvaresi

This comment has been minimized.

Show comment
Hide comment
@fvaresi

fvaresi Jul 7, 2015

@giordano On a similar bug report (#1045) they pointed out that using 127.0.0.1 may cause undesired side effects since the host does exist (and tramp expects it to not exist). So it's better to use an invalid IP.

fvaresi commented Jul 7, 2015

@giordano On a similar bug report (#1045) they pointed out that using 127.0.0.1 may cause undesired side effects since the host does exist (and tramp expects it to not exist). So it's better to use an invalid IP.

@giordano

This comment has been minimized.

Show comment
Hide comment
@giordano

giordano Jul 8, 2015

Ok, I'm persuaded it's a problem with tramp (or my ISP actually): when it tries to evaluate tramp-ssh-controlmaster-options Emacs hangs because my ISP resolves every non existing domain to 54.72.52.58. So, in my case, 127.0.0.1 or 54.72.52.58 is almost the same, at least the former has the port 22 closed and replies immediately. The problem is fixed also by setting tramp-ssh-controlmaster-options to the correct value ("-o ControlMaster=auto -o ControlPath='tramp.%%C' -o ControlPersist=no" in my case) before starting helm. I just wonder why helm needs this variable but tramp itself doesn't, for a basic use.

giordano commented Jul 8, 2015

Ok, I'm persuaded it's a problem with tramp (or my ISP actually): when it tries to evaluate tramp-ssh-controlmaster-options Emacs hangs because my ISP resolves every non existing domain to 54.72.52.58. So, in my case, 127.0.0.1 or 54.72.52.58 is almost the same, at least the former has the port 22 closed and replies immediately. The problem is fixed also by setting tramp-ssh-controlmaster-options to the correct value ("-o ControlMaster=auto -o ControlPath='tramp.%%C' -o ControlPersist=no" in my case) before starting helm. I just wonder why helm needs this variable but tramp itself doesn't, for a basic use.

@theherk

This comment has been minimized.

Show comment
Hide comment
@theherk

theherk Jul 18, 2015

In my case, the problem was T-Mobile's DNS. I hate that some companies do this, but they hijack non-existent url's. I was getting a 301 on non-existent hosts. Editing my resolv.conf to OpenNIC DNS resolved the issue.

theherk commented Jul 18, 2015

In my case, the problem was T-Mobile's DNS. I hate that some companies do this, but they hijack non-existent url's. I was getting a 301 on non-existent hosts. Editing my resolv.conf to OpenNIC DNS resolved the issue.

@thierryvolpiatto

This comment has been minimized.

Show comment
Hide comment
Member

thierryvolpiatto commented Jul 21, 2015

@thierryvolpiatto thierryvolpiatto changed the title from Helm is broken on Emacs 24.5.1 on Archlinux to Helm is hanging forever on Emacs 24.5.1 on Archlinux and others when loading tramp Jul 21, 2015

@thierryvolpiatto

This comment has been minimized.

Show comment
Hide comment
@thierryvolpiatto

thierryvolpiatto Jul 21, 2015

Member

So to resume, to fix this issue, you have to switch to emacs-25 or use the last version of tramp, or modify tramp-ssh-controlmaster-options according to the discussion above.

Member

thierryvolpiatto commented Jul 21, 2015

So to resume, to fix this issue, you have to switch to emacs-25 or use the last version of tramp, or modify tramp-ssh-controlmaster-options according to the discussion above.

azuwis added a commit to azuwis/ansible-pc that referenced this issue Jan 4, 2016

Vodurden added a commit to Vodurden/devbox that referenced this issue Feb 17, 2016

Fix freeze on load caused by helm issue.
There seems to be an issue between helm and the specific version
of emacs used by Arch. This commit adds a patch that should resolve the
issue.

When Emacs 25 is available we should remove the patch and see if the issue
still exists.

See: emacs-helm/helm#1000
@wzhd

This comment has been minimized.

Show comment
Hide comment
@wzhd

wzhd May 25, 2016

@giordano You can set the ConnectTimeout option for only one host in ~/.ssh/config:

Host host.does.not.exist
    ConnectTimeout=1

wzhd commented May 25, 2016

@giordano You can set the ConnectTimeout option for only one host in ~/.ssh/config:

Host host.does.not.exist
    ConnectTimeout=1
@thierryvolpiatto

This comment has been minimized.

Show comment
Hide comment
@thierryvolpiatto

thierryvolpiatto Jul 7, 2016

Member

Can someone experimenting this issue could set tramp-verbose to 6 and send here the relevant tramp debug buffer ?

Thanks.

Member

thierryvolpiatto commented Jul 7, 2016

Can someone experimenting this issue could set tramp-verbose to 6 and send here the relevant tramp debug buffer ?

Thanks.

@abergmeier

This comment has been minimized.

Show comment
Hide comment
@abergmeier

abergmeier May 1, 2017

Can someone with some in-depth-knowledge explain to me why (potentially long running) networking runs in the main/ui thread?

abergmeier commented May 1, 2017

Can someone with some in-depth-knowledge explain to me why (potentially long running) networking runs in the main/ui thread?

@thierryvolpiatto

This comment has been minimized.

Show comment
Hide comment
@thierryvolpiatto

thierryvolpiatto May 2, 2017

Member
Member

thierryvolpiatto commented May 2, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment