Package: gdb
Version: 7.7.1+dfsg-3
It seems possible that this is a problem elsewhere, but it's so similar
to #603201 that I'm assuming it's gdb at fault.
The libdevel-bt-perl package is failing its test suite on armhf (#721421)
because it's expecting a backtrace but seeing stack corruption. Other
architectures show a clean backtrace with perl_run() near the bottom of
the call stack.
A test command triggering a SIGSEGV, as suggested by Leon Timmermans
in #721421:
(echo r; echo bt; echo quit) | gdb --args perl -e 'unpack "p", pack "L!", 1'
which gives on harris.d.o in a sid schroot:
Program received signal SIGSEGV, Segmentation fault.
0xb6d6a1ee in strlen () from /lib/arm-linux-gnueabihf/libc.so.6
(gdb) #0 0xb6d6a1ee in strlen () from /lib/arm-linux-gnueabihf/libc.so.6
#1 0xb6f3f048 in Perl_newSVpv (my_perl=0x22008, s=0x1 <error: Cannot access
memory at address 0x1>, len=0)
at sv.c:8965
#2 0x00040002 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Somewhat surprisingly, I'm seeing the same issue on armel (abel.d.o) too
when perl-debug isn't installed. Installing it fixes the backtrace there,
but not on armhf (harris.d.o).
(The perl-debug package contains detached debugging symbols for
/usr/bin/perl and libperl.so.5.20, and a separate debugging-enabled
binary /usr/bin/debugperl. It should not be needed for a clean backtrace
AFAICS, and isn't on amd64 at least.)
--
Niko Tyni [email protected]
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
