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@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@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 nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
