Bug 821215 - remmina VNC session freezes when pcmanfm brings up Confirm dialog for file-deletion
remmina VNC session freezes when pcmanfm brings up Confirm dialog for file-de...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: remmina (Show other bugs)
16
Unspecified Linux
unspecified Severity medium
: ---
: ---
Assigned To: Christoph Wickert
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-13 03:42 EDT by "FeRD" (Frank Dana)
Modified: 2013-02-13 08:23 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-13 08:23:19 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description "FeRD" (Frank Dana) 2012-05-13 03:42:48 EDT
Description of problem:

This is, admittedly, a bit of an esoteric one.

$SERVER is running a secondary vncserver:1 with LXDE session loaded (openbox for the wm).
$DESKTOP is remotely-displaying that session in remmina, using an SSH-encapsulated VNC connection.
If a pcmanfm file browser window is open in the remote session, and the Delete key is pressed to delete a file (which would normally bring up a Confirm dialog box, accompanied by an alert sound), the display freezes immediately after the audible alert. It can be revived using the Refresh option from remmina's Tools menu, at which point the Confirm dialog box is displayed. (It is not shown before the display freeze.)

Version-Release number of selected component (if applicable):
remmina-0.9.3-3.fc16.x86_64

How reproducible:
100% of the time, using pcmanfm. Perhaps-interestingly, the same problem does NOT occur when attempting to delete a root-owned file in nautilus (which also sounds the alert tone, although it doesn't trigger a dialog box).

Steps to Reproduce:
1. Replicate the rather complicated setup above, in as much detail as is necessary to create the proper conditions for the bug (an unknown)
2. Open a remote-desktop session in remmina
3. Open a pcmanfm window in the remote session
4. Highlight a file to be deleted, and press Delete on the keyboard
  
Actual results:
The system sound plays, and the remote session immediately freezes. The mouse pointer is released to the local machine, and can be used to select "Refresh" from the Remmina toolbar's "Tools" menu, recovering the remote session and revealing the pcmanfm Confirm popup.

Expected results:
The system sound plays, and the Confirm popup is displayed with no interruption.

Additional info:
As I mentioned above, this doesn't happen when Nautilus triggers the system sound, which was the only other test I could think of. It would be interesting to test another application that pops up a dialog box, similar to pcmanfm, but I couldn't come up with one offhand.

This is also not a problem when using vncviewer out of tigervnc. While the system sound is not heard, the Confirm dialog pops up immediately with no interruption or freezing of the connection.
Comment 1 "FeRD" (Frank Dana) 2012-05-13 03:49:19 EDT
I'll add that, since discovering the remmina debugging window, I enabled that to watch for any indication what might be causing the freeze problem. There was none (nothing obvious, anyway.) Here's a snippet of the debugging for a session where I triggered the freeze

[SSH] placing 3532 bytes into channel buffer (stderr=0)
[SSH] channel_write wrote 10 bytes
[SSH] channel_write wrote 6 bytes
[SSH] channel_write wrote 6 bytes
[SSH] channel_write wrote 6 bytes
[SSH] placing 849 bytes into channel buffer (stderr=0)
[SSH] channel_write wrote 10 bytes
[SSH] placing 849 bytes into channel buffer (stderr=0)
[SSH] channel_write wrote 10 bytes
[SSH] placing 110 bytes into channel buffer (stderr=0)
[SSH] channel_write wrote 10 bytes
[SSH] channel_write wrote 6 bytes
[SSH] channel_write wrote 6 bytes
[SSH] placing 110 bytes into channel buffer (stderr=0)
[SSH] channel_write wrote 10 bytes
[SSH] channel_write wrote 8 bytes
[SSH] placing 1 bytes into channel buffer (stderr=0)
[SSH] placing 1 bytes into channel buffer (stderr=0)
[SSH] placing 1 bytes into channel buffer (stderr=0)
[SSH] placing 6785 bytes into channel buffer (stderr=0)
[SSH] channel_write wrote 8 bytes
[SSH] channel_write wrote 6 bytes
[SSH] channel_write wrote 6 bytes
[SSH] channel_write wrote 6 bytes
[SSH] channel_write wrote 6 bytes
[SSH] channel_write wrote 6 bytes
[SSH] channel_write wrote 6 bytes
[SSH] channel_write wrote 6 bytes
[SSH] channel_write wrote 6 bytes
[SSH] channel_write wrote 6 bytes
[SSH] channel_write wrote 6 bytes

The freeze occurred at the point where three successive lines are logged containing "placing 1 byte into channel buffer", followed by the large 6K buffer insertion. The string of unbroken channel_write messages that follows represents my mouse movements, which still triggered debug logging even though they were ignored by the remote session (the remote pointer did not track).
Comment 2 Fedora End Of Life 2013-01-16 07:49:22 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 3 Fedora End Of Life 2013-02-13 08:23:22 EST
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.