Bug#721421: libdevel-bt-perl: FTBFS on armel, hurd-i386, kfreebsd-amd64
On Sat, Sep 27, 2014 at 9:48 AM, Niko Tyni wrote: > tag 721421 patch > thanks > > On Fri, Sep 26, 2014 at 11:12:06PM +0300, Niko Tyni wrote: > > > The problem apparently happens when the timeout in the select loop > > (one second) triggers before execvp() has been called. > > > > I can reproduce a similar "race" on my x86_64 machine by inserting a > > sleep(1) call right before the execvp() call. > > > > I still haven't got to the bottom of it, but it looks like the gdb > > output is lost somewhere with select() timeouting (and returning zero) > > on subsequent calls too even though gdb has happily written to the pipe. > > Further investigation with strace shows that the fd_set passed into > select() becomes empty if execvp() happens after the first select() > call. I was able to reproduce this with gdb replaced by a trivial program > that just prints to stdout (which greatly helped debugging.) > > So I suppose the execvp() call somehow invalidates the fd set? > > I haven't found an explanation for this observed behaviour. The closest > thing I was able to find was this in the select_tut(2) Linux manual page > (on Debian sid if that matters): > >11. Since select() modifies its file descriptor sets, if the >call is being used in a loop, then the sets must be >reinitialized before each call. > > Reinitializing the set in the loop fixes it and seems to be the correct > thing to do anyway. Patch attached, this makes it work for me on both > mips and amd64. > Right, that is definitely a bug. Haven't used select in such a long time that I had looked over that insanity. Leon
Bug#721421: libdevel-bt-perl: FTBFS on armel, hurd-i386, kfreebsd-amd64
On Tue, Sep 23, 2014 at 9:59 PM, Niko Tyni wrote: > I also had a look at the mips one, and there the problem doesn't seem > to be with the backtrace, as running gdb separately works as expected. > However, running perl with -d:bt doesn't seem to do anything. It looks > like the host is just too slow; inserting a 'sleep(1)' just before the > "thread apply all backtrace" command in stack_trace() fixes it for > me. Perhaps the code should just check that the fd is ready for writing? > This should not matter. Pipes are buffered at a kernel level. This is not making sense to me. Leon
Bug#721421: libdevel-bt-perl: FTBFS on armel, hurd-i386, kfreebsd-amd64
On Mon, Sep 22, 2014 at 12:21 AM, gregor herrmann wrote: > Here we go: > > That's armhf on a Debian box in an unstable chroot: > > (sid_armhf-dchroot)gregoa@harris:~$ (echo r; echo bt; echo quit) | gdb > --args perl -e 'unpack "p", pack "L!", 1' | egrep '^#' > #1 0xb6f3f048 in Perl_newSVpv () from > /usr/lib/arm-linux-gnueabihf/libperl.so.5.20 > #2 0x00040002 in ?? () > That looks wrong to me. Does a debugging perl show the same result? Leon
Bug#721421: libdevel-bt-perl: FTBFS on armel, hurd-i386, kfreebsd-amd64
On Sun, Sep 21, 2014 at 7:37 PM, Dominic Hargreaves wrote: > On Thu, Sep 04, 2014 at 02:25:44PM +0200, gregor herrmann wrote: > > On Mon, 01 Sep 2014 19:24:18 +0200, Leon Timmermans wrote: > > > > > The attached patch might fix the issue on Hurd, I can't really say much > > > about the issue on armel or kfreebsd-amd64 without having some > build/test > > > output from them though. > > > > Thanks for the patch, I've applied it now and uploaded the new > > version. > > > > Build logs (with TEST_VERBOSE=1) will show up shortly at > > https://buildd.debian.org/status/package.php?p=libdevel-bt-perl or > > https://buildd.debian.org/status/logs.php?pkg=libdevel-bt-perl > > Hurd is still failing, although that's not the priority at the moment. > It's just armhf and mips we care about, since the bug is only considered > release-critical if it's a regression, and it's never built successfully > on kFreeBSD, Hurd or arm64 (and at least Hurd isn't a release > architecture). > > Here are some log extracts from recent builds: > > armhf: > > > https://buildd.debian.org/status/fetch.php?pkg=libdevel-bt-perl&arch=armhf&ver=0.06-2&stamp=1409851075 > That suggests the issue is missing symbols in the gdb output. What is the output on such a machine of: (echo r; echo bt; echo quit) | gdb --args perl -e 'unpack "p", pack "L!", 1' | egrep '^#' Does that include a perl_run entry? mips: > > > https://buildd.debian.org/status/fetch.php?pkg=libdevel-bt-perl&arch=mips&ver=0.06-2&stamp=1410539249 > That shows the gdb output to be empty. That's either a bug in devel-bt or a bug in gdb. I'd say the former is more likely, but I can't diagnose it at a distance. Leon
Bug#721421: libdevel-bt-perl: FTBFS on armel, hurd-i386, kfreebsd-amd64
The attached patch might fix the issue on Hurd, I can't really say much
about the issue on armel or kfreebsd-amd64 without having some build/test
output from them though.
Leon
From 7243c7acfa7731697dfd75e930906817588c9c2f Mon Sep 17 00:00:00 2001
From: Leon Timmermans
Date: Mon, 1 Sep 2014 11:53:23 +0200
Subject: [PATCH] Raise instead of kill the signal
---
t/basic.t | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/basic.t b/t/basic.t
index 4519941..95fbb90 100644
--- a/t/basic.t
+++ b/t/basic.t
@@ -18,7 +18,7 @@ local $ENV{PERL5LIB} = join $Config::Config{path_sep} => @INC;
for my $signal (@signals) {
next unless __PACKAGE__->can($signal);
my $signum = __PACKAGE__->can($signal)->();
-my @cmd = ($^X, qw(-d:bt -e), "kill $signum, \$\$");
+my @cmd = ($^X, qw(-d:bt -MPOSIX=raise -e), "raise($signum)");
use Capture::Tiny 'capture';
my ($stdout) = capture { system @cmd };
--
1.9.1
Bug#714542: cdbs: Please use "--" long option prefixes for Perl's Module::Build build system
> As we take pride in CDBS being backporting-friendly, it would be nice if you could also test in a Squeeze (i.e. oldstable) environment that the change doesn't break things that far back either. The 'new style' arguments were introduced in Module::Build 0.17, released in March 2003. Backwards compatibility really shouldn't be an issue. Leon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
