When I open more than nine or ten mousepad windos in parallel, I can still use one or two of the open windows but the other mousepad windows start to allocate memory until it is exhausted. Only one document is opened in each mousepad window. It can 100% be reproduced on a machine running FreeBSD with 4GB if RAM. On a machine with more RAM, it takes much longer. More details here: http://freebsd.1045724.x6.nabble.com/mousepad-memory-leak-td6233929.html The same issue exists also on Linux.
Can you tell how your Mousepad was configured? Is it Gtk2 or Gtk3? Is DBus single-instance support enabled (--enable-dbus), is it using the standard GSettings backend or the GKeyFile backend? If you can find out what options were passed to `configure` script, it would tell this stuff. FWIW, I can run like 15 windows with files open using single-instance/dbus and the memory sits right at 20MB.
(In reply to Matthew Brush from comment #1) > Can you tell how your Mousepad was configured? Is it Gtk2 or Gtk3? Is DBus > single-instance support enabled (--enable-dbus), is it using the standard > GSettings backend or the GKeyFile backend? > > If you can find out what options were passed to `configure` script, it would > tell this stuff. I also did some tests. I used the binary package provided by the FreeBSD foundations, so built using the ports tree [1] with default options. So the arguments passed to configure are these: --disable-gtk3 --prefix=/usr/local I presume we're using the standard GSettings backend. I made the tests without doing any extra configuration. I saw the same behaviour in a arch Linux virtual machine with XFCE installed, again using the official packages installed via pacman. I don't know how to extract information about configure arguments used in official arch Linux package builds though. If you need any further information please ask. I can also build debugging binaries and test patches on FreeBSD if needed. > > FWIW, I can run like 15 windows with files open using single-instance/dbus > and the memory sits right at 20MB. Maybe there are other factors at play. What I see in my tests is Mousepad taking exponentially longer and using exponentially more ram for each new window open both in opening the new window and in opening files in windows. Editing and closing windows seems unaffected. Closing windows does not release the extra memory from the process. I have also observed significant disk activity from both mousepad and dconf-service (not swap related) during the pause while opening new windows or opening files. Again same behaviour in arch Linux. BTW which Linux distribution are you using? maybe I could test there too and check what is the difference. [1] https://www.freebsd.org/ports/
Would you be able to try building from Git master branch? https://git.xfce.org/apps/mousepad/ There have been some important fixes since that ports package was created. Once checked-out, try running: $ ./autogen.sh --enable-gtk3 --enable-dbus --enable-maintainer-mode --prefix=/where/ever $ make $ make install # as root if needed Of note is the `--enable-dbus` option which will ensure that when you run `mousepad` command, it will just open up new windows in the same process, rather than spawning a new process each time.
(In reply to Matthew Brush from comment #3) > Would you be able to try building from Git master branch? > > https://git.xfce.org/apps/mousepad/ > > There have been some important fixes since that ports package was created. > > Once checked-out, try running: > > $ ./autogen.sh --enable-gtk3 --enable-dbus --enable-maintainer-mode > --prefix=/where/ever > $ make > $ make install # as root if needed Thanks, I will need a little time to perform this test. > > Of note is the `--enable-dbus` option which will ensure that when you run > `mousepad` command, it will just open up new windows in the same process, > rather than spawning a new process each time. I will use that flag. Anyway in my tests I have always seen only one Mousepad process in ps and top output.
Hi, (In reply to Matthew Brush from comment #1) > Can you tell how your Mousepad was configured? Is it Gtk2 or Gtk3? Is DBus > single-instance support enabled (--enable-dbus), is it using the standard > GSettings backend or the GKeyFile backend? FreeBSD allows me only to take GTK2 or GTK3, I took GTK2. > > If you can find out what options were passed to `configure` script, it would > tell this stuff. > > FWIW, I can run like 15 windows with files open using single-instance/dbus > and the memory sits right at 20MB. Same here when I do it on a machine with more than 4GB RAM. Erich
(In reply to Matthew Brush from comment #3) > Would you be able to try building from Git master branch? > > https://git.xfce.org/apps/mousepad/ that machine will be offline for most likely two more weeks. > > There have been some important fixes since that ports package was created. > > Once checked-out, try running: > > $ ./autogen.sh --enable-gtk3 --enable-dbus --enable-maintainer-mode > --prefix=/where/ever > $ make > $ make install # as root if needed > > Of note is the `--enable-dbus` option which will ensure that when you run > `mousepad` command, it will just open up new windows in the same process, > rather than spawning a new process each time.
(In reply to Matthew Brush from comment #3) > Would you be able to try building from Git master branch? > > https://git.xfce.org/apps/mousepad/ > > There have been some important fixes since that ports package was created. > > Once checked-out, try running: > > $ ./autogen.sh --enable-gtk3 --enable-dbus --enable-maintainer-mode > --prefix=/where/ever > $ make > $ make install # as root if needed > > Of note is the `--enable-dbus` option which will ensure that when you run > `mousepad` command, it will just open up new windows in the same process, > rather than spawning a new process each time. Thanks for the suggestion. I followed a different strategy, I imported the differences from the release in the FreeBSD port as patches, so I got something I can commit to the official ports tree and fix it for other FreeBSD users. I have tested it and can't reproduce the problem anymore, so the bug was actually already fixed on your part. Is a "0.4.1" release of mousepad planned? Since these patches are fixing an actual bug that looks like a reasonable thing.
> Is a "0.4.1" release of mousepad planned? Since these patches are fixing an actual bug that looks like a reasonable thing. Yeah, there are some other important fixes since last release too, I just don't really know how to do it using Xfce infrastructure. I'll see if I can at least make a Git tag in the near future.