Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Thu, Jul 03, 2014 at 07:43:57PM +0300, Niko Tyni wrote:
> On Thu, Jul 03, 2014 at 08:48:37AM +0200, Aurelien Jarno wrote:
> > On Wed, Jul 02, 2014 at 11:29:58PM +0200, Bastian Blank wrote:
>
> > > The problem is a missmatch between the jmp_buf size in perl vs. modules.
> > > Aka the build against glibc 2.19 changed the public ABI of perl.
> >
> > Yes, jmp_buf had to be increased to support new CPUs. This has been done
> > using symbol versioning, but unfortunately it doesn't work when jmp_buf
> > is embedded in a struct like in perl.
> >
> > Upstream consider this as a non-issue and recommend to do the upgrade of
> > all the perl packages in a lockstep.
>
> I see. A bit of googling turns up the related
> https://bugzilla.redhat.com/show_bug.cgi?id=1064271
>
> I note that Carlos O'Donell says there
>
> I expect Ruby is going to fail also since it embeds jmp_buf similarly.
>
> Has anybody noticed similar issues with Ruby?
So far I haven't, but as symbol versioning is used, until we start
mixing versions, the problem won't appear.
> > > How do we want to fix this so upgrades won't barf in the users face?
> >
> > The problem only concerns the jessie to jessie partial upgrades,
> > dist-upgrades should be fine. wheezy to jessie upgrades are also fine,
> > due to the perl 5.14 to 5.18 transition. If we want to fix that for
> > jessie to jessie, one way is to start the perl 5.20 transition.
>
> So all libc6 reverse dependencies have been binNMU'd on s390x for this
> in early June? It looks like some have a confusing changelog entry. I
> checked libterm-readline-gnu-perl and libreadonly-xs-perl, which state
> "Rebuild against perl 5.18".
>
> I could make a sourceful perl upload incrementing perlapi-5.18.2 to
> for instance perlapi-5.18.2d (and removing perlapi-5.18.1) on s390x
> only. This would make ~500 reverse dependencies of perlapi-5.18.*
> uninstallable and require a new binNMU round for them. As libperl5.18
> has a tight dependency on perl-base, I don't think we'd need to
> do anything on the libperl side.
I think this would work fine. From the buildds point of view, the 500
binNMUs should not pose any problem, we have enough build power there.
> I think this would be the right way fix this, but I suppose it would
> affect ongoing transitions and the like. I'm cc'ing the release team
> for advice.
>
> It'll still take at least a few weeks before we can do a clean perl 5.20
> transition. See #753529.
> --
> Niko
>
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: