Bug#1022031: perl: FTBFS on sparc64: test failures in t/re
Source: perl Version: 5.36.0-4 Tags: ftbfs X-Debbugs-Cc: debian-sparc@lists.debian.org The perl package currently fails to build on sparc64 due to two failing tests: t/re/reg_fold ok t/re/reg_mesg FAILED--no leader found t/re/reg_namedcapture ok t/re/reg_nc_tie .. ok t/re/reg_nocapture ... ok t/re/reg_pmod ok t/re/reg_posixcc . ok t/re/regex_sets .. FAILED--no leader found [...] Failed 2 tests out of 2622, 99.92% okay. re/reg_mesg.t re/regex_sets.t The 5.36 transition is already ongoing (see https://lists.debian.org/debian-devel-announce/2022/10/msg5.html ) so you might want to upload a nocheck build or something to catch the train. Apologies for the late notice, -- Niko Tyni nt...@debian.org
Re: Bug#869231: perl: FTBFS on sparc64: re/fold_grind.t timeout
On Fri, Jul 21, 2017 at 02:30:07PM -0400, Aaron M. Ucko wrote: > Source: perl > Version: 5.26.0-4 > Severity: important > Justification: fails to build from source (but built successfully in the past) > > Recent builds of perl on sparc64 (admittedly not a release > architecture) have been failing: > > t/re/fold_grind # Test > process timed out - terminating > FAILED--no leader found > > Could you please take a look? Thanks. Copying the debian-sparc list in the hope somebody there will debug this. 5.26.0-4 built on the 'landau' buildd fwiw so it seems either nondeterministic or hardware related. It looks like there's a test timeout of 300 seconds, maybe it's just too slow? That would be a bit odd given it doesn't happen on the "small" architectures (arm*, mips*)... See also #869124 for another apparently timing related issue on sparc64. -- Niko Tyni nt...@debian.org
Bug#869124: perl: waithires.t problems on sparc64
Package: perl Version: 5.24.1-7 Severity: normal Control: found -1 5.26.0-3 X-Debbugs-Cc: debian-sparc@lists.debian.org The perl package has mostly failed to build on sparc64 recently due to waithires.t failures. There's a few successful builds too (including 5.26.0-1) so it's probably nondeterministic. However, it seems limited to sparc64 afaics. I'm copying the debian-sparc list. I don't intend to work on this myself, but patches are welcome of course if it turns out to be a bug in perl and not the sparc64 platform. -- Niko Tyni nt...@debian.org
Re: Anybody have a spare sparc machine? (was: Re: Bug#543573: FTBFS: libdevel-declare-perl_0.005011-1 on sparc (dist=unstable))
On Tue, Sep 01, 2009 at 07:52:17PM -0700, Ryan Niebur wrote: > the upstream author of libdevel-declare-perl thinks that this could be > the same as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505415 > so if somebody with a sparc machine could just rebuild > libdevel-declare-perl against the perl in experimental and confirm > that it builds, that would be sufficient. I can confirm this. Core was generated by `debugperl -Iblib/lib -Iblib/arch t/combi.t'. Program terminated with signal 10, Bus error. #0 0xf7c7dadc in S_scan_str (my_perl=, offset=13) at stolen_chunk_of_toke.c:716 716 SvGROW(sv, SvCUR(sv) + (PL_bufend - s) + 1); It works with Perl 5.10.1. A workaround for 5.10.0 is to lower the optimization to -O1. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#501825: libjson-xs-perl_2.23-1(sparc/unstable): FTBFS on sparc, fails in tests
On Fri, Oct 10, 2008 at 09:00:21PM +0200, Martin Zobel-Helas wrote:
> Package: libjson-xs-perl
> Version: 2.23-1
> Severity: serious
>
> There was an error while trying to autobuild your package:
>
> > Automatic build of libjson-xs-perl_2.23-1 on schroeder by sbuild/sparc 99.99
> > Build started at 20081010-1421
> > t/19_incr...dubious
> > Test returned status 0 (wstat 10, 0xa)
> > DIED. FAILED test 697
> > Failed 1/697 tests, 99.86% okay
This is reproducible on sperger.d.o.
It's an alignment problem that only shows up with an optimization level
of at least -O2.
Program received signal SIGBUS, Bus error.
0xf7ec1134 in decode_json (string=0x192280, json=0x39f18,
offset_return=0xff85b96c) at XS.xs:1443
1443 SvGROW (string, SvCUR (string) + 1); // should basically be a NOP
(gdb) bt
#0 0xf7ec1134 in decode_json (string=0x192280, json=0x39f18,
offset_return=0xff85b96c) at XS.xs:1443
#1 0xf7ec2444 in XS_JSON__XS_incr_parse (my_perl=0x22008, cv=0x126d58) at
XS.xs:1828
#2 0xf7dfab48 in Perl_pp_entersub () from /usr/lib/libperl.so.5.10
#3 0xf7df8f9c in Perl_runops_standard () from /usr/lib/libperl.so.5.10
#4 0xf7df4298 in perl_run () from /usr/lib/libperl.so.5.10
#5 0x00010b88 in main ()
The instruction that causes the bus error is a double-word load (ldd):
0xf7ec1130 : ld [ %l1 ], %g1
0xf7ec1134 : ldd [ %g1 + 8 ], %g2
0xf7ec1138 : inc %g2
0xf7ec113c : cmp %g3, %g2
The preprocessor output for the above SvGROW() macro invocation is
(((XPV*) (string)->sv_any)->xpv_len < (((XPV*) (string)->sv_any)->xpv_cur +
1) ? Perl_sv_grow(((PerlInterpreter
*)pthread_getspecific((*Perl_Gthr_key_ptr(((void *)0), string,((XPV*)
(string)->sv_any)->xpv_cur + 1) : ((string)->sv_u.svu_pv));
and the above assembly is the compiled form of the first comparison
at -O2. The compiler is using a double-word instruction to load both
xpv_cur and xpv_len in one go.
Now, this apparently requires that ((XPV*) (string)->sv_any)->xpv_cur
is aligned on a double-word (64-bit) boundary, which fails here:
$1 = {sv_any = 0x25714, sv_refcnt = 1, sv_flags = 536888326, sv_u = {svu_iv =
1662248, svu_uv = 1662248,
svu_rv = 0x195d28, svu_pv = 0x195d28 "[42]", svu_array = 0x195d28, svu_hash
= 0x195d28,
svu_gp = 0x195d28}}
(gdb) print &((XPV*) (string)->sv_any)->xpv_cur
$2 = (STRLEN *) 0x2571c
(gdb) print &((XPV*) (string)->sv_any)->xpv_len
$3 = (STRLEN *) 0x25720
(Delving somewhat further, I see the 64-bit alignment of string->sv_any
is lost in libperl's sv_chop(), invoked from incr_skip() at XS.xs:1855
or so.)
This suggests to me that gcc is being too aggressive on optimizing here.
I don't see how it can consider the double word instruction safe.
Cc'ing the sparc porters list in the hope that somebody gets interested
in this.
I suppose a workaround is to use -O1 on sparc.
--
Niko Tyni [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#477694: FTBFS: ext/threads/t/stress_re.t fails sporadically on sparc
On Fri, Apr 25, 2008 at 10:29:03PM +0200, Florian Weimer wrote: > * Niko Tyni: > > > It doesn't show up on my own sparc uniprocessor host, which has the > > Etch kernel, so it's either specific to new kernels or SMP hosts. As it > > works on sperger in the sid chroot, it would seem that newer versions > > of glibc work better. > > Could you build the latest security update (that will be -7etch3, > available in a coupleo f hours) in an etch chroot and upload it? > > It's not a regression in the security update and it's not been reported > before, so this appears to be a rather benign bug. Unfortunately my sparc box is physically in a quite unsecure place, so I don't think I can sign the result. Maybe somebody else on debian-sparc could help? Another alternative is to build it with DEB_BUILD_OPTIONS=x-perl-notest, I guess. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#477694: FTBFS: ext/threads/t/stress_re.t fails sporadically on sparc
On Thu, Apr 24, 2008 at 05:49:16PM +0200, Florian Weimer wrote: > Package: perl > Version: 5.8.8-7etch1 > Severity: serious > > To my knowledge, this bug only occurs on sparc in an etch chroot, > possibly only when running newer kernels. I cannot reproduce it with > the sid chroot on sperger. > The point at which the Perl process is terminated (IOW, number of lines > printed) varies from invocation to invocation. > > spontini, the sparc security build daemon, is similarly affected: > building perl sporadically fails as well, and it remains to be seen if > we can get it it to pass. Yeah, I can reproduce it on sperger/etch. It doesn't need the full Perl build tree, just running the system perl on ext/threads/t/stress_re.t (attached for convenience) shows the problem. It doesn't show up on my own sparc uniprocessor host, which has the Etch kernel, so it's either specific to new kernels or SMP hosts. As it works on sperger in the sid chroot, it would seem that newer versions of glibc work better. Looking at the glibc changelog, the threads implementation changed in 2.4.1 from LinuxThreads to NPTL, which sounds related. I don't really claim to know anything about their differences, though. CC'ing the debian-sparc list. help would be welcome. Bisecting with other kernel versions (sperger has 2.6.22.18sperger) might tell us something. Hm, one more data point: this was very easy to reproduce last night when sperger was empty, but now that there's some load from other people, the test completes almost all of the time. That would seem quite natural for a threading bug on an SMP host. Cheers, -- Niko Tyni [EMAIL PROTECTED] stress_re.t Description: Troff document
Re: Bug#477741: libauthen-dechpwd-perl_2.002-3(sparc/unstable): FTBFS, test failed
On Thu, Apr 24, 2008 at 05:27:39PM -0700, Ivan Kohler wrote:
> severity 477741 important
> tags 477741 help
> thanks
>
> FTBFS appears to be specific to sparc architecture.
>
> I tried to log onto sperger.debian.org and at least look further into
> the problem, but neither debhelper nor libmodule-build-perl are
> installed. I'll email debian-admin@ and ask.
I guess you forgot to switch to the sid chroot...
> > > t/purdy...dubious
> > > Test returned status 0 (wstat 10, 0xa)
> > > DIED. FAILED tests 2-101
This is an aligment problem triggering a bus error.
(gdb) run -Iblib/lib -Iblib/arch t/purdy.t
Starting program: /usr/bin/perl -Iblib/lib -Iblib/arch t/purdy.t
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
(no debugging symbols found)
(no debugging symbols found)
1..101
[New Thread 0xf7bd66b0 (LWP 19114)]
ok 1 - use Authen::DecHpwd;
Program received signal SIGBUS, Bus error.
[Switching to Thread 0xf7bd66b0 (LWP 19114)]
0xf7879ac0 in PQMUL_R2 (U=0xffa1b6e4, Y=0xffa1b6e4, result=0xffa1b6ec) at
lib/Authen/DecHpwd.xs:595
595 PQADD_R0(&part1, &stack, result);/* Whole thing */
(gdb) bt
#0 0xf7879ac0 in PQMUL_R2 (U=0xffa1b6e4, Y=0xffa1b6e4, result=0xffa1b6ec) at
lib/Authen/DecHpwd.xs:595
#1 0xf787973c in PQEXP_R3 (U=0xffa1b910, n=224, result=0xffa1b7f8) at
lib/Authen/DecHpwd.xs:544
#2 0xf787903c in Purdy (U=0xffa1b910) at lib/Authen/DecHpwd.xs:483
#3 0xf7878d58 in VMS_lgihpwd (output=0xffa1b910, password=0x14f698
"eviscerate", password_len=10,
encrypt=1, salt=50917, username=0xffa1b870 "unclasping ", username_len=12)
at lib/Authen/DecHpwd.xs:437
#4 0xf787a484 in XS_Authen__DecHpwd_lgi_hpwd (my_perl=0x24008, cv=0x127984) at
lib/Authen/DecHpwd.xs:646
#5 0xf7f02b04 in Perl_pp_entersub () from /usr/lib/libperl.so.5.8
#6 0xf7f011ac in Perl_runops_standard () from /usr/lib/libperl.so.5.8
#7 0xf7ea24b4 in perl_run () from /usr/lib/libperl.so.5.8
#8 0x0001143c in main ()
It's using the ul64 version of PQADD_R0 from DecHpwd.xs:326,
assigning to *result which is unaligned.
#define PQADD_R0(U, Y, result) \
{ \
*(ul64*)(result) = *(ul64*)(U) + *(ul64*)(Y); \
if (~*(ul64*)(U) < *(ul64*)(Y)) do { \
*(ul64*)(result) += (ul64)A; \
} while (*(ul64*)(result) < (ul64)A); \
}
Patching it to use the !ul64 version instead makes the tests pass, FWIW.
(BTW, debian/rules needs something like
$(PERL) Build.PL installdirs=vendor config=optimize="$(CFLAGS)"
to honour DEB_BUILD_OPTIONS=noopt.)
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
