Re: mousepad memory leak

[Erich Dollansky]

Hi,

On Fri, 19 Jan 2018 10:46:41 +0100
Guido Falsi <m...@madpilot.net> wrote:

> On 01/19/2018 08:41, Erich Dollansky wrote:
> > Hi,
> >
> > when I open more than nine or ten mousepads 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.
>
> It's not easy to diagnose such a problem for people not knowing the
> details of mousepad sources and the libraries it uses.

I know, it looks so easy but it needs a very good knowledge of what is
going on inside.
>
> The people who are most able to help you are the XFCE guys (mousepad
> being part of the xfce desktop). Is this issue FreeBSD specific? If
> not you should definitely report this to the upstream developers.
>
We are a FreeBSD-only shop.

> I'll make a pair of tests in virtual machines to see what happens.
>
> Can you confirm simple steps to reproduce as follows:
>
> - Open 2 mousepad windows and open documents in them

No, you have to open only one document in one windows. On a machine
with only 4GB or RAM, it happens around 10 windows with 10 documents.
The documents are small. Not more than 4KB, plain text, no

> - do some work in one or both

Do nothing but continue to open new windows and then open a single
document in them. I change also workspace between.

> - wait, the leak happens in idle windows

It just happens when the next window is opened. The text never appears
and the text in most other windows disappears. The windows with text
still visible in them are fully usable. I did not notice any limitations
in them.

When I tried the same thing on a machine with 8GB RAM, nothing
happened. It might will happen too when much more windows are opened.

Most important, on the machine with only 4GB, I can reproduce it 100%.

Erich
_______________________________________________
freebs...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-port...@freebsd.org"

[Guido Falsi]

On 01/21/2018 01:44, Erich Dollansky wrote:

>>
>> The people who are most able to help you are the XFCE guys (mousepad
>> being part of the xfce desktop). Is this issue FreeBSD specific? If
>> not you should definitely report this to the upstream developers.
>>
> We are a FreeBSD-only shop.

Great for you and FreeBSD, but understanding if the problem is FreeBSD
specific or not helps in the diagnosis.

Setting up quick jail with some linux distribution is really a fast thing.

>
>> I'll make a pair of tests in virtual machines to see what happens.
>>
>> Can you confirm simple steps to reproduce as follows:
>>
>> - Open 2 mousepad windows and open documents in them
>
> No, you have to open only one document in one windows. On a machine
> with only 4GB or RAM, it happens around 10 windows with 10 documents.
> The documents are small. Not more than 4KB, plain text, no

I did a test in two jails, one with FreeBSD and one with arch linux.

I got the same behavior, so it's not FreeBSD specific. It's not a memory
leak though. It looks more like some limitation in thee mousepad
architecture.

What I did is open mousepad from the xfce menu, open a small text file
in it (some random file from /etc), then choose "new window" from the
menu, open a file in the new window, and so on.

Up to 8 windows it's working as usual, after that it gets slower and
slower, allocation a lot of ram for every operation. It looks like the
allocated memory grows exponentially, after 10-12 windows it allocates
really a lot of memory, this could explaain the behaviour you're seeing.

Since it's doing the same in linux it looks like a bug in the upstream
software so you should report it there:

https://bugzilla.xfce.org/

I also found a bug which looks somewhat similar:

https://bugzilla.xfce.org/show_bug.cgi?id=13978


But don't describe this as a memory leak, because it does not look like
that. Closing the opened windows, while being slow, did actually release
the used memory.

I also noticed that when mousepad was working and allocating memory also
the "dconf-service" process consuming a lot of CPU. I think it's the
communication with this demon which actually has some problems.

Just to know why do you need so many windows, when tabs are available?
Since it looks like a fundamental bug in mousepad cannot you use some
other editor?

--
Guido Falsi <m...@madpilot.net>

[Guido Falsi]

On 01/21/2018 16:03, Guido Falsi wrote:

> But don't describe this as a memory leak, because it does not look like
> that. Closing the opened windows, while being slow, did actually release
> the used memory.
>

I was a little hasty in writing this. It's actually keeping that memory
after closing the windows, so it could be a leak...but there's also
something else "pathological" about it allocating exponentially more
memory for every window.

[Erich Dollansky]

Hi,

On Mon, 22 Jan 2018 21:18:28 +0100
Guido Falsi <m...@madpilot.net> wrote:

> On 01/22/2018 08:36, Erich Dollansky wrote:
>
> > Irony is that I used mousepad the first time for this thinking that
> > it is small, the machine is limited, should still work.
> >
>
> I just committed r459693 which adds commits from the upstream
> repository as patches which address this issue. I have been unable to
> cause the pathological behaviour with these patches, so they work, at
> least to some extent.

perfect. That was real fast.
>
> Please test after upgrading your ports or packages(whatever you use)
> and report back.
>
The affected machine a offline for at least 2 more weeks. I will do
this the moment the machine goes online again.

Erich