Memory leak in 1.4.0.1637

Ask any support questions here
Post Reply
zyxxel
Posts: 3
Joined: Tue Sep 29, 2020 7:00 pm

Memory leak in 1.4.0.1637

Post by zyxxel »

The beta version 1.4 seems to leak a lot of memory.

See attached image - two instances of Explorer++ that has been running for a few days.
Top line is Explorer++ 1.4.0.1637 64-bit
Bottom line is Explorer++ 1.3.1.404 64-bit

Running on a Win7 machine. Both started at same time, using same XML configuration file with originally same 4 folders open.
I have alternated opening music album directories on the two versions of Explorer++

As can be seen, version 1.4.0 has allocated 2.5 GB private RAM while version 1.3.1 has allocated 37 MB.

Notice the huge difference in number of references for version 1.4.0.
And version 1.4.0 has also performed a significantly lager amount of file reads.

It isn't really clear what makes 1.4.0 gobble RAM. Just clicking around between different music album directories does not make the RAM climb or add to number of references or I/O read. But if I revisit at a later time, the RAM is way higher. And while writing this, the number of references have ticked up to 19054. And just looking at the task manager have shown the RAM tick up again and again and again.
Attachments
20201002-explorer++-memory-leak.png
20201002-explorer++-memory-leak.png (7.97 KiB) Viewed 1344 times

zyxxel
Posts: 3
Joined: Tue Sep 29, 2020 7:00 pm

Re: Memory leak in 1.4.0.1637

Post by zyxxel »

10 days later - time to kill the 1.4 version - the 1.3.1 version is ticking strong without exploding RAM usage.
Attachments
20201012-explorer++-memory-leak.png
20201012-explorer++-memory-leak.png (7.72 KiB) Viewed 1314 times

David Erceg
Site Admin
Posts: 905
Joined: Sat Apr 18, 2009 1:46 am

Re: Memory leak in 1.4.0.1637

Post by David Erceg »

There is one situation I'm aware of that can cause memory (and cpu) usage to spike in this sort of way. It has to do with the way folders are managed within the treeview.

When a folder in the treeview is displayed, there's a query that's performed to determine whether the folder has any subfolders (which is then used to remove the expansion arrow, if necessary). The query itself is performed by the shell.

If you have a large zip file, and that zip file is scrolled into view in the treeview, both memory usage and cpu usage will rise as the shell determines whether the item has any subfolders. I'm assuming that's because the shell decompresses the entire file first. The same behavior can be seen in Windows Explorer and past versions of Explorer++.

This leads to a situation where there is sustained cpu usage and memory usage increases over time, even if you're not using the application at all. Even once the process has finished, memory usage doesn't go back to its original level. For example, when showing two zip files in the treeview that come to about 8GB combined, memory usage peaked at around 90MB and then fell to 67MB once the subfolder query process completed (whereas the starting memory usage was about 11MB).

You can test to see whether this is the cause of the behavior you're seeing. First, hide the treeview or disable treeview synchronisation (uncheck Tools > Options > Window > Automatically synchronize treeview with main pane). Then, when you navigate through folders or create new tabs, the treeview selection won't change. If the above is the cause of the behavior, memory usage should stay roughly level.

Although it is possible that there's a memory leak within Explorer++ itself, there's nothing within the application that allocates that amount of memory (especially not hundreds of MBs or more). A leak like that would stand out when running the application in the debugger or under a memory instrumentation tool. I've also tested leaving Explorer++ open for several hours or throughout the day (without using it, however) and have seen no increase in memory usage.

David Erceg
Site Admin
Posts: 905
Joined: Sat Apr 18, 2009 1:46 am

Re: Memory leak in 1.4.0.1637

Post by David Erceg »

After investigating it a bit more, this will have been due to the code used to save data to the XML config file. That code (as well as the code to load from the config file) was leaking a lot of memory. It's not really visible with 1.3.5, because that version loads data once and saves it once. On the other hand, 1.4 saves every 30 seconds, which made the leaks have a much bigger impact.

It should be fixed now in the latest development version.

Edgar5
Posts: 63
Joined: Sun Apr 02, 2017 7:22 am

Re: Memory leak in 1.4.0.1637

Post by Edgar5 »

Hi David!
I have a highly customized version of 1.3.5 which I have designed especially for folks who cannot use a keyboard nor mouse. It is free and open source and I have discussed it here on the form previously. Could you give me a clue as to what you did to resolve this memory leak - at least point me to the relative sections of the code. Thanks!
-Edgar5

David Erceg
Site Admin
Posts: 905
Joined: Sat Apr 18, 2009 1:46 am

Re: Memory leak in 1.4.0.1637

Post by David Erceg »

Hi Edgar, the leaks were fixed in these two commits:

https://github.com/derceg/explorerplusp ... 996adc5ce9
https://github.com/derceg/explorerplusp ... 9f9a0648b0

Quite a few of the resources allocated by the xml load/save functions weren't being freed.

Edgar5
Posts: 63
Joined: Sun Apr 02, 2017 7:22 am

Re: Memory leak in 1.4.0.1637

Post by Edgar5 »

David Erceg wrote:
Fri Oct 30, 2020 8:33 am
the leaks were fixed in these two commits
Thanks David! That's a lot to look at and I will need to hold off for a month or so before I dig into it!
-Edgar5

Post Reply