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: d...@debian.org, vor...@debian.org, > > > gl...@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-p...@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 aurel...@aurel32.net http://www.aurel32.net
