2

I'm working on a project that is kept on a shared server (server runs Ubuntu 14.04 LTS; my machine runs OS X 10.10.2). I access the server files via Tramp using a password-secured SSH connection. Whenever I try to use Helm to navigate between files in the project I'm working on, Emacs freezes with the following message in the minibuffer:

Tramp: Opening connection for [username]@[server] using scp...

Emacs is unresponsive after this. A few minutes later, it says the connection was failed:

Tramp: Opening connection for [username]@[host] using scp...failed

It remains unresponsive at this point indefinitely. I need to kill the process or force quit the application so I can reopen it. Backtrace under lldb doesn't give any useful information, probably because the program isn't really crashing - it's being terminated after becoming unresponsive.

Any idea what might be going on / how to diagnose the issue / what to do to fix it?

EDIT: Backtrace available at https://gist.github.com/JDRomano2/eb95345b7cd3c1c71911

JDRomano2
  • 21
  • 4
  • [this answer](http://emacs.stackexchange.com/questions/5410/how-to-kill-a-buffer-when-it-causes-emacs-to-stop-responding/7893#7893) might be relevant. In this case, you do want a backtrace for debugging. – PythonNut Feb 09 '15 at 16:06
  • 1
    The suggestions on that page didn't help. I'm not simply trying to find a way to make Emacs responsive again - rather I'm trying to make Helm actually work over SSH. I also posted a link to the backtrace above. – JDRomano2 Feb 09 '15 at 16:17
  • 2
    This is for debugging. The backtrace produced by Emacs is easier to understand because it's at a higher level (it will tell you what functions were running, etc.) The problem with the `lldb` backtrace is that it doesn't contain information about `helm`. – PythonNut Feb 09 '15 at 16:26

0 Answers0