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: Miklos Vajna
Subject: Re: [Gnash] youtube status on ppc in bzr
Date: Fri, 19 Sep 2008 19:11:44 +0200
User-agent: Mutt/1.5.17 (2007-11-01)

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

Attachment: pgpkHQ46MEcex.pgp
Description: PGP signature


reply via email to

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