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 · 23 comments

Projects

None yet

9 participants

@oppenlander

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
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.

@jeroentbt

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

@jeroentbt

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

@oppenlander

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

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.

@i90rr
i90rr 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
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

@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
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
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
Member

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

@giordano
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
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

@fvaresi
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
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
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
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
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 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
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.

@azuwis azuwis added a commit to azuwis/ansible-pc that referenced this issue Jan 4, 2016
@azuwis azuwis Let host.does.not.exist return NXDOMAIN 22b5dcb
@Vodurden Vodurden added a commit to Vodurden/devbox that referenced this issue Feb 17, 2016
@Vodurden Vodurden 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
bdecf8d
@wzhd
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
Member

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

Thanks.

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