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

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

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]

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.

[cig0]

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

[bard]

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.

[bard]

@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 happens also on Debian, with Emacs 24.5, and also there ConenctTimeout=1 works the problem around, but this breaks ssh elsewhere.

[thierryvolpiatto]

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

[giordano]

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]

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]

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]

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]

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

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]

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]

See discussion here:

https://lists.gnu.org/archive/html/emacs-devel/2015-07/msg00251.html

[thierryvolpiatto]

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.

[wzhd]

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

Host host.does.not.exist
    ConnectTimeout=1

[thierryvolpiatto]

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

Thanks.

[abergmeier]

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

[thierryvolpiatto]

Andreas Bergmeier <notifications@github.com> writes:

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

Helm is NOT doing or attempting any network connections, but tramp does to setup its options when loading (which is wrong and had been fixed in emacs-25.1). IOW when helm load, it requires tramp which initialize a remote connection. Hope that's clear that helm is NOT doing or attempting any network connections.

…

-- Thierry Gpg Key fingerprint = 6CEC 7081 AB33 E251 4AB8 5FC2 28D1 7F53 59F2 9997