Description of problem: There appears to be some kind of memory leak in Xvnc. I am using it with xrdp and today it was showing over 1/2 GB of residential memory use. My swap was completely exhausted and the whole machine (a VM) was crawling. Version-Release number of selected component (if applicable): 1.0.90-0.11.20100420svn4030.fc13.i686 How reproducible: This is the first time I've seen this, but then again, it's a relatively fresh F-13 install. Steps to Reproduce: 1. Connect to Xvnc behind xrdp over several days. Actual results: Xvnc uses huge amount of memory. Expected results: Wasn't a problem in F-12. Additional info:
New session is at 50 MB already. Started off at about 32 and keeps going up (all RES). In comparison, Xorg on my other machine is stead at 25 MB RES. Something's not quite right...
82 MB RES and going up. Xvnc just topped the list in ps, memory wise. PS. A real time bug ;-)
Left it overnight, climbed by only 1 MB. However, now krb5-auth-dialog is taking 188 MB of RES. On my other machine, it takes only 10 MB. It seems like something both of these link to is causing the leak.
Just rebooted. This time, Xvnc leaking again. krb5-auth-dialog is steady at 10 MB (maybe it went nuts last time because my kerberos password expired - not sure). If it matters, this is a VM running under VMware.
(In reply to comment #3) > Left it overnight, climbed by only 1 MB. However, now krb5-auth-dialog is > taking 188 MB of RES. On my other machine, it takes only 10 MB. > > It seems like something both of these link to is causing the leak. I'm guessing krb5-auth-dialog memory leak is a different problem. So, please ignore it here. I'll open a separate bug for it. It has to do with ticket expired situation.
Hmm, interesting. Xvnc is sitting on 33 MB now, after a few hours of use. This is with -112 kernel, if that somehow matters.
Ah, here we go again - up to 67 MB RES now.
Most definitely still happening. Xvnc at 227 MB RES this morning. Shared seems stable at just under 7 MB. Changing severity/priority in hope it will see some action.
Tried running ltrace -S against Xvnc from a separate ssh session. That killed Xvnc after a moved the mouse, so no luck finding out what's going on.
Definitely leaking again. Up to 176 MB RES now.
Which applications do you use when Xvnc leaks memory? This might be also application bug because it's common that applications ask server to keep data (for example images) for them and don't free it so it might look that it's Xvnc's fault.
I have Evo, FF and Gnome terminal open. Occasionally, I'll open OOo, but even without that the memory use keeps going up.
I have two other memory leak bugs in my view (one opened by me for F-13, the other I can still see in F-13: bug #597669, bug #568693). Is it possible that we have an underlying problem in F-13 under certain conditions?
Up to 235 MB RES today. So, there is a leak somewhere.
Do you have also memory leak problems with the Xorg? Or this is Xvnc specific.
There is a definite memory leak in Xvnc and its specific to tigervnc only because I was using realvnc earlier with the same set of apps (kde4, firefox, thunderbird, konsole, krdc) and there was no leak. My RSS for Xvnc is showing as 615MB currently. My earlier session which lasted for 7 days, had Xvnc reach 1.2GB and I had to restart the session. This is not an application issue. As I said, this doesn't happen if I use realvnc. Also, the same set of apps I use daily on my desktop with Xorg and there is no leak there. I am using ZRLE encoding in client.
Just Xvnc.
RSS of Xvnc gone up to 631MB since the last update. xrestop reports 55MB in pixmaps. Nothing stands out among the clients. Most of them seem to be using less than 100KB but couple of them are using few MBs but max is 14MB (cscope inside an xterm). Total 37 clients. So, this is not client apps.
(In reply to comment #18) > RSS of Xvnc gone up to 631MB since the last update. > > xrestop reports 55MB in pixmaps. Nothing stands out among the clients. Most of > them seem to be using less than 100KB but couple of them are using few MBs but > max is 14MB (cscope inside an xterm). Total 37 clients. So, this is not client > apps. Similar here - 7.5 MB in pixmaps only. The biggest user is gnome-settings daemon with 2.4 MB, followed by nautilus at 1.9 MB and FF at 1.3 MB. Xvnc is using 128 MB of RES memory right now and is the number one process regarding memory use on the system. When Xvnc starts, it is at 20+ MB.
Can you download & test packages from http://koji.fedoraproject.org/koji/taskinfo?taskID=2242970, please? They should fix this issue. Thank you in advance.
(In reply to comment #20) > Can you download & test packages from > http://koji.fedoraproject.org/koji/taskinfo?taskID=2242970, please? They should > fix this issue. Thank you in advance. Can you please give me a patch against the current 1.0.1 release? I went to that page and I don't know what am I supposed to do there. I am using Gentoo, so I build from source.
(In reply to comment #21) > (In reply to comment #20) > > Can you download & test packages from > > http://koji.fedoraproject.org/koji/taskinfo?taskID=2242970, please? They should > > fix this issue. Thank you in advance. > > Can you please give me a patch against the current 1.0.1 release? I went to > that page and I don't know what am I supposed to do there. That link contains binary rpm packages. > I am using Gentoo, so I build from source. Hm, this issue should not be present in the "pure" 1.0.1 release, seems that Gentoo uses same patchset as Fedora. The patch is on http://atkac.fedorapeople.org/tigervnc11-rh597172.patch.
(In reply to comment #20) > Can you download & test packages from > http://koji.fedoraproject.org/koji/taskinfo?taskID=2242970, please? They should > fix this issue. Thank you in advance. Installed it now. Will let you know how it goes over the next few days. PS. Once we get this one sorted, I'll report another problem I'm having with (probably) Xvnc, which is sticky keys. CAPS LOCK doesn't work at all, shift does strange things, including characters being repeated or not working occasionally etc.
Initial RES usage 25 MB, for future reference.
So far, steady on 29 MB RES.
Holding steady on 29 MB RES.
Holding steady at 221MB (KDE4 in Xvnc is fun!) here. So looks like fixed!
Mine went down to 22 MB RES over the weekend. So, yeah, looks like fixed. Thanks!
Thanks for the feedback, I will release the update soon.
tigervnc-1.0.90-0.12.20100420svn4030.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/tigervnc-1.0.90-0.12.20100420svn4030.fc13
tigervnc-1.0.90-0.12.20100420svn4030.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update tigervnc'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/tigervnc-1.0.90-0.12.20100420svn4030.fc13
tigervnc-1.0.90-0.12.20100420svn4030.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
I'm pretty sure this bug needs to be reopened. I saw 45 MB RES yesterday. Today it's at 55 MB RES. When it goes this high, it usually has a leak. Anyone else noticed anything like this with recent tigervnc?
Then again, maybe not. It just dropped back to 42 MB RES.