Summary: | Memory leaks when using the gtk-qt theme engine | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | J Decker <voydmachine> | ||||||||
Component: | SWT | Assignee: | Billy Biggs <billy.biggs> | ||||||||
Status: | RESOLVED WONTFIX | QA Contact: | |||||||||
Severity: | critical | ||||||||||
Priority: | P3 | CC: | andrew.james.barr, billy.biggs, brcosta, douglas.pollock, federico, john.arthorne, shaun.senecal, voydmachine, zanetu | ||||||||
Version: | 3.1 | Keywords: | performance | ||||||||
Target Milestone: | --- | ||||||||||
Hardware: | PC | ||||||||||
OS: | Linux-GTK | ||||||||||
Whiteboard: | |||||||||||
Attachments: |
|
Description
J Decker
2006-02-20 06:26:57 EST
If it's xorg that is taking the memory, then it could be a leak of SWT resources by some plugin. Moving to SWT, where they may be able to help diagnose this further. CCing Doug, who I believe is also an UBuntu user. I have done some additional testing. Since it is an xserver issue, I have switched drivers from "i810" to "vesa" to see if it is a driver issue. The situation appears to be a little better since some of the memory gets freed after shutting down eclipse. the leak though is still present: ---- before shutting down eclipse --- xrestop - Display: localhost:0 Monitoring 27 clients. XErrors: 0 Pixmaps: 1061293K total, Other: 267K total, All: 1061561K total res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 3000000 1031 138 1 11191 288 1036264K 35K 1036299K ? C/C++ - Logger.h - Eclipse SDK --- top before --- Mem: 1026948k total, 1009304k used, 17644k free, 19676k buffers Swap: 1799272k total, 738872k used, 1060400k free, 115176k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ nFLT COMMAND 29304 root 15 0 1071m 488m 2428 S 16.5 48.7 30:13.95 11k Xorg 4478 auser 15 0 538m 165m 11m S 0.0 16.5 7:22.75 992 java 5341 auser 15 0 124m 48m 15m S 0.0 4.9 1:50.30 226 firefox-bin --- xrestop after --- xrestop - Display: localhost:0 Monitoring 27 clients. XErrors: 26 Pixmaps: 27952K total, Other: 193K total, All: 28145K total res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 3200000 336 155 1 888 213 18756K 17K 18774K ? Bug 128617 - xserver (Xorg) allocates a large amount of memory - Mozilla Firefox 1800000 35 12 1 120 1755 6113K 43K 6157K ? KDE Desktop --- top after --- Mem: 1026948k total, 776936k used, 250012k free, 23480k buffers Swap: 1799272k total, 718084k used, 1081188k free, 130600k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ nFLT COMMAND 29304 root 15 0 938m 405m 1856 S 26.4 40.4 32:48.31 13k Xorg 5341 auser 16 0 133m 59m 19m S 0.0 6.0 2:11.80 344 firefox-bi ------------------ No, I'm not an ubuntu user. However, could you run a small application called "wininfo" (http://www.freedesktop.org/wiki/Software_2fwininfo)? It gives information about whichever application's window is under the mouse. Most interesting would be the "Server Resources" tab. You might be able to tell us where all the resources are going (e.g., pixmaps, fonts, etc.). I have reported the bug to the ubuntu folks as well https://launchpad.net/distros/ubuntu/+source/xorg/+bug/32176 First of all, thanks for the replies. I have run wininfo. Though, I think, "xrestop" shows almost the same information. The output of "xrestop" is shown above. I have copied the output of both cases (two different runs): --- xrestop 1 --- xrestop - Display: localhost:0 Monitoring 26 clients. XErrors: 23 Pixmaps: 937942K total, Other: 231K total, All: 938174K total res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 3000000 763 138 1 9978 214 921398K 27K 921425K 12458 1800000 35 12 1 125 2344 6134K 57K 6191K ? KDE Desktop ... the JVM has pid 12458 --- xrestop 2 --- xrestop - Display: localhost:0 Monitoring 27 clients. XErrors: 0 Pixmaps: 1061293K total, Other: 267K total, All: 1061561K total res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 3000000 1031 138 1 11191 288 1036264K 35K 1036299K ? C/C++ - Logger.h - Eclipse SDK -------- I think, the Pxm mem (pixmaps) part is the issue here. Some plugin is likely leaking SWT Images. Can you try running Eclipse for a while with CDT disabled? Can you watch in xrestop while you use Eclipse to see what actions trigger lots of pixmaps to be created? Created attachment 35096 [details]
Screenshot
I have not disabled CDT, yet, since I am soley coding C++...
I thought, that the problem was resolved. Though, suddenly, xorg allocated 1.7G of memory for eclipse (see screenshot). I was moving stuff around in my svn repository, so the compiler produced a lot of errors when I tried to compile my application. Though, I cannot say what exactly allocates so many pixmaps.
Hi, the problem is still not resolved. I have watched wininfo to see what actions trigger memory allocation. Though, I really cannot say what specifically takes the memory away. I am working with CDT. I might be able to disable it and run eclipse without CDT. But, since I am not working then, this might not be a real situation. I really like eclipse but this is a nightmare... what if it is CDT thats leaking? Could it be a specific problem with my system here? I always thought, Java apps cannot leak memory. But I know, SWT uses native libs and the JVM itself is not the issue here. I would appreaciate your comments, Joe ---------- top ----------- Mem: 1026948k total, 974964k used, 51984k free, 5376k buffers Swap: 1799272k total, 1442648k used, 356624k free, 57800k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ nFLT COMMAND 19303 root 15 0 1804m 645m 2380 S 8.0 64.4 17:55.67 206 Xorg 30306 user 15 0 555m 106m 9.8m S 0.0 10.6 11:34.67 889 java --------- xrestop ---------- xrestop - Display: localhost:0 Monitoring 27 clients. XErrors: 0 Pixmaps: 1813874K total, Other: 320K total, All: 1814194K total res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 3400000 1815 138 1 18861 379 1794258K 55K 1794313K ? C/C++ - SomeFile.h - Eclipse SDK Ok, I have done some more investigation: Here's what I found out. Every time when I run the (developed) program within eclipse, about 2.5 MByte of pixmaps get allocated due to the console output. --- before run --- res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 2e00000 543 138 1 2446 171 182881K 20K 182902K ? C/C++ - Graph.h - Eclipse SDK ------------------- --- after run --- res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 2e00000 543 138 1 2471 171 185381K 20K 185402K ? C/C++ - Graph.h - Eclipse SDK ------------------- The console output is only textual, though stderr is automatically colored red. One thing: I have turned on CDT's "Always clean console before building". Could the console output be the issue here? Cheers I thought it might be the progress dialog/view, but it doesn't seem likely. (I've run some tests on 3.1 and 3.2.) I've done some tests with launching, and again I see nothing. Interesting, it is exactly 25 pixmaps being leaked at exactly 2500KB total. This is exactly 100KB per pixmap (if they are all equal). Do you have any views or editors open that are displaying images? As far as I know, I do not have views or windows open that display images. Thanks for all your efforts so far. In order to have another main pillar, I am in the progress of switching back to vim and gnu autotools build system. Maybe, I have time to debug CDT further. I am experiencing the exact same problem, however, I am not using CDT. Everyone else around here is running RHEL3 which uses XFree86 instead of Xorg (I am on Ubuntu Breezy). For whatever reason, XFree86 doesn't seem to display this problem. I am going to try to eliminate as many plugin's as possible (using the M5 release) to see if I can isolate where the problem is occuring. I also want to try using a newer version of Xorg. It's a little suspicious that the XFree86 folks arent seeing this problem at all. Just a small update... It seems to be tied to cleaning or building somehow. I just installed a fresh&clean build of M5 and reimported my projects. Along the way, I have been using ps to monitor the Xorg process. Everything was going along as expected, until the projects started to build. Each time a build (or a clean?) was initiated I would see ~2MB increase in the resident size of the Xorg process. I also noticed that switching between the "Problems" and "Declarations" tab during the build would also cause additional jumps in memory usage (also ~2MB each). (In reply to comment #14) > I also noticed that switching between the "Problems" and "Declarations" tab > during the build would also cause additional jumps in memory usage (also > ~2MB each). If you close the Problems view (and keep it closed), do you see the same memory spikes? Ya, the same spikes happen. I have closed all of the views down there, and the same problem is happening. However, I just noticed that simply going to "Project"->"Clean..." causes ~700K spike. Each time the "Clean" dialog is opened, another 700K is allocated, but never seems to return when you close the dialog (by cancelling or cleaning). Then, as the "Cleaning Workspace" and "Building WOrkspace" dialogs come up, more spikes are seen. It looks like the "Cleaning Workspace" dialog causes ~1.6M spike and the "Building Workspace" dialog causes ~90K. I havent tried debugging into it yet, so I dont know that it is the dialogs that are causing the problem, but since the issue is with Xorg I'm guessing its related. Shaun, it is wrong to assume that huge memory use by Xorg is a bug in Xorg. Xorg allocates memory for pixmaps as requested by X applications. Memory spikes are almost always client bugs, not bugs in the X server itself. If xrestop shows the memory is used by Eclipse, it is an Eclipse bug. Also, if you are seeing high X pixmap use and you are not using CDT, it is likely this is not the same problem as reported in this bug report. More information is required to know for sure. I didnt mean to imply the problem was actually in Xorg, but that it was tied to the way it is being used. Either way, I have run xrestop and I can see that Eclipse is using more and more Pixmap memory every time a dialog is opened. Currently, xrestop is displaying: res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 2c00000 436 139 1 1048 728 62892K 31K 62923K ? Java - BDPException.java - Eclipse SDK Once I open the "Find" dialog it becomes: res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 2c00000 494 139 1 1059 742 64092K 33K 64125K ? Java - BDPException.java - Eclipse SDK and stays that way after the dialog has been closed. Eventually there are hundreds of megs associated with these pixmaps. As for CDT... It could be that these problems arent related, but I didnt think this bug had been determined to be in CDT. Since the behaviour I'm seeing seems to happen with any dialog, I assume it would affect CDT the same way. If you would like me to create a new bug for this issue, let me know. Is there any other information I can get for you right now? Created attachment 35784 [details]
small SWT test app
when run under Ubuntu (Breezy), this test app will continually allocate X resources, slowly bringing the box down
Has anyone been able to reproduce this? It seems to be specific to using Ubuntu (well, the libs it uses), since I am unable to reproduce the behaviour on RHAS4. I am also not able to reproduce the behaviour by remotely running Eclipse from the AS4 box and displaying to my Ubuntu box. However, when Eclipse (or the little test app I have created) is run from Ubuntu, the number of pixmaps generated continuately grows as the user uses the GUI. Below are the lib versions of the X servers used and the GTK2.0 libs. Ubuntu box: X Window System Version 6.8.2 (Ubuntu 6.8.2-77 20051010174523 root@vernadsky.buildd) Release Date: 9 February 2005 X Protocol Version 11, Revision 0, Release 6.8.2 Build Operating System: Linux 2.6.10 i686 [ELF] Current Operating System: Linux vanssenecal02 2.6.12-10-686 #1 Mon Feb 13 12:18:37 UTC 2006 i686 Build Date: 10 October 2005 GTK2.0 v2.8.6 RedHat AS4 box: X Window System Version 6.8.2 Release Date: 9 February 2005 X Protocol Version 11, Revision 0, Release 6.8.2 Build Operating System: Linux 2.6.9-1.906_ELsmp i686 [ELF] Current Operating System: Linux van-w-01-msiege 2.6.9-11.ELsmp #1 SMP Fri May 20 18:26:27 EDT 2005 i686 Build Date: 13 May 2005 Build Host: tweety.build.redhat.com GTK2.0 v2.4.13 Attached is a little SWT test app that creates a FileDialog, then calls open() in a loop. When this app is run from Ubuntu, resources are allocated by the X process each time open() is called. However, on the AS4 box, no additional resources are allocated each time open() is called. Using xrestop, you can see that on Ubuntu the number of pixmaps generated continues to grow each time a button is clicked. I'm guessing it has something to do with the way SWT interacts with GTK and differences in the GTK versions. I tried to mimic the SWT behaviour in a C++/GTK application and the same increase in pixmaps was observed. The difference between the C++ app and the SWT app was that after the test app was closed, the X resources where returned to the system. Should a new bug be entered for this, or do you feel the issues are related? > when run under Ubuntu (Breezy), this test app will continually allocate X
> resources, slowly bringing the box down
I cannot reproduce using GTK+ 2.8.8 and X.org 6.8.2. I tried with both Sun 1.5.0_04 and Blackdown 1.4.1.
J Decker: Does this test app reproduce the problem for you as well?
what libs do i have to include? it says "The import org.eclipse cannot be resolved"... (In reply to comment #22) > what libs do i have to include? it says "The import org.eclipse cannot be > resolved"... http://www.eclipse.org/swt/eclipse.php (If you have PDE installed, then you can Import "Existing Plug-ins and Fragments" instead of "Existing Projects into Workspace". This avoids requiring to download the SWT ZIP file.) I think this bug is what is happening to me with the Azureus BitTorrent client on Linux i686 (2.6.16) -- Debian unstable. I have tried GNU Java (4.1/1.4.2), Blackdown Java (1.4.2), and Sun Java (1.5.0 update 6) and when Azureus is running under all three of them the Xorg server process slowly and steadily eats up memory until the kernel begins killing processes for lack of memory. X.org server is 7.0. This doesn't appear to happen with the Motif libraries, only the GTK+ ones, but I can't get the UI to work properly with Motif. Just my 2 cents. (In reply to comment #24) > I think this bug is what is happening to me with the Azureus BitTorrent client > on Linux i686 (2.6.16) -- Debian unstable. I have tried GNU Java (4.1/1.4.2), > Blackdown Java (1.4.2), and Sun Java (1.5.0 update 6) and when Azureus is > running under all three of them the Xorg server process slowly and steadily > eats up memory until the kernel begins killing processes for lack of memory. > X.org server is 7.0. This doesn't appear to happen with the Motif libraries, > only the GTK+ ones, but I can't get the UI to work properly with Motif. > > Just my 2 cents. > Yep, I'm 99.99% sure its the same problem (much like Ivory soap). The bug should probably have been logged with Ubuntu, since the problem looks like its a leak in GTK (or one of its dependencies). I was able to simulate the leak using the attached GTK test app, so the problem isnt specific to SWT. If you try newer versions of GTK, the problem goes away. I'm just counting the days until Dapper is released and I can update. This bug against SWT can probably be closed. Which app are you talking about, the SWT one linked above? Created attachment 37946 [details]
GTK test app, mimicing SWT test app
seems to show a pixmap resource leak when using GTK v2.8.6
(In reply to comment #26) > Which app are you talking about, the SWT one linked above? > Sorry, I thought I had attached the GTK app as well as the SWT app. I created a mini GTK app to try to mimic what SWT was doing and you could see the pixmap resources continually growing the same way it does in SWT. I will attach the app now. I am running the gtk test app ... I am just running it, non-interactive - does the memory leak appear this way? I recently upgraded to Ubuntu Dapper (Testing). the pixmaps count is steady so the leak does not appear ... 3400000 39 129 1 33 48 1785K 6K 1791K ? gtktest I have not tested eclipse on dapper since I moved back to vim/autoconf/gdb/esvn, etc. if I continuously click on cancel, the app allocates pixmaps ... I am not into gtk programming, so I don't know if this is normal behaviour after about 10 clicks on cancel, xrestop shows, so the pixmaps count went up from 33 to 308... res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 3400000 43 134 1 308 326 24863K 12K 24875K ? gtktest Federico would know. I'm not a GTK programmer either, so it's possible that there is a bug in my GTK test app. However, the behaviour it exhibits is the same as the SWT test app. As you click on the buttons, the number of pixmaps steadily climbs. When you do the same thing on different versions of GTK, the number of pixmaps does not continue to climb. Does this issue occur in Dapper (Testing) as well? What version of GTK is being used? Question for someone who actually has this problem: what GTK+ theme are you running, what version of GTK+, and which distribution? (In reply to comment #33) > Question for someone who actually has this problem: what GTK+ theme are you > running, what version of GTK+, and which distribution? > Hi, I noticed the memleak when I started to use the gtk-qt theme engine (v0.60), no memory leak with clearlooks here. Ubuntu Breezy Badger 5.10, gtk+-2.8.6, eclipse 3.2 (In reply to comment #34) > (In reply to comment #33) > > Question for someone who actually has this problem: what GTK+ theme are you > > running, what version of GTK+, and which distribution? > > > > Hi, > > I noticed the memleak when I started to use the gtk-qt theme engine (v0.60), no > memory leak with clearlooks here. Ubuntu Breezy Badger 5.10, gtk+-2.8.6, > eclipse 3.2 > Same deal here. gtk-qt, gtk+ v2.8.6, all on Ubuntu Breezy I am also using GTK-Qt. The gtk-qt engine is an extremely buggy piece of crap :( Please use another theme. Closing - yet another bug due to the gtk-qt theme engine. Please file this at bugs.freedesktop.org against the gtk-qt component. Thanks Federico. I am also using gtk-qt ... so it all boils down to changing themes. Thanks. |