Skip to content
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
Closed
Labels

Comments

@oppenlander
Copy link

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

@thierryvolpiatto 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
Copy link

@jeroentbt 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
Copy link
Member

@thierryvolpiatto 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
Copy link

@jeroentbt 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
Copy link
Author

@oppenlander 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
Copy link
Author

@oppenlander 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
Copy link

@cig0 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
Copy link

@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
Copy link
Author

@oppenlander 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
Copy link

@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
Copy link

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

@thierryvolpiatto thierryvolpiatto commented Jul 6, 2015

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

@giordano
Copy link

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

@thierryvolpiatto 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
Copy link

@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
Copy link

@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
Copy link

@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
Copy link

@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
Copy link

@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 Helm is broken on Emacs 24.5.1 on Archlinux Helm is hanging forever on Emacs 24.5.1 on Archlinux and others when loading tramp Jul 21, 2015
@thierryvolpiatto
Copy link
Member

@thierryvolpiatto 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
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
Copy link

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

@thierryvolpiatto 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
Copy link

@abergmeier 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
Copy link
Member

@thierryvolpiatto thierryvolpiatto commented May 2, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants
You can’t perform that action at this time.