Bug#753542: perl-base - Segfaults in libperl.so.5.18
On 03/07/14 19:50, Aurelien Jarno wrote:
> 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.
I have come up with:
https://release.debian.org/transitions/html/perlapi-5.18.2d-s390x.html
Although I would prefer to wait a bit and do 5.20 directly, I'm not affected by
this breakage as I don't have any s390x machines. So if you think this is
important enough, we could go ahead and do it now. The only conflict I see right
now is gdal with the poppler transition, but that one should be finished in two
or three days if everything goes well.
Emilio
>> It'll still take at least a few weeks before we can do a clean perl 5.20
>> transition. See #753529.
>> --
>> Niko
>>
>
Reply to: