severity 602668 important clone 602668 -1 retitle -1 gdb: 7.2 falsely (?) shows stack corruption on armel reassign -1 gdb 7.2-1 block 602668 with -1 thanks
On Sat, Nov 06, 2010 at 11:15:01PM +0000, Hector Oron wrote: > Package: libdevel-bt-perl > Version: 0.05-1 > Severity: serious It's never built on armel yet, so downgrading. > t/basic.t (Wstat: 1280 Tests: 5 Failed: 5) > Failed tests: 1-5 This is because gdb thinks the stack gets corrupted somewhere between perl_run() and Perl_runops_standard(): abel% gdb perl GNU gdb (GDB) 7.2-debian [...] Reading symbols from /usr/bin/perl...(no debugging symbols found)...done. (gdb) br perl_run Breakpoint 1 at 0x898c (gdb) br Perl_runops_standard Function "Perl_runops_standard" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 2 (Perl_runops_standard) pending. (gdb) run -e 1 Starting program: /usr/bin/perl -e 1 [Thread debugging using libthread_db enabled] Breakpoint 1, 0x400740c4 in perl_run () from /usr/lib/libperl.so.5.10 (gdb) bt #0 0x400740c4 in perl_run () from /usr/lib/libperl.so.5.10 #1 0x00008b9c in main () (gdb) c Continuing. Breakpoint 2, 0x400cead4 in Perl_runops_standard () from /usr/lib/libperl.so.5.10 (gdb) bt #0 0x400cead4 in Perl_runops_standard () from /usr/lib/libperl.so.5.10 #1 0x400743f4 in perl_run () from /usr/lib/libperl.so.5.10 #2 0x00011008 in ?? () Cannot access memory at address 0x0 #3 0x00011008 in ?? () Cannot access memory at address 0x0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) This seems to be a regression in gdb itself: 7.2-1 from sid shows the above stack corruption, 7.0.1-2 from squeeze doesn't with the same perl binary. (I tested this on abel by copying /usr/bin/gdb from the sid chroot to my home directory and running it in the squeeze one.) Cloning, reassigning and blocking. -- 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