Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18

[Aurelien Jarno]

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 at aurel32.net                 http://www.aurel32.net