[Top][All Lists]

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

Re: [Gnash] youtube status on ppc in bzr

From: Bastiaan Jacques
Subject: Re: [Gnash] youtube status on ppc in bzr
Date: Fri, 19 Sep 2008 18:38:14 -0700 (PDT)
User-agent: Alpine 1.00 (DEB 882 2007-12-20)

No, the missing instruction is a Valgrind bug.


On Sat, 20 Sep 2008, Markus Gothe wrote:

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

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
==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== Conditional jump or move depends on uninitialised value(s)
==27937==    at 0x4002538: _dl_start (in /lib/
==27937==    by 0x4015B04: _start (in /lib/
==27937== Conditional jump or move depends on uninitialised value(s)
==27937==    at 0x4002570: _dl_start (in /lib/
==27937==    by 0x4015B04: _start (in /lib/
RcInitFile: parsing /etc/gnashrc
RcInitFile: couldn't open file: /home/vmiklos/.gnashrc
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== Process terminating with default action of signal 4 (SIGILL)
==27937==  Illegal opcode at address 0xE206ACC
==27937== at 0xE206ACC: check_dcbzl_effect (in /usr/lib/ ==27937== by 0xE206B60: dsputil_init_ppc (in /usr/lib/
==27937==    by 0xDF596C8: dsputil_init (in /usr/lib/
==27937== by 0xDFE0FDC: MPV_common_init (in /usr/lib/ ==27937== by 0xE0A1D38: ff_h263_decode_init (in /usr/lib/
==27937==    by 0xDFAB384: avcodec_open (in /usr/lib/
==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== 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== 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.

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

Here it is:
Gnash mailing list

reply via email to

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