search

lils000 / xvid4psp

Automatically exported from code.google.com/p/xvid4psp
GNU General Public License v2.0
0 stars 0 forks source link

Xvid4PSP memory leakage suspicion #11

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
The memory usage of the open application grows constantly during encoding 
process and doesn't fall back after the process finishes.

Win7 eng, Xvid4PSP 5.0.37.177, .NET 4.0

Original issue reported on code.google.com by a.shpi...@gmail.com on 10 Oct 2010 at 10:23

GoogleCodeExporter commented 8 years ago 
How fast and how much it growing up? After starting encoding memory usage was 
xxMb, how much it will be after 30min (1hour, 2 hours, ..) of encoding? In my 
test the difference was ~10Mb and encoding time was few minutes. BUT, if 
Encoder window is minimized, memory usage almost the same. So I guess it is a 
WPF-related memory eating (GUI redrawing with updated progress string and 
progress lines), and not a memory leak. And if memory usage increases for 
10-20(-30)Mb for long time encoding, I think it is normal (for WPF).

Original comment by forc...@gmail.com on 10 Oct 2010 at 11:51

GoogleCodeExporter commented 8 years ago 
It is ~600Mb for ~8-10 hours of encoding and growing. I will timestamp the 
exact values the next time I encode smth of that amount.

Original comment by a.shpi...@gmail.com on 10 Oct 2010 at 12:04

GoogleCodeExporter commented 8 years ago 
Then it`s not normal (but may be it`s still normal for WPF when it redrawing 
window for long time - who knows :) ). Next time please try to minimize Encoder 
window (or even minimize to tray, so it will be not visible at all).

Original comment by forc...@gmail.com on 10 Oct 2010 at 12:20

GoogleCodeExporter commented 8 years ago 
I tried with the encoder window minimized as you advised, after 16hr of 
encoding + 5hr of idleness the memory grew from 580/650Mb to 830/930Mb (Working 
Set/Commit Size). That's definitely less than the last time when the window was 
open and focused. So, the issue is not the blocker as the workaround exists, 
but still some kind of memory leakage is present.

Original comment by a.shpi...@gmail.com on 11 Oct 2010 at 5:08

GoogleCodeExporter commented 8 years ago 
This behaviour is not reproduced with the currently latest version 5.10.305.0 
(2012-09-13) RC32.1, so it can be closed.

Original comment by a.shpi...@gmail.com on 19 Feb 2013 at 7:28

GoogleCodeExporter commented 8 years ago

Original comment by forc...@gmail.com on 20 Feb 2013 at 6:03