gnash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash] youtube status on ppc in bzr


From: Markus Gothe
Subject: Re: [Gnash] youtube status on ppc in bzr
Date: Sat, 20 Sep 2008 00:13:58 +0200

As I thought, it's ffmpeg's fault...

//Markus
On 19 Sep 2008, at 19:11, Miklos Vajna wrote:

On Fri, Sep 19, 2008 at 06:44:50PM +0200, strk <address@hidden> wrote:
Can you also try valgrind please ?

----
$ valgrind gtk-gnash http://klaus.geekserver.net/flash/video.swf
==27937== Memcheck, a memory error detector.
==27937== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==27937== Using LibVEX rev 1854, a library for dynamic binary translation.
==27937== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==27937== Using valgrind-3.3.1, a dynamic binary instrumentation framework. ==27937== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==27937== For more details, rerun with: -v
==27937==
==27937== Conditional jump or move depends on uninitialised value(s)
==27937==    at 0x4002538: _dl_start (in /lib/ld-2.8.so)
==27937==    by 0x4015B04: _start (in /lib/ld-2.8.so)
==27937==
==27937== Conditional jump or move depends on uninitialised value(s)
==27937==    at 0x4002570: _dl_start (in /lib/ld-2.8.so)
==27937==    by 0x4015B04: _start (in /lib/ld-2.8.so)
RcInitFile: parsing /etc/gnashrc
RcInitFile: couldn't open file: /home/vmiklos/.gnashrc
dis_cache_manage(ppc)(opc1|b21to25|b0)
disInstr(ppc): unhandled instruction: 0x7C2907EC
                primary 31(0x1F), secondary 2028(0x7EC)
==27937== valgrind: Unrecognised instruction at address 0xE206ACC.
==27937== Your program just tried to execute an instruction that Valgrind
==27937== did not recognise.  There are two possible reasons for this.
==27937== 1. Your program has a bug and erroneously jumped to a non- code
==27937==    location.  If you are running Memcheck and you just saw a
==27937== warning about a bad jump, it's probably your program's fault. ==27937== 2. The instruction is legitimate but Valgrind doesn't handle it, ==27937== i.e. it's Valgrind's fault. If you think this is the case or ==27937== you are not sure, please let us know and we'll try to fix it. ==27937== Either way, Valgrind will now raise a SIGILL signal which will
==27937== probably kill your program.
==27937==
==27937== Process terminating with default action of signal 4 (SIGILL)
==27937==  Illegal opcode at address 0xE206ACC
==27937== at 0xE206ACC: check_dcbzl_effect (in /usr/lib/ libavcodec.so.51.56.0) ==27937== by 0xE206B60: dsputil_init_ppc (in /usr/lib/ libavcodec.so.51.56.0) ==27937== by 0xDF596C8: dsputil_init (in /usr/lib/libavcodec.so. 51.56.0) ==27937== by 0xDFE0FDC: MPV_common_init (in /usr/lib/ libavcodec.so.51.56.0) ==27937== by 0xE0A1D38: ff_h263_decode_init (in /usr/lib/ libavcodec.so.51.56.0) ==27937== by 0xDFAB384: avcodec_open (in /usr/lib/libavcodec.so. 51.56.0) ==27937== by 0xFEECF98: gnash::media::VideoDecoderFfmpeg::init(CodecID, int, int, unsigned char*, int) (VideoDecoderFfmpeg.cpp:163) ==27937== by 0xFEED768: gnash ::media ::VideoDecoderFfmpeg::VideoDecoderFfmpeg(gnash::media::VideoInfo&) (VideoDecoderFfmpeg.cpp:137) ==27937== by 0xFEE3AC4: gnash ::media ::MediaHandlerFfmpeg::createVideoDecoder(gnash::media::VideoInfo&) (MediaHandlerFfmpeg.cpp:62) ==27937== by 0xFB3517C: gnash::NetStreamFfmpeg::initVideoDecoder(gnash::media::MediaParser&) (NetStreamFfmpeg.cpp:215) ==27937== by 0xFB35CF0: gnash::NetStreamFfmpeg::startPlayback() (NetStreamFfmpeg.cpp:270) ==27937== by 0xFB36A18: gnash::NetStreamFfmpeg::play(std::string const&) (NetStreamFfmpeg.cpp:189)
==27937==
==27937== ERROR SUMMARY: 4 errors from 2 contexts (suppressed: 3 from 1) ==27937== malloc/free: in use at exit: 3,218,350 bytes in 19,079 blocks. ==27937== malloc/free: 54,290 allocs, 35,211 frees, 6,108,681 bytes allocated.
==27937== For counts of detected errors, rerun with: -v
==27937== searching for pointers to 19,079 not-freed blocks.
==27937== checked 15,369,360 bytes.
==27937==
==27937== LEAK SUMMARY:
==27937==    definitely lost: 42,137 bytes in 1,105 blocks.
==27937==      possibly lost: 192,268 bytes in 1,513 blocks.
==27937==    still reachable: 2,983,945 bytes in 16,461 blocks.
==27937==         suppressed: 0 bytes in 0 blocks.
==27937== Rerun with --leak-check=full to see details of leaked memory.
Killed
----

(would be worth filing a bug report for this too, it's easier to track)

Here it is:

https://savannah.gnu.org/bugs/index.php?24311
_______________________________________________
Gnash mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnash

Attachment: PGP.sig
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]