Recently XnViewMP was killed by windows after doing almost nothing, and Windows gave me a warning about running low in memory, even though task manager continually showed physical memory running at around 3 to 3.5GB free and another 2GB or so "standby" - containing known data but available if necessary.
The Event viewer showed a message from Resource-Exhaustion-Detector:
Code: Select all
Windows successfully diagnosed a low virtual memory condition. The following programs consumed the most virtual memory: xnview.exe (3372) consumed 13125148672 bytes, firefox.exe (8012) consumed 309899264 bytes, ... etc
So I started the Resource Monitor from the task manager page, and watched while I ran XnViewMP.
When only the file browser window was open and I was wandering between folders the "Commit" value crept uop from around 25MB to over 100MB and seemed to stabilise.
The Working set looked OK, going up and down in the 100MB to 300MB range.
As soon as I open a single image window in XnView the commit value jumps by 4GB, and sometimes to 8GB.
As I select left or right to go though the images, the commit value bounces around in multiples of 4GB.
When I kill the image window and return to the browser the commit value remains at 4GB until I select a different folder at which time it drops back to the 100MB region.
This is quite reproducible at the moment.
Hmm, I thought this sounded familiar - I reported this a year ago with V0.64: http://newsgroup.xnview.com/viewtopic.php?f=62&t=29312 but then it seemed to be associated with rebuilding thumbnails.
This is not a memory leak as such, because the program eventually frees the memory. It looks like a 32-bit value of -1 is suddenly interpreted as a 64-bit unsigned value.