Bug#721421: libdevel-bt-perl: FTBFS on armel, hurd-i386, kfreebsd-amd64
On Sat, Sep 27, 2014 at 9:48 AM, Niko Tyni nt...@debian.org 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 nt...@debian.org 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 gre...@debian.org 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 d...@earth.li 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-perlarch=armhfver=0.06-2stamp=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-perlarch=mipsver=0.06-2stamp=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 faw...@gmail.com
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
