! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Consumes all memory while idling
Status:
RESOLVED: FIXED
Product:
Xfce4-terminal
Component:
General

Comments

Description Tim Wescott 2015-06-26 19:58:26 CEST
This is on version 0.6.3, which is NOT in the version list!!!!

The bug has the same symptoms as 7871 -- if I leave a terminal window open for long periods of time, it slowly consumes memory.  If leave a window open for a long period it causes the system to slow down so much from memory swapping that I just have to reset to get my computer back.

I've switched to gnome-terminal for the moment, which does not show a hint of this problem.
Comment 1 Tim Wescott 2015-07-02 23:41:12 CEST
I've been using gnome-terminal for the last week -- there's not a whisper of a memory leak problem.  I was ready to believe that there was something with the apps that I often use from the command line that were doing this.  I don't think so.
Comment 2 Igor editbugs 2016-07-27 17:44:17 CEST
Are you also using background image as in bug 7871?
Comment 3 Tim Wescott 2016-07-27 20:15:59 CEST
Igor:

Yes, although it's only apparent when you go into setup.

The default configuration appears to have it set to background image with no file selected.  This also appears (after about 15 minutes of testing each combination), the only thing that causes an automatic and persistent leak.

* Background image, no file: slow leak, about 1MB every minute or so.

* Background image, file selected: no leak apparent

* Transparent background: no leak apparent

* Solid color: no leak apparent

A quick fix going forward would be to simply change the default configuration to something innocuous.
Comment 4 Tim Wescott 2016-07-27 23:06:19 CEST
Sorry for the reverse-update -- after three hours on solid background, the memory footprint for xfce terminal has grown from 26MiB to 32.  So there appears to be a slow leak, still.  More news as it comes in...
Comment 5 Tim Wescott 2016-07-28 03:44:40 CEST
(In reply to Tim Wescott from comment #4)
> Sorry for the reverse-update -- after three hours on solid background, the
> memory footprint for xfce terminal has grown from 26MiB to 32.  So there
> appears to be a slow leak, still.  More news as it comes in...

Steady at 32MiB for the last four hours -- I think it must have jumped up at some point when I wasn't looking, possibly for the screen-saver.  At any rate, it's holding steady.  I'm going to call it good.
Comment 6 Igor editbugs 2016-07-28 10:43:10 CEST
Tim, thanks for the update.

However, I'd left the terminal running overnight, and in the morning it showed exactly the same memory consumption as it'd been showing before I left it. I configured it for using background image (no image set) with 0.82 opacity.

I'm using gtk3/vte3 version built from git. Could you also try it and check if memory leaks for you?
Comment 7 Tim Wescott 2016-07-28 18:47:14 CEST
(In reply to Igor from comment #6)

> I'm using gtk3/vte3 version built from git. Could you also try it and check
> if memory leaks for you?

I'm mostly a "use what's in the Ubuntu repositories" guy, not a "build from source" guy.

If you point me to a short how-to I'll give it a go, however.  I probably just need to know the correct git URL and whether I need to tell the configuration app anything special before I run make.
Comment 8 Igor editbugs 2016-07-29 10:20:25 CEST
I came up to the following instruction which works in my VM Ubuntu 16.04 installation. Please try it and come back in case of any queries.

$ sudo apt-get install build-essential git xfce4-dev-tools libglib2.0-dev libgtk-3-dev libvte-2.91-dev libxfce4ui-2-dev
$ git clone git://git.xfce.org/apps/xfce4-terminal
$ cd xfce4-terminal
$ ./autogen.sh
$ make
$ ./terminal/xfce4-terminal
Comment 9 Tim Wescott 2016-07-31 01:38:06 CEST
(In reply to Igor from comment #8)
> I came up to the following instruction which works in my VM Ubuntu 16.04
> installation. Please try it and come back in case of any queries.

Built fine, appears to run fine, but it doesn't follow the terminal properties set by the "regular" terminal, and when I try to modify them in this software the command line in the terminal from which I launch says:

"xfce4-terminal-CRITICAL **: Failed to load ui file: /usr/share/xfce4/terminal/terminal-preferences.ui:2:41196 Invalid property: GtkHScale.update_policy."

I tried deleting the file, and making an empty file of that name -- neither allowed me to edit (and, hopefully, regenerate) the file.
Comment 10 Igor editbugs 2016-07-31 21:01:08 CEST
Yeah, this is because some properties have been changed in GTK, and GTK3 version is not able to use .ui file created for GTK2 version.
If your old .ui file is not of much value for you (I guess so as you've already tried removing it), you can replace it with the .ui file generated during building:

$ cp ./te
Comment 11 Igor editbugs 2016-07-31 21:02:23 CEST
Sorry...

$ sudo cp ./terminal/terminal-preferences.ui /usr/share/xfce4/terminal/terminal-preferences.ui

This should make it work.
Comment 12 Tim Wescott 2016-08-01 00:01:04 CEST
(In reply to Igor from comment #11)
> Sorry...
> 
> $ sudo cp ./terminal/terminal-preferences.ui
> /usr/share/xfce4/terminal/terminal-preferences.ui
> 
> This should make it work.

Actually, I've been stashing the existing preferences into a temp file, playing my games, then restoring things.

I'm seeing weird stuff.  I put the file where you said and the terminal program let me play with settings.  I had intended to set it up with a picture, verify that memory was not being used, then set the picture to "none" and verify (again) that memory was not being used.

However, the following anomalies occurred:

First, the thing never showed the picture.  I tried with several different pictures.

Second, while the setting persisted across exiting and restarting the terminal program, the terminal-preferences.ui file in the spot that you named never got changed.

So -- I dunno what's going on, but I was unable to fully test for a fix.  Could someone have been aware of the problem and simply disabled the background image functionality entirely, since both opaque and transparent backgrounds work correctly?  It acts like selecting an image file just makes it work the same as selecting transparent background.
Comment 13 Igor editbugs 2016-08-01 11:33:43 CEST
Tim, for your second problem - terminal preferences are not stored in the .ui file, they are stored in ~/.config/xfce4/terminal/terminalrc. The .ui file only describes the interface of the preferences dialog window.

For the first one - the background image functionality has been removed from the vte library (which is used by xfce4-terminal as terminal widget) which means that it's currently impossible to set an image.
But, I'd still want you to check gtk3 version as, according to you, the memory was leaking even if no file was selected:
> Background image, no file: slow leak, about 1MB every minute or so.
Comment 14 Tim Wescott 2016-08-01 20:38:06 CEST
(In reply to Igor from comment #13)
> Tim, for your second problem - terminal preferences are not stored in the
> .ui file, they are stored in ~/.config/xfce4/terminal/terminalrc. The .ui
> file only describes the interface of the preferences dialog window.
> 
> For the first one - the background image functionality has been removed from
> the vte library (which is used by xfce4-terminal as terminal widget) which
> means that it's currently impossible to set an image.
> But, I'd still want you to check gtk3 version as, according to you, the
> memory was leaking even if no file was selected:
> > Background image, no file: slow leak, about 1MB every minute or so.

Ah.  That was a problem with me jumping to conclusions, and then failing to communicate my error properly.

The leap to a conclusion was me only watching the thing with image set for about 15 minutes, and mistaking a temporary uptick in memory usage for a real problem.

The miscommunication was also mine.  I did post about this earlier, but was not clear: if I let it run for a couple of hours, there appears to be no problem.  I started a terminal-with-picture at 9:57 this morning; it reported using 113MiB.  It is now 11:35, and it's been reporting 112MiB for the last hour or so.

Please forgive me for the confusion.  I work in software myself (just not desktop software), and I know how frustrating it can be to chase ghosts.
Comment 15 Igor editbugs 2016-08-01 20:48:25 CEST
OK, and I'd like to make it completely clear :)
Are you observing memory leaks in version 0.6.3? under which circumstances?
Do the same actions/settings lead to memory leaks in version 0.6.90 or git version?
Comment 16 Tim Wescott 2016-08-01 21:17:10 CEST
(In reply to Igor from comment #15)
> OK, and I'd like to make it completely clear :)
> Are you observing memory leaks in version 0.6.3? under which circumstances?
> Do the same actions/settings lead to memory leaks in version 0.6.90 or git
> version?

I am seeing memory leaks in version 0.6.3, only when the thing is set to background image with the file set to none.  I tested all the other combinations I could (background set to file with a file chosen, background set to transparent, background set to solid), and observed no leaks.

I don't have a copy of 0.6.90 -- the version that came with Xubuntu 16.04 is 0.6.3.  

The git version that you had me build (0.7.0git-64c50d1) did not show the problem in any of the combinations I could access (background set to file with a file chosen, which it appeared to allow, background set to transparent, background set to solid).
Comment 17 Igor editbugs 2016-08-02 18:16:30 CEST
(In reply to Tim Wescott from comment #16)
> I am seeing memory leaks in version 0.6.3, only when the thing is set to
> background image with the file set to none.  I tested all the other
> combinations I could (background set to file with a file chosen, background
> set to transparent, background set to solid), and observed no leaks.
Understood, thanks.

> I don't have a copy of 0.6.90 -- the version that came with Xubuntu 16.04 is
> 0.6.3.  
0.6.90 is just a git snapshot that I released as a development release a few days ago. It has no changes in this area comparing to actual git version.

> The git version that you had me build (0.7.0git-64c50d1) did not show the
> problem in any of the combinations I could access (background set to file
> with a file chosen, which it appeared to allow, background set to
> transparent, background set to solid).
What about background image with the file set to none? the only options that is leaking in 0.6.3?
Comment 18 Tim Wescott 2016-08-04 02:53:38 CEST
(In reply to Igor from comment #17)

> What about background image with the file set to none? the only options that
> is leaking in 0.6.3?

Took me a bit to figure out how to coerce that situation (the git-version doesn't allow it, but it'll inherit it if you set it up in 0.6.3).

Works fine.  No problem.
Comment 19 Igor editbugs 2016-08-04 11:17:33 CEST
(In reply to Tim Wescott from comment #18)
> Took me a bit to figure out how to coerce that situation (the git-version
> doesn't allow it, but it'll inherit it if you set it up in 0.6.3).
> 
> Works fine.  No problem.
Ok, thanks!
Closing as fixed.

Bug #12020

Reported by:
Tim Wescott
Reported on: 2015-06-26
Last modified on: 2016-08-04

People

CC List:
1 user

Version

Attachments

Additional information