Re: Killing a hung ssh process in a TRAMP session

[Suvayu Ali]

Hi Michael,

Sorry for the delay in my response, got a little busy with work.

On Thursday 07 January 2010 07:46 AM, Michael Albinus wrote:
> Suvayu Ali<fatkasuvayu+linux@gmail.com>  writes:
>
> > These will be a lot of help when emacs is still responsive,
> > thanks. But usually when this happens, all the frames associated to
> > the emacs server freezes, and doesn't respond to any keyboard or mouse
> > input. I also see similar behaviour whenever TRAMP is busy with the
> > network, say authenticating to the remote server. As soon as its done,
> > every thing goes back to normal. Maybe I should have taken screen
> > shots. :-\
>
> Please apply
>
>    (setq debug-on-error t
>          debug-on-signal t
>          debug-on-quit t)
>
> before the next test. Then, when Emacs hangs, you could try from a shell
>
> # kill -FPE<emacspid>
>
> Don't ask me why, but sometimes Emacs comes back with the FPE signal,
> and you get a backtrace. This I would like to see, because then I could
> protect that code with-local-quit and friends.

These are the steps I took to generate the backtrace, after setting the 
variables as you requested.

* Opened a remote file and edited it.
* Disconnected my network connection.
* Tried to save the file with `C-x C-s'
* After emacs hung, I took a screenshot
* Killed emacs with `kill -FPE <emacs_pid>'
* Copied the backtrace to a buffer, saved it as raw-text.
* Executed the kill command again (as emacs was still unresponsive)

I have attached the screenshot and the text file with the backtrace.

Hope this will help. And as always, thanks for the help.

> Best regards, Michael.

--
Suvayu

Open source is the future. It sets us free.

hung-emacs.png
Description: PNG image

tramp-traceback-2.txt
Description: Text document