Bug#721421: libdevel-bt-perl: FTBFS on armel, hurd-i386, kfreebsd-amd64

[Niko Tyni]

On Tue, Sep 23, 2014 at 05:50:00PM +0200, gregor herrmann wrote:
> On Tue, 23 Sep 2014 17:31:52 +0200, Leon Timmermans wrote:
> 
> > > That's armhf on a Debian box in an unstable chroot:
> > >
> > > (sid_armhf-dchroot)gregoa at 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?
> 
> Let's see: Same machine, same chroot, this time with perl-debug
> installed:
> 
> (sid_armhf-dchroot)gregoa at harris:~$ (echo r; echo bt; echo quit) | gdb --args perl -e 'unpack "p", pack "L!", 1' | egrep '^#'
> #1  0xb6f3f048 in Perl_newSVpv (my_perl=0x22008, s=0x1 <error: Cannot access memory at address 0x1>, len=0)
> #2  0x00040002 in ?? ()

I've reproduced this armhf issue and filed #762620 against gdb about it.
I think removing the armhf binaries of libdevel-bt-perl is a reasonable
workaround for this, but let's give the gdb maintainer a bit of time
to investigate first. (Removing the binaries would mean that we don't
provide an armhf version of the package unless it starts working again.)

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?
-- 
Niko Tyni   ntyni at debian.org