Bug 707085 - remmina debugging fills harrdisk!!
Summary: remmina debugging fills harrdisk!!
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: remmina
Version: 15
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Christoph Wickert
QA Contact: Fedora Extras Quality Assurance
URL: https://sourceforge.net/tracker/?func...
Whiteboard:
: 783671 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-24 00:33 UTC by Jason Haar
Modified: 2013-01-10 13:10 UTC (History)
11 users (show)

Fixed In Version: 1.0.1-6.fc17
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-07 11:48:37 UTC
Type: ---


Attachments (Terms of Use)
File to work around the problem; place in /etc/NetworkManager/dispatcher.d/ (1.44 KB, application/octet-stream)
2011-10-08 14:08 UTC, Alan Ernhart
no flags Details

Description Jason Haar 2011-05-24 00:33:05 UTC
Description of problem:

I'm working away on my F15 laptop when suddenly I notice I can't write to disk. Ends up /home is full. Ends up that is caused by a 30G+ ~/.xsession-errors file. Ends up that is caused by debugging output from remmina (which I had added as a startup app)


Version-Release number of selected component (if applicable):


How reproducible:

always. remmina appears to have debugging enabled and it seems to trigger some SSL code that makes it generate huge amounts of SSL errors. Strange thing is the app seems to work just fine - but it's noisily logging to .xsession-errors until it fills the disk. I'm talking 20-30G in 1-2 days - that's pretty massive!


Steps to Reproduce:
1. run remmina
2. use it
3. see lots of SSL errors on stdout
  
Actual results:


Expected results:


Additional info:

In the end I wrapped it in a script to pipe to /dev/null - but I'd imagine lots of people hitting this when F15 goes live

Comment 1 Christoph Wickert 2011-05-25 19:59:49 UTC
(In reply to comment #0)
> 30G+ ~/.xsession-errors file. 

Are you sure this is only form remmina? I don't see this on my machine. What plugins are you using?

Comment 2 Jason Haar 2011-05-25 20:03:58 UTC
Most of them - only missing the devel ones

remmina.x86_64                           0.9.3-3.fc15                   @fedora 
remmina-plugins-common.x86_64            0.9.2-2.fc15                   @fedora 
remmina-plugins-nx.x86_64                0.9.2-2.fc15                   @fedora 
remmina-plugins-rdp.x86_64               0.9.2-2.fc15                   @fedora 
remmina-plugins-telepathy.x86_64         0.9.2-2.fc15                   @fedora 
remmina-plugins-vnc.x86_64               0.9.2-2.fc15                   @fedora 
remmina-plugins-xdmcp.x86_64             0.9.2-2.fc15                   @fedora 
remmina-devel.i686                       0.9.3-3.fc15                   fedora  
remmina-devel.x86_64                     0.9.3-3.fc15                   fedora  

I only use remmina to access M$ terminal servers, so it could be remmina-plugins-rdp

Comment 3 Jason Haar 2011-05-25 20:05:05 UTC
...and it is remmina because I also ran it from a shell and after 10-20 minutes saw  the following roaring across the screen

SSL_write: I/O error
SSL_write: I/O error
SSL_write: I/O error
SSL_write: I/O error
SSL_write: I/O error
SSL_write: I/O error
SSL_write: I/O error
SSL_write: I/O error
SSL_write: I/O error
SSL_write: I/O error
SSL_write: I/O error
SSL_write: I/O error
SSL_write: I/O error
SSL_write: I/O error
SSL_write: I/O error
SSL_write: I/O error
SSL_write: I/O error
SSL_write: I/O error
SSL_write: I/O error

Comment 4 Stijn Tintel 2011-06-07 08:16:42 UTC
Same here when using Remmina to connect to Windows Terminal servers. I am going to symlink .xsession-errors to /dev/null for now, since this problem is wasting my SSD's write cycles.

Comment 5 Dimitar Dimitrov 2011-06-10 11:06:35 UTC
I can confirm exactly the same issue. 
OS: Fedora 15.

Remmina packages:
remmina-plugins-common-0.9.2-2.fc15.x86_64
remmina-plugins-telepathy-0.9.2-2.fc15.x86_64
remmina-plugins-xdmcp-0.9.2-2.fc15.x86_64
remmina-plugins-vnc-0.9.2-2.fc15.x86_64
remmina-0.9.3-3.fc15.x86_64
remmina-plugins-rdp-0.9.2-2.fc15.x86_64

Also notice occasional high CPU load when a terminal session has been opened.

Comment 6 Christoph Wickert 2011-06-13 14:53:04 UTC
Sorry for the late response. I forwarded the report upstream as
https://sourceforge.net/tracker/?func=detail&aid=3315749&group_id=278330&atid=1181674

Comment 7 Alan Ernhart 2011-07-12 01:24:15 UTC
Thanks for taking this upstream. I'd seen this occasionally with Remmina under RHEL 6 and then 6.1, but given that it continues under F15 with the distro-shipped Remmina, I'm ready to provide any details needed to hunt it down and have it fixed. The comments in http://sourceforge.net/tracker/index.php?func=detail&aid=3315749&group_id=278330&atid=1181674 cover the scenario that causes this for me: disrupted network connection (e.g. VPN drop, or moving from wired to wireless in the office). I can provide details on the connection settings if needed and try patches or debug code if that would help.

Remmina's a great tool, and I say that after years of using rdesktop, so I'm glad to help if I can.

Comment 8 Alan Ernhart 2011-10-08 14:03:43 UTC
I've not seen any work on this issue upstream yet, so want to offer the workaround that I've been using for a few months: Network Manager is designed to execute user-provided scripts upon network status changes. I've used this for other stuff, like adjusting DNS search domains, so I extended it to kill remmina upon changes (like changing wifi access points, dropping off the VPN, and so on). Because this leaves the GUI session on the remote Windows system running and ready for a re-connection, the inconvenience of any unneeded killing of remmina is a minor annoyance compared to walked back to my laptop and finding "disk full".

I'm attaching a version of my script, one that only addresses the remmina issue. To use it, read it over first, copy into /etc/NetworkManager/dispatcher.d/ under any name (I thing scripts there are executed in alphanumeric order), and I think you should make it executable (chmod 755 <filename>).

The defect report on sourceforge mentions the case where just a few packets are dropped. I "my" workaround will handle that, but it covers all the main cases.

remmina also runs at very high cpu when failing in this case - I looked into how to effectively monitor it and kill it upon ANY runaway case, but didn't find a good means to do so. I also gave a quick look to the utilities in package inotify-tools to see if I could watch ~/.xsession-errors for sudden growth and kill remmina if it's the culprit. Another option is, if remmina opens ~/.xsession-errors itself (rather than X doing so) upon failure, a once/second loop of lsof could catch this event and kill remmina.

I also tried moving ~/.xsession-errors onto its own modest partition via a symbolic link but didn't get far with that. I should have the chops to make that work, so that's an option.

Comment 9 Alan Ernhart 2011-10-08 14:08:14 UTC
Created attachment 527031 [details]
File to work around the problem; place in /etc/NetworkManager/dispatcher.d/

Comment 10 Stijn Tintel 2011-12-12 10:40:28 UTC
Same problem occurs in Fedora 16.

Comment 11 Jacob 2012-01-03 15:45:22 UTC
I am also getting this bug in Fedora 16.  I am worried about killing my SSD as well.  I think one notification per session would be great.

Comment 12 Christoph Wickert 2012-01-29 19:26:25 UTC
*** Bug 783671 has been marked as a duplicate of this bug. ***

Comment 13 Filipe Rosset 2012-04-23 19:22:28 UTC
I can't reproduce this problem in Fedora 17 (beta) with remmina-1.0.0-1.fc17.x86_64, can anyone reproduce this problem?

Comment 14 Filipe Rosset 2012-04-23 20:10:27 UTC
Actually I was able to reproduce the issue connecting to a server using the IP address instead of the hostname, so I can see warnings like these:

gdi_get_bitmap_pointer: requesting invalid pointer: (0,23) in 32x17
gdi_get_bitmap_pointer: requesting invalid pointer: (0,24) in 32x17
gdi_get_bitmap_pointer: requesting invalid pointer: (0,25) in 32x17
gdi_get_bitmap_pointer: requesting invalid pointer: (0,26) in 32x17
gdi_get_bitmap_pointer: requesting invalid pointer: (0,27) in 32x17
gdi_get_bitmap_pointer: requesting invalid pointer: (0,28) in 32x17
gdi_get_bitmap_pointer: requesting invalid pointer: (0,29) in 32x17
gdi_get_bitmap_pointer: requesting invalid pointer: (0,30) in 32x17
gdi_get_bitmap_pointer: requesting invalid pointer: (0,31) in 32x17
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@           WARNING: CERTIFICATE NAME MISMATCH!           @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The hostname used for this connection (192.168.0.203) 
does not match the name given in the certificate:
server-xxx.example.org
A valid certificate for the wrong name should NOT be trusted!
SSL_read: I/O error
connected to 192.168.0.203:3389
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@           WARNING: CERTIFICATE NAME MISMATCH!           @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The hostname used for this connection (192.168.0.203) 
does not match the name given in the certificate:
server-xxx.example.org
A valid certificate for the wrong name should NOT be trusted!
gdi_get_bitmap_pointer: requesting invalid pointer: (0,13) in 64x13
gdi_get_bitmap_pointer: requesting invalid pointer: (0,14) in 64x13
gdi_get_bitmap_pointer: requesting invalid pointer: (0,15) in 64x13
gdi_get_bitmap_pointer: requesting invalid pointer: (0,16) in 64x13
gdi_get_bitmap_pointer: requesting invalid pointer: (0,17) in 64x13
gdi_get_bitmap_pointer: requesting invalid pointer: (0,18) in 64x13
gdi_get_bitmap_pointer: requesting invalid pointer: (0,13) in 64x13
gdi_get_bitmap_pointer: requesting invalid pointer: (0,14) in 64x13
gdi_get_bitmap_pointer: requesting invalid pointer: (0,15) in 64x13
gdi_get_bitmap_pointer: requesting invalid pointer: (0,16) in 64x13
gdi_get_bitmap_pointer: requesting invalid pointer: (0,17) in 64x13

Comment 15 Benny Amorsen 2012-04-24 11:12:26 UTC
I tried upgrading my F16 with just the remmina from updates-testing on F17. An explicit version dependency between remmina and the remmina plugins might be a good idea, since a mismatch just ends in a segmentation violation without an error message.

Anyway, testing now after upgrading remmina-plugins* and freerdp*

Comment 16 Benny Amorsen 2012-04-24 11:23:42 UTC
Testing failed, when I open an RDP connection I get:

remmina: symbol lookup error: /usr/lib64/freerdp/rdpsnd_pulse.so: undefined symbol: pa_threaded_mainloop_new

I tried upgrading pulseaudio* to match, but the error did not go away.

Comment 17 Christoph Wickert 2012-05-02 11:56:08 UTC
(In reply to comment #16)
> remmina: symbol lookup error: /usr/lib64/freerdp/rdpsnd_pulse.so: undefined
> symbol: pa_threaded_mainloop_new

This is a different problem, please see bug 816692.

Comment 18 Benny Amorsen 2012-05-07 11:34:41 UTC
(In reply to comment #17)
> (In reply to comment #16)
> > remmina: symbol lookup error: /usr/lib64/freerdp/rdpsnd_pulse.so: undefined
> > symbol: pa_threaded_mainloop_new
> 
> This is a different problem, please see bug 816692.

Right, but it was difficult to check the upgrade when I couldn't connect to my server... Anyway, both 707085 and 816692 are gone in 1.0.1-6.fc17, so I am happy.

Thank you!

Comment 19 Christoph Wickert 2012-05-07 11:48:37 UTC
Thanks for the feedback, I will now close this bug.


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