Emacs unexpectedly stalls on remote image

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Emacs unexpectedly stalls on remote image

Mikhail P

Greetings,

I am experiencing hangs when opening remote images in Emacs using tramp.

I ran the following

emacs -Q --eval="(progn (add-to-list 'load-path \"/path/to/tramp/install/dir/tramp\") (require 'tramp) (setq tramp-verbose 10) (setq tramp-use-ssh-controlmaster-options nil) (setq tramp-debug-to-file t))"  /ssh:horsehop:/storage1/mikpom/wizard_devel/CNV/figs/TCGA_CNV/ATP23/TCGA-02-2485.png

After that, on resizing the window with image or the whole frame Emacs stalls. The hang occurred from 10:29 till 10:35 (as seen from timestamps in attached file) when I interrupted it with C-g.

-Thanks,

Mikhail

PS Interrupting was not feasible on some occasions so I tried to debug with (tramp-debug-to-file t). Anyhow, if it is self-contained bug report file, it is a convenient way to email necessary information, compared to saving the buffers.



*debug tramp ssh horsehop* (2M) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Emacs unexpectedly stalls on remote image

Michael Albinus
Mikhail P <[hidden email]> writes:

> Greetings,

Hi Mikhail,

> After that, on resizing the window with image or the whole frame Emacs
> stalls. The hang occurred from 10:29 till 10:35 (as seen from
> timestamps in attached file) when I interrupted it with C-g.

Thanks for the debug info. It explains what happens, best seen in the
backtrace.

> 10:35:15.924058 tramp-accept-process-output (10) #
>   backtrace()
>   tramp-signal-hook-function(quit nil)
>   accept-process-output(#<process *tramp/ssh horsehop*> nil nil t)
>   tramp-accept-process-output(#<process *tramp/ssh horsehop*>)

[...]

>   file-readable-p("/ssh:horsehop:/storage1/mikpom/wizard_devel/CNV/fi...")
>   image-toggle-display-image()
>   image-fit-to-window(#<window 3 on TCGA-02-2485.png>)
>   apply(image-fit-to-window #<window 3 on TCGA-02-2485.png>)
>   timer-event-handler([t 0 1 0 nil image-fit-to-window (#<window 3 on TCGA-02-2485.png>) idle 0])
>   accept-process-output(#<process *tramp/ssh horsehop*> nil nil t)
>   tramp-accept-process-output(#<process *tramp/ssh horsehop*>)

[...]

>   file-readable-p("/ssh:horsehop:/storage1/mikpom/wizard_devel/CNV/fi...")
>   image-toggle-display-image()
>   image-fit-to-window(#<window 3 on TCGA-02-2485.png>)
>   apply(image-fit-to-window #<window 3 on TCGA-02-2485.png>)
>   timer-event-handler([t 0 1 0 nil image-fit-to-window (#<window 3 on TCGA-02-2485.png>) idle 0])
>   accept-process-output(#<process *tramp/ssh horsehop*> nil nil t)
>   tramp-accept-process-output(#<process *tramp/ssh horsehop*>)

[...]

>   file-readable-p("/ssh:horsehop:/storage1/mikpom/wizard_devel/CNV/fi...")
>   image-toggle-display-image()
>   image-fit-to-window(#<window 3 on TCGA-02-2485.png>)
>   apply(image-fit-to-window #<window 3 on TCGA-02-2485.png>)
>   timer-event-handler([t 0 1 0 nil image-fit-to-window (#<window 3 on TCGA-02-2485.png>) idle 0])
>   accept-process-output(#<process *tramp/ssh horsehop*> nil nil t)
>   tramp-accept-process-output(#<process *tramp/ssh horsehop*>)

and so on. Obviously, the idle timer image-fit-to-window is called, and
it doesn't finish within the image-auto-resize-on-window-resize time
frame (1 second). So the next idle timer is called on top, which also
doesn't finish in time, etc pp. This confuses Tramp.

I have prepared a patch for tramp-sh.el (appended), which shall prevent
this scenario. Could you pls try, whether this patch fixes your problem?

> -Thanks,
>
> Mikhail

Best regards, Michael.


attachment0 (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Emacs unexpectedly stalls on remote image

Michael Albinus
Mikhail P <[hidden email]> writes:

Hi Mikhail,

> I tried to reproduce the same steps and seems like it did not fix the
> issue.

In which way it isn't fixed? My local tests have shown, that an image in
a remote buffer is resized, after changing window size. Doesn't this
happen to you?

> Attaching debug file and tramp-sh.el after applying the patch.
>
> Also I get the messages:
>
> Error running timer ‘image-fit-to-window’: (file-error "Forbidden
> reentrant call of Tramp")
> File error: Forbidden reentrant call of Tramp [5 times]

This is expected, I see them as well. My patch changes Tramp such a way,
that it prevents timers to run remote commands when they shouldn't. The
error message is the result of the patch; guilty timers must be adapted
to avoid this case.

Until now, they didn't care, and so they have blocked Emacs like in your case.

> Best,
> Mikhail

Best regards, Michael.

Reply | Threaded
Open this post in threaded view
|

Re: Emacs unexpectedly stalls on remote image

Michael Albinus
Mikhail P <[hidden email]> writes:

> Hi Michael,

Hi Mikhail,

> I tried the new version and emacs does not hang. Also the resizing has
> become much faster (I suspect I have the same connection speed and it
> was very slow with your initial patch).

Thanks for the reply. I haven't done something special wrt performance
in my patch. However, my final patch uses a different approach; maybe
this has also some performance improvement consequences :-)

> However I do see "Error running timer..." messages and I occasionally
> get unexpected ... changed on disk; really edit buffer? prompt.

In Emacs' etc/NEWS file I've dropped the note

--8<---------------cut here---------------start------------->8---
If such an error occurs, please report this as bug via 'M-x report-emacs-bug'.
Until it is solved you could ignore such errors by performing

    (setq debug-ignored-errors (cons 'remote-file-error debug-ignored-errors))
--8<---------------cut here---------------end--------------->8---

This setting might be helpful for the time being. The bug report shall
still be submitted, and I'll inspect also your debug output later on,
when time permits.

> I am aware that the code for image display is well outside of TRAMP
> and separate report should be submitted. I am attaching a tramp debug
> file I got when opening the image in a clean session (no .emacs conf)
> and playing with resizing it. On the last resize I got buffer edit
> prompt. Let me know if this has to be submitted to general Emacs bug
> reporting list.

Yes, I believe it fits all together. But since this is not my game
field, a bug report might involve other Emacs developers for fixing it.

> Thanks,
>
> Mikhail

Best regards, Michael.

Reply | Threaded
Open this post in threaded view
|

Re: Emacs unexpectedly stalls on remote image

Michael Albinus
Michael Albinus <[hidden email]> writes:

Hi Mikhail,

>> I am aware that the code for image display is well outside of TRAMP
>> and separate report should be submitted. I am attaching a tramp debug
>> file I got when opening the image in a clean session (no .emacs conf)
>> and playing with resizing it. On the last resize I got buffer edit
>> prompt. Let me know if this has to be submitted to general Emacs bug
>> reporting list.
>
> Yes, I believe it fits all together. But since this is not my game
> field, a bug report might involve other Emacs developers for fixing it.

Just a wild guess: does the appended patch to image-mode.el helps?

>> Thanks,
>>
>> Mikhail

Best regards, Michael.


attachment0 (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Emacs unexpectedly stalls on remote image

Michael Albinus
Mikhail P <[hidden email]> writes:

> Hi,

Hi Mikhail,

> I tried it and emacs stalls occasionally though not on every resize.
>
> Attaching the debug file

Thanks. According to the debug file, there are further remote file
operations. verify-visited-file-name this case.

> Let me know if I can help any further.

Since this dives too deep into the image-mode.el code, I cannot do much
further. Plas write the bug report.

> -Mikhail

Best regards, Michael.