Re: Bug#875927: perl: SIGUNUSED removal in glibc 2.26 changes PL_sig_name / SIG_SIZE
On 2017-10-24 15:34, Dominic Hargreaves wrote:
> On Sun, Oct 22, 2017 at 08:57:59PM +0300, Niko Tyni wrote:
> > On Sat, Sep 16, 2017 at 10:27:26AM +0300, Niko Tyni wrote:
> > > Package: perl
> > > Version: 5.26.0-8
> > > Severity: normal
> > > X-Debbugs-Cc: doko@debian.org, vorlon@debian.org, glibc@packages.debian.org
> > >
> > > As seen in
> > > https://bugs.launchpad.net/ubuntu/+source/libanyevent-perl/+bug/1717367
> > > an upstream change in glibc 2.26, presumably
> > > https://patchwork.sourceware.org/patch/20800/ causes perl to change its
> > > ABI when rebuilt against the new glibc. I'm copying Steve and Matthias
> > > who worked on the issue on the Ubuntu side.
> > >
> > > The problem is that Perl's global array PL_sig_name[] and the SIG_SIZE
> > > constant ($Config{sig_name}, $Config{sig_size} on the perl language side)
> > > change due to the removal of the (long?) obsolete SIGUNUSED constant in
> > > glibc. The Async::Interrupt (libasync-intterupt-perl) XS module compiles
> > > in SIG_SIZE and walks PL_sig_name[] at run time based on that. When the
> > > array changes on the Perl side, Async::Interrupt does not know that and
> > > accesses it out of bounds.
> >
> > > Looking at codesearch.debian.net, this also concerns (reverse dependencies
> > > of) libio-aio-perl, libcoro-perl and libev-perl.
> >
> > Perl upstream is not going to do anything about this. Their recommendation
> > is to hardcode the list of signals when calling Configure. This
> > seems somewhat over the top to me. It might be nicer to temporarily
> > patch Configure (or from 5.26.1-1 onward rather its sources, mainly
> > regen-configure/dist/U/Signal.U) to add SIGUNUSED to the list of signals
> > if it's missing.
> >
> > Alternatively, postprocessing config.sh should work too and is arguably
> > cleaner. Ubuntu is currently postprocessing config.h which I'm not
> > quite as comfortable about as I think it leaves the relevant %Config
> > entries unchanged.
> >
> > Regardless of the approach taken, I note that the stashed Configure
> > results in debian/cross/*/config.sh.static show that SIGUNUSED does not
> > exist on all architectures, so adding it unconditionally would be wrong.
> > These ones don't seem to have it:
> >
> > % for f in debian/cross/*/config.sh.static; do grep -q '^sig_name_init.*UNUSED' $f || echo $f; done
> > debian/cross/alpha/config.sh.static
> > debian/cross/hurd-i386/config.sh.static
> > debian/cross/kfreebsd-amd64/config.sh.static
> > debian/cross/kfreebsd-i386/config.sh.static
> > debian/cross/mips64el/config.sh.static
> > debian/cross/mips/config.sh.static
> > debian/cross/mipsel/config.sh.static
> > debian/cross/sparc64/config.sh.static
> >
> > AFAICS this means we need a hardcoded white- or blacklist of the affected
> > architectures somewhere (and renders the issue even more unactionable
> > upstream.)
> >
> > Upstream also suggests that the modules breaking due to this change
> > are unnecessarily fragile. They all seem to be using the same code,
> > namely an 's_signum()' function in schmorp.h. Quoting Leon Timmermans:
> >
> > > The patch to the modules would be little more than removing code;
> > > they'd just have to use the whichsig (perl 1.0) /whichsig_sv (perl 5.16)
> > > API instead of reimplementing it. Alternatively s_signame could check
> > > for the end of PL_sig_name by checking for a null-pointer instead of
> > > assuming it has SIG_SIZE elements. Unlike the other solutions that will
> > > prevent this kind of situation from happening again.
> >
> > Tony Cook also notes that these s_signum() implementations are buggy in
> > any case, as shown with
> >
> > perl -MAsync::Interrupt -le 'print Async::Interrupt::sig2num("POLL")'
> >
> > which should give 29 instead of 67 on amd64. The code should look the
> > signal number up in PL_sig_num[] instead of assuming the signal number
> > is same as the array index.
> >
> > I'm tempted to just declare that anything relying on these parts of the
> > ABI is buggy and get the known affected modules/packages fixed.
>
> This does seem like the correct approach, given that all the alternatives
> are going against upstream, and are varying levels of hackiness (and remain
> fragile). Am I correct that implementing Tony's suggestion is in itself
> a complete fix for the issue?
>
> I'm adding debian-perl@lists.debian.org for wider visibility of this
> issue, which might include patching these four packages:
> libasync-interrupt-perl, libio-aio-perl, libcoro-perl and libev-perl.
Now that we have glibc 2.26 in experimental, can I ask about the status
of this issue? Do we have to add Breaks: against the affected perl
packages?
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: