Re: [Gnash-dev] Gnash0.8.2 memory usage improvement on ARMv6 -- seeking support

[Hong Yu]

Thanks for the suggestions! Unfortunately my tasks recently would not 
allow for the time. In our opinion, we reply more on 'valgrind 
--tool=memcheck's and 'valgrind --tool=massif's reports. And this is 
certainly THE .swf file that leads to crash and 'std::bad_alloc' on ARMv6.

And in our opinion, the flash file may be more important for you to 
debug multi-sound-layer-handling; the memory problem here is only an 
associated case, which has not happened when AudioDecoderFfmpeg be 
correctly chosen.

Best regards,

Hong Yu



Sandro Santill wrote:
> On Fri, May 02, 2008 at 04:08:45PM +0800, Hong Yu wrote:
>   
> > Attached is the SWF file that let gnash-0.8.2 hit memory leak 
> >     
>
> Using gnash-cvs for the test.
>
> Running the movie now with -r1 to exclude sound handling (no click on play):
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  1436 strk      15   0 70368  43m  10m S  3.7  2.8   0:14.01 lt-gtk-gnash
>  1436 strk      15   0 70360  43m  10m R  3.7  2.8   0:16.41 lt-gtk-gnash
>  1436 strk      15   0 70364  43m  10m S  3.7  2.8   0:18.15 lt-gtk-gnash
>  1436 strk      15   0 70360  43m  10m S  4.0  2.8   0:23.00 lt-gtk-gnash
>
> Memory use seems stable to me up to here.
> Now with -r2: only sound, no gui
> (still no click on play -- can't click w/out gui):
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  1599 strk      15   0 61512  32m 9240 S  0.3  2.1   0:02.05 lt-gtk-gnash
>  1599 strk      15   0 61512  32m 9240 S  0.3  2.1   0:02.22 lt-gtk-gnash
>  1599 strk      16   0 61512  32m 9240 S  0.0  2.1   0:02.59 lt-gtk-gnash
>
> Still stable, and also using very low CPU. I guess the time
> sampled is the actual CPU time, and sound handler isn't doing much so 
> the TIME+ field keeps pretty low.
>
> Now w/out -r (both sound and rendering, still no click on play):
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  1692 strk      15   0 78588  51m  12m S  3.3  3.4   0:02.41 lt-gtk-gnash
>  1692 strk      15   0 78580  51m  12m S  4.0  3.4   0:03.72 lt-gtk-gnash
>  1692 strk      15   0 78588  51m  12m R  4.0  3.4   0:05.13 lt-gtk-gnash
>  1692 strk      15   0 78588  51m  12m S  3.7  3.4   0:07.62 lt-gtk-gnash
>
> Click on play now (and no sound):
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  1812 strk      25   0 70764  43m  10m R 97.9  2.9   0:27.39 lt-gtk-gnash
>  1812 strk      25   0 72400  45m  10m R 89.9  3.0   1:36.76 lt-gtk-gnash
>  1812 strk      25   0 70832  43m  10m R 97.9  2.9   0:53.61 lt-gtk-gnash
>  1812 strk      25   0 70620  43m  10m R 95.9  2.9   2:26.15 lt-gtk-gnash
>  1812 strk      25   0 71156  43m  10m R 92.2  2.9   3:33.05 lt-gtk-gnash
>  1812 strk      25   0 70804  43m  10m R 89.9  2.9   4:07.50 lt-gtk-gnash --- 
> end
>  1812 strk      25   0 70804  43m  10m R 96.2  2.9   4:33.11 lt-gtk-gnash
>
> Note that I did run with -d1 so didn't really look at it for 4+ hours :)
> The last time (---end) is on the last frame, you can see memory doesn't grow.
>
> That's all for now, just wanted to check there was no leak w/out sound.
> For a proper sound leak analisys, I suggest you produce a custom testcase
> with the components you think are leaking. Ideally the testcsae would be
> run automatically on make check. See also the existing tests and check
> if they leak.
>
> --strk;
>
>
>
>
>
>
>
> _______________________________________________
> Gnash-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnash-dev
>
>