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

Re: Bug#703793: mplayer crash seriously with newer libogg



On Sat, Mar 23, 2013 at 04:20:25PM -0430, PICCORO McKAY Lenz wrote:
> i'll explain..
> 
> the kernel are bad.. my kernel are x86 only 3.2.0 from wheeze
> 
> so i upgraded mplayer rebuild agains new libogg and goes bad.. then i
> upgrade mplayer sources and rebuild agains libogg (and several others new)
> and work fine

I don't believe this is a bug in the libogg packages of any existing
Debian suite.  Let me count the ways ...

 - __stack_chk_fail is not a symbol from libogg, nor was it removed.
   It is a symbol from glibc, imported when -fstack-protector is used.

 - __stack_chk_fail_local is not a symbol from amd64 arches.
   AIUI, this is an optimisation wrapper for __stack_chk_fail used on
   IA32 only, and doesn't appear to be used by the Debian i386 libogg
   packages either for that matter.

 - If you don't have this symbol, you've either forced libc6 not to be
   upgraded according to the declared deps, the declared deps are wrong
   due to a bug in the libc6 package (which is unlikely because that
   symbol is versioned GLIBC_2.4), or you've done something odd and wrong
   locally that we can't predict and you haven't told us anything about.
   Including but not limited to a broken local build of mplayer.

 - In fact it almost certainly can't be glibc either, because only the
   real symbol should be included there, and the wrapper is likely in
   your mplayer executable, or some libogg build that didn't come from
   the distro and/or wasn't built with the distro compiler.

 - If adding -fstack-protector for wheezy introduced a bug like this,
   we'd have surely seen lots of other things explode already.

I have no definite idea offhand what you actually have done, but I'm
pretty certain that it is not just a partial update from one Debian
release to another.

> i send the report with and old due i very busy and the report script are
> very tedious

We very busy too, and poor reports, with incomplete and/or incorrect
information, from frankensystems that aren't running Debian packages
that the distro has shipped are pretty tedious too.

Please don't do that.

  Ron


> On Sat, Mar 23, 2013 at 4:11 PM, Adam D. Barratt
> <adam@adam-barratt.org.uk>wrote:
> 
> > On Sat, 2013-03-23 at 21:23 +0100, Dominik George wrote:
> > > Hi,
> >
> > You need to mail the submitter if you expect replies / information from
> > them.
> >
> > > this could either be fixed with a Breaks against older mplayer versions,
> > > but I recognize this is not preferred if the bug only affects incomplete
> > > upgrades to wheezy.
> > >
> > > If this were release critical, teh release team could set it
> > > wheezy-ignore, but I am lowering the severity to important because you
> > > seem to be a special case. First, you state that this only happens for
> > > *incomplete* upgrades and I assume this does not meet the criteria "most
> > > users".
> >
> > Partial upgrades from stable to stable+1 are required to work (CC to
> > -release as I'm not entirely sure if this is explicitly documented,
> > despite having been the case for as long as I can remember). The reason
> > I'm not re-upgrading it straight away is:
> >
> > > Second, your system strikes me odd:
> > >
> > > > Debian Release: testing/unstable
> > > >   APT prefers unstable
> > > >   APT policy: (900, 'unstable')
> > > > Architecture: amd64 (x86_64)
> > > > Shell:  /bin/sh linked to /bin/bash
> > > > Kernel: Linux 2.6.15-k8-3
> > >
> > > This system cannot even be squeeze, as squeeze has Linux 2.6.18.
> >
> > No, squeeze has 2.6.26; lenny had 2.6.18. There's no requirement to use
> > Debian's kernel packages though. However, squeeze's libc6 won't install
> > on anything less than 2.6.18, so there does seem to be something
> > slightly strange.
> >
> > Regards,
> >
> > Adam
> >
> >
> 
> 
> -- 
> Lenz McKAY Gerardo (PICCORO)
> http://qglochekone.blogspot.com


Reply to: