Sat 15 Dec 2007 09:02:07 AM UTC, comment #13:
No, most of the original issues and all the "security" ones seem fixed. I'll close this bug since it's too general and open new bugs for specific issues (when I've worked out what they are).
|
Fri 14 Dec 2007 11:26:47 PM UTC, comment #12:
Fixed more robustness issues, I don't see any security issue with this testcase anymore, do you Ben ?
|
Wed 12 Dec 2007 11:56:26 PM UTC, comment #11:
Some parsing problems have been fixed (just made the parser more robust, still have lots of errors).
Now with -r1 I get CPU at 100% on first big screen with gdb always in agg::curve3_div::recursive_bezier
Might be worth an inspection from the renderer side.
|
Sat 06 Oct 2007 12:36:24 PM UTC, comment #10:
I still get a segfault runnign with -r2 for a couple of minutes.
Ffmpeg version is: Lavc0d.51.11.0
after lots of ERROR: Error while decoding audio data. :
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1238295888 (LWP 26219)]
0xb6b7ea36 in avcodec_decode_video () from /usr/lib/libavcodec.so.0d
(gdb) bt
#0 0xb6b7ea36 in avcodec_decode_video () from /usr/lib/libavcodec.so.0d
#1 0xb7a1b3a5 in gnash::VideoDecoderFfmpeg::decode (this=0x0, input=0x84d1fd0 "xF\n\033\n\033?j��", inputSize=40, outputSize=@0xbfb32008)
at /home/strk/src/gnash/gnash-head/libmedia/sdl/VideoDecoderFfmpeg.cpp:225
#2 0xb7a1b241 in gnash::VideoDecoderFfmpeg::decodeToImage (this=0x87275d8, input=0x84d1fd0 "xF\n\033\n\033?j��", inputSize=40)
at /home/strk/src/gnash/gnash-head/libmedia/sdl/VideoDecoderFfmpeg.cpp:324
#3 0xb7c07134 in gnash::video_stream_instance::display (this=0x82889d8) at /home/strk/src/gnash/gnash-head/server/video_stream_instance.cpp:216
#4 0xb7c88965 in gnash::DisplayList::display (this=0x82027ec) at /home/strk/src/gnash/gnash-head/server/dlist.cpp:809
#5 0xb7bd72bd in gnash::sprite_instance::display (this=0x8202700) at /home/strk/src/gnash/gnash-head/server/sprite_instance.cpp:2696
#6 0xb7bb031a in gnash::movie_root::display (this=0x81511e8) at /home/strk/src/gnash/gnash-head/server/movie_root.cpp:801
#7 0x0808b3a1 in gnash::Gui::display (this=0x814fa20, m=0x81511e8) at /home/strk/src/gnash/gnash-head/gui/gui.cpp:490
#8 0x0808bda6 in gnash::Gui::advanceMovie (this=0x814fa20) at /home/strk/src/gnash/gnash-head/gui/gui.cpp:657
#9 0x080967c0 in gnash::NullGui::run (this=0x814fa20) at /home/strk/src/gnash/gnash-head/gui/gui.h:208
#10 0x08094d7c in gnash::Player::run (this=0xbfb33cf8, argc=5, argv=0xbfb33e04, infile=0xbfb34484 "/home/strk/src/gnash/tests/dogthebountyhunter.swf",
url=0x0) at /home/strk/src/gnash/gnash-head/gui/Player.cpp:348
#11 0x08086262 in main (argc=5, argv=0xbfb33e04) at /home/strk/src/gnash/gnash-head/gui/gnash.cpp:426
|
Sat 06 Oct 2007 11:38:23 AM UTC, comment #9:
Firstly, the leak fixes appear to have worked. Nothing needs to be swapped out any more, so it's clearly staying within reasonable limits.
Ffmpeg version is: Lavc51.28.0
I still see lots of bits_left= (always have done), which probably doesn't help playback speed in itself.
bits_left=1339
bits_left=1102
bits_left=840
bits_left=964
bits_left=1038
bits_left=1038
bits_left=780
bits_left=758
bits_left=654
bits_left=842
bits_left=510
20765] 13:36:48: ERROR: Error while decoding audio data.
20765] 13:36:48: ERROR: Error while decoding audio data.
20765] 13:36:48: ERROR: Error while decoding audio data.
20765] 13:36:48: ERROR: Error while decoding audio data.
20765] 13:36:48: ERROR: Error while decoding audio data.
20765] 13:36:48: ERROR: Error while decoding audio data.
20765] 13:36:48: ERROR: Error while decoding audio data.
20765] 13:36:48: ERROR: Error while decoding audio data.
|
Sat 06 Oct 2007 09:56:50 AM UTC, comment #8:
I've committed some possible leak fixes, though I'm not sure this will solve the issue you are seeing.
Do you still see a lot of 'bits left='? They should have been fixed before libmedia introduction.
What version of ffmpeg do you use? Just copy the result of "gnash --version".
|
Fri 05 Oct 2007 10:08:16 PM UTC, comment #7:
291,404 (800 direct, 290,604 indirect) bytes in 10 blocks are definitely lost
allocated by gnash::SDL_sound_handler::play_sound(int, int, int, long, std::vector<gnash::sound_handler::sound_envelope, std::allocator<gnash::sound_handler::sound_envelope> > const*) (sound_handler_sdl.cpp:180)
|
Fri 05 Oct 2007 10:00:13 PM UTC, comment #6:
Attached.
(file #14095)
|
Fri 05 Oct 2007 09:52:04 PM UTC, comment #5:
Rerun with --leak-check=full to see details of leaked memory.
|
Fri 05 Oct 2007 12:12:24 PM UTC, comment #4:
valgrind gtk-gnash -t60 ~/Download/SWF/dog.swf
report:
==26395==
==26395== Thread 1:
==26395== Conditional jump or move depends on uninitialised value(s)
==26395== at 0x8195A5D: (within /usr/lib64/libasound.so.2.0.0)
==26395== by 0x81909CE: (within /usr/lib64/libasound.so.2.0.0)
==26395== by 0x8165074: snd_pcm_close (in /usr/lib64/libasound.so.2.0.0)
==26395== by 0x8199387: (within /usr/lib64/libasound.so.2.0.0)
==26395== by 0x819939F: (within /usr/lib64/libasound.so.2.0.0)
==26395== by 0x8165074: snd_pcm_close (in /usr/lib64/libasound.so.2.0.0)
==26395== by 0x817D7DC: (within /usr/lib64/libasound.so.2.0.0)
==26395== by 0x8165074: snd_pcm_close (in /usr/lib64/libasound.so.2.0.0)
==26395== by 0x7EA69E3: (within /usr/lib64/libSDL-1.2.so.0.11.0)
==26395== by 0x7E78405: SDL_AudioQuit (in /usr/lib64/libSDL-1.2.so.0.11.0)
==26395== by 0x7E77994: SDL_QuitSubSystem (in /usr/lib64/libSDL-1.2.so.0.11.0)
==26395== by 0x52E0169: gnash::SDL_sound_handler::~SDL_sound_handler() (sound_handler_sdl.cpp:70)
26395] 14:10:16: DEBUG: Loading thread cancelation requested, returning from read_all_swf
==26395==
==26395== ERROR SUMMARY: 1222 errors from 8 contexts (suppressed: 2 from 1)
==26395== malloc/free: in use at exit: 482,938,093 bytes in 15,336 blocks.
==26395== malloc/free: 125,695 allocs, 110,359 frees, 1,302,263,120 bytes allocated.
==26395== For counts of detected errors, rerun with: -v
==26395== searching for pointers to 15,336 not-freed blocks.
==26395== checked 22,689,792 bytes.
==26395==
==26395== LEAK SUMMARY:
==26395== definitely lost: 463,470,106 bytes in 2,730 blocks.
==26395== possibly lost: 17,733,072 bytes in 944 blocks.
==26395== still reachable: 1,734,915 bytes in 11,662 blocks.
==26395== suppressed: 0 bytes in 0 blocks.
==26395== Rerun with --leak-check=full to see details of leaked memory.
|
Fri 05 Oct 2007 11:54:21 AM UTC, comment #3:
Not sure exactly what the problem is. Apart from the following output from top, which is plainly inaccurate, I get lots of hard disk activity, which is a sure sign of excessive swapping that didn't happen with this movie until recently. Media handler ffmpeg.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26183 benjamin 16 0 250m 59m 14m R 23.9 13.8 0:02.39 gtk-gnash
26183 benjamin 15 0 1960m 119m 15m S 74.1 27.4 0:09.83 gtk-gnash
26142 benjamin 15 0 191m 11m 8904 R 0.1 2.6 0:00.08 gtk-gnash
26183 benjamin 18 0 4915m 158m 15m R 75.6 36.5 0:17.39 gtk-gnash
26142 benjamin 15 0 191m 10m 8716 S 0.1 2.5 0:00.09 gtk-gnash
26183 benjamin 25 0 10.5g 202m 12m R 88.1 46.6 0:26.22 gtk-gnash
26183 benjamin 25 0 14.8g 215m 8976 R 98.4 49.6 0:37.01 gtk-gnash
26183 benjamin 25 0 23.9g 274m 3108 R 99.1 63.1 0:48.02 gtk-gnash
26183 benjamin 25 0 26.7g 269m 2652 R 96.3 62.0 0:58.91 gtk-gnash
26183 benjamin 25 0 31.0g 267m 2380 R 97.9 61.5 1:09.30 gtk-gnash
26183 benjamin 25 0 35.5g 256m 2272 R 97.6 59.1 1:19.28 gtk-gnash
26183 benjamin 25 0 39.2g 243m 1952 R 97.2 56.0 1:29.68 gtk-gnash
26142 benjamin 15 0 191m 1788 1360 S 0.1 0.4 0:00.10 gtk-gnash
26183 benjamin 25 0 42.7g 231m 1728 R 97.1 53.2 1:39.46 gtk-gnash
26183 benjamin 25 0 46.1g 223m 1652 R 99.9 51.3 1:50.51 gtk-gnash
26183 benjamin 25 0 51.5g 225m 1644 R 88.9 51.9 2:02.23 gtk-gnash
26183 benjamin 25 0 55.5g 218m 1648 R 99.8 50.2 2:12.60 gtk-gnash
|
Fri 05 Oct 2007 11:09:04 AM UTC, comment #2:
Hmm, i just realized that libmedia isn't in 0.8.1 (I guess it stil a bit early for me...). But I don't see the massive memleak. Though I see CPU going 100%.
|
Fri 05 Oct 2007 11:06:49 AM UTC, comment #1:
Is this with 0.8.1 or CVS? a similar bug has already been fixed in CVS, so if using 0.8.1 please try CVS. If there is still an issue, please (always) report what media-handler you're using.
|
Thu 04 Oct 2007 07:32:41 PM UTC, original submission:
There seems to be a fairly massive memory leak with:
http://www.dogthebountyhunter.com/index.swf
01719ebd9416fad6da89f3145d952e03
since libmedia introduction. It's always had problems with sound and video playback, (lots of 'bits left=' to start with) but they are quite obvious at the moment.
Playback is so slow on my system (512MB RAM) that I can't do any useful debugging. I'm using ffmpeg.
|