Bug #16335 for Coro: Test failure with debugging perl

Tue Dec 06 23:32:02 2005 SAMV [...] cpan.org - Ticket created

Subject:

Test failure with debugging perl

Debian et al ship with a "debugperl", which is an alternate version of perl built with debugging symbols. Running the Coro tests with this version of Perl fail on my system: PERL_DL_NONLAZY=1 /usr/bin/debugperl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/00_basic.......ok t/01_process.....ok t/02_channel.....ok t/03_cont........ok t/04_rwlock......ok t/05_specific....ok t/06_prio........dubious Test returned status 0 (wstat 11, 0xb) DIED. FAILED tests 6-10 Failed 5/10 tests, 50.00% okay t/07_eval........Bad realloc() ignored at t/07_eval.t line 7. t/07_eval........dubious Test returned status 0 (wstat 11, 0xb) DIED. FAILED tests 2-5 Failed 4/5 tests, 20.00% okay t/08_join........dubious Test returned status 0 (wstat 11, 0xb) DIED. FAILED tests 6-10 Failed 5/10 tests, 50.00% okay t/09_timer.......ok Failed Test Stat Wstat Total Fail Failed List of Failed ------------------------------------------------------------------------------- t/06_prio.t 0 11 10 10 100.00% 6-10 t/07_eval.t 0 11 5 8 160.00% 2-5 t/08_join.t 0 11 10 10 100.00% 6-10 Failed 3/10 test scripts, 70.00% okay. 14/102 subtests failed, 86.27% okay. make: *** [test_dynamic] Error 255 This makes debugging other problems with "gdb" problematic... Verbose versions of test output: wilber:~/.cpan/build/Coro-1.5$ PERL_DL_NONLAZY=1 perl -Mlib=blib/{arch,lib} t/06_prio.t 1..10 ok 1 ok 2 ok 3 ok 4 ok 5 ok 6 ok 7 ok 8 ok 9 ok 10 wilber:~/.cpan/build/Coro-1.5$ PERL_DL_NONLAZY=1 debugperl -Mlib=blib/{arch,lib} t/06_prio.t 1..10 ok 1 ok 2 ok 3 ok 4 ok 5 Segmentation fault wilber:~/.cpan/build/Coro-1.5$ PERL_DL_NONLAZY=1 debugperl -Mlib=blib/{arch,lib} t/07_eval.t 1..5 ok 1 Bad realloc() ignored at t/07_eval.t line 7. Segmentation fault wilber:~/.cpan/build/Coro-1.5$ PERL_DL_NONLAZY=1 debugperl -Mlib=blib/{arch,lib} t/08_join.t 1..10 ok 1 ok 2 ok 3 ok 4 ok 5 Segmentation fault wilber:~/.cpan/build/Coro-1.5$

Tue Dec 06 23:36:50 2005 SAMV [...] cpan.org - Correspondence added

From:

SAMV [...] cpan.org

backtraces wilber:~/.cpan/build/Coro-1.5$ PERL_DL_NONLAZY=1 gdb debugperl GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -Mlib=blib/arch -Mlib=blib/lib t/06_prio.t Starting program: /usr/bin/debugperl -Mlib=blib/arch -Mlib=blib/lib t/06_prio.t [Thread debugging using libthread_db enabled] [New Thread 46912504633040 (LWP 26699)] 1..10 ok 1 ok 2 ok 3 ok 4 ok 5 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912504633040 (LWP 26699)] 0x0000000000511d81 in Perl_push_scope (my_perl=0x6d6010) at scope.c:136 136 scope.c: No such file or directory. in scope.c (gdb) bt #0 0x0000000000511d81 in Perl_push_scope (my_perl=0x6d6010) at scope.c:136 #1 0x00000000004cdd01 in Perl_pp_entersub (my_perl=0x6d6010) at pp_hot.c:2658 #2 0x000000000042585d in S_call_body (my_perl=0x6d6010, myop=0x2aaaab58ad70, is_eval=0) at perl.c:2361 #3 0x00000000004252c1 in Perl_call_sv (my_perl=0x6d6010, sv=0x817f48, flags=150) at perl.c:2282 #4 0x00000000004ddc7e in Perl_sv_clear (my_perl=0x6d6010, sv=0x864588) at sv.c:5110 #5 0x00000000004de7d3 in Perl_sv_free (my_perl=0x6d6010, sv=0x864588) at sv.c:5356 #6 0x00000000005120a4 in Perl_free_tmps (my_perl=0x6d6010) at scope.c:196 #7 0x00000000004c05c4 in Perl_pp_unstack (my_perl=0x6d6010) at pp_hot.c:141 #8 0x00000000004a1259 in Perl_runops_debug (my_perl=0x6d6010) at dump.c:1452 #9 0x00002aaaab446ffc in continue_coro () from blib/arch/auto/Coro/State/State.so #10 0x00002aaaab445b07 in coro_init () from blib/arch/auto/Coro/State/State.so #11 0x0000000000000000 in ?? () Cannot access memory at address 0x2aaaab58b000 (gdb) (gdb) run -Mlib=blib/arch -Mlib=blib/lib t/07_eval.t Starting program: /usr/bin/debugperl -Mlib=blib/arch -Mlib=blib/lib t/07_eval.t [Thread debugging using libthread_db enabled] [New Thread 46912504633040 (LWP 26750)] 1..5 ok 1 Bad realloc() ignored at t/07_eval.t line 7. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912504633040 (LWP 26750)] 0x00000000005135a7 in Perl_save_sptr (my_perl=0x6d6010, sptr=0x6d6b60) at scope.c:477 477 scope.c: No such file or directory. in scope.c (gdb) bt #0 0x00000000005135a7 in Perl_save_sptr (my_perl=0x6d6010, sptr=0x6d6b60) at scope.c:477 #1 0x0000000000437f96 in Perl_lex_start (my_perl=0x6d6010, line=0x7488a8) at toke.c:432 #2 0x0000000000529507 in Perl_pp_entereval (my_perl=0x6d6010) at pp_ctl.c:3388 #3 0x00000000004a1259 in Perl_runops_debug (my_perl=0x6d6010) at dump.c:1452 #4 0x0000000000524e14 in S_docatch_body (my_perl=0x6d6010) at pp_ctl.c:2606 #5 0x0000000000524f78 in S_docatch (my_perl=0x6d6010, o=0x7e1908) at pp_ctl.c:2642 #6 0x000000000052a83e in Perl_pp_entertry (my_perl=0x6d6010) at pp_ctl.c:3545 #7 0x00000000004a1259 in Perl_runops_debug (my_perl=0x6d6010) at dump.c:1452 #8 0x0000000000425886 in S_call_body (my_perl=0x6d6010, myop=0x2aaaab56aea0, is_eval=0) at perl.c:2364 #9 0x00000000004252c1 in Perl_call_sv (my_perl=0x6d6010, sv=0x818428, flags=140) at perl.c:2282 #10 0x00002aaaab446ceb in setup_coro () from blib/arch/auto/Coro/State/State.so #11 0x00002aaaab445b07 in coro_init () from blib/arch/auto/Coro/State/State.so #12 0x0000000000000000 in ?? () Cannot access memory at address 0x2aaaab56b000 (gdb) (gdb) run -Mlib=blib/arch -Mlib=blib/lib t/08_join.t The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/bin/debugperl -Mlib=blib/arch -Mlib=blib/lib t/08_join.t [Thread debugging using libthread_db enabled] [New Thread 46912504633040 (LWP 26759)] 1..10 ok 1 ok 2 ok 3 ok 4 ok 5 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912504633040 (LWP 26759)] 0x0000000000511d81 in Perl_push_scope (my_perl=0x6d6010) at scope.c:136 136 in scope.c (gdb) bt #0 0x0000000000511d81 in Perl_push_scope (my_perl=0x6d6010) at scope.c:136 #1 0x00000000004cdd01 in Perl_pp_entersub (my_perl=0x6d6010) at pp_hot.c:2658 #2 0x000000000042585d in S_call_body (my_perl=0x6d6010, myop=0x2aaaab58ad70, is_eval=0) at perl.c:2361 #3 0x00000000004252c1 in Perl_call_sv (my_perl=0x6d6010, sv=0x817f08, flags=150) at perl.c:2282 #4 0x00000000004ddc7e in Perl_sv_clear (my_perl=0x6d6010, sv=0x864358) at sv.c:5110 #5 0x00000000004de7d3 in Perl_sv_free (my_perl=0x6d6010, sv=0x864358) at sv.c:5356 #6 0x00000000005120a4 in Perl_free_tmps (my_perl=0x6d6010) at scope.c:196 #7 0x00000000004c05c4 in Perl_pp_unstack (my_perl=0x6d6010) at pp_hot.c:141 #8 0x00000000004a1259 in Perl_runops_debug (my_perl=0x6d6010) at dump.c:1452 #9 0x00002aaaab446ffc in continue_coro () from blib/arch/auto/Coro/State/State.so #10 0x00002aaaab445b07 in coro_init () from blib/arch/auto/Coro/State/State.so #11 0x0000000000000000 in ?? () Cannot access memory at address 0x2aaaab58b000 (gdb)

Wed Dec 07 16:03:31 2005 MLEHMANN [...] cpan.org - Correspondence added

[SAMV - Tue Dec 6 23:32:02 2005]: I can't reproduce this, but debians debugperl is compiled using a different config than the normal perl, and is in generall incompatible with binary modules (it uses a different allocator, for example). Most modules survive this because there rarely is an exchange of data structures between the perl core and modules, but in case of Coro, there is (Coro has to allocate/free structures that perl has to free/allocate). Your problem could of course be caused by a bug in Coro, but it's hopeless to debug with debugperl - it would need to be reproducible with the normal perl. If you happen to know a nice way of detecting this (I don't, as just detecfting wether this is a dbeug perl is not sufficient) then I could warn about this, but a recompile seems to be required.

Wed Dec 07 16:03:32 2005 MLEHMANN [...] cpan.org - Status changed from 'new' to 'resolved'

Thu Dec 08 20:58:09 2005 SAMV [...] cpan.org - Correspondence added

From:

SAMV [...] cpan.org

[MLEHMANN - Wed Dec 7 16:03:31 2005]: Show quoted text

> I can't reproduce this, but debians debugperl is compiled using a > different config than the normal perl, and is in generall incompatible > with binary modules (it uses a different allocator, for example). Most > modules survive this because there rarely is an exchange of data > structures between the perl core and modules, but in case of Coro, > there > is (Coro has to allocate/free structures that perl has to > free/allocate).

I see. I considered this, and had built Coro with: debugperl Makefile.PL make CC="gcc -g -DDEBUGGING" To compile it with the same options as the debugging perl. Comparing `perl -V' with `debugperl -V' shows that the DEBUGGING option is the only difference, so I thought that this would work. Show quoted text

> Your problem could of course be caused by a bug in Coro, but it's > hopeless to debug with debugperl - it would need to be reproducible > with the normal perl.

Right. I was trying to get a backtrace for a different bug that I found, so I thought I'd try with debugperl. Show quoted text

> If you happen to know a nice way of detecting this (I don't, as just > detecfting wether this is a dbeug perl is not sufficient) then I could > warn about this, but a recompile seems to be required.

Detecting differences between the Perl config used for compilation of Perl and that used for compilation of the module is probably a hairy enough question to sensibly ignore. The best solution to this would be to find a way of compiling a Coro that can work with debugperl. Any ideas?

Thu Dec 08 20:58:12 2005 The RT System itself - Status changed from 'resolved' to 'open'

Fri Dec 09 04:54:49 2005 schmorp [...] schmorp.de - Correspondence added

Date:	Fri, 9 Dec 2005 10:54:02 +0100
From:	Marc Lehmann <schmorp [...] schmorp.de>
To:	via RT <bug-Coro [...] rt.cpan.org>
CC:	undisclosed-recipients: ;
Subject:	Re: [cpan #16335] Test failure with debugging perl
RT-Send-Cc:

On Thu, Dec 08, 2005 at 08:58:09PM -0500, via RT <bug-Coro@rt.cpan.org> wrote: Show quoted text

> I see. I considered this, and had built Coro with: > > debugperl Makefile.PL > make CC="gcc -g -DDEBUGGING" > > To compile it with the same options as the debugging perl. Comparing > `perl -V' with `debugperl -V' shows that the DEBUGGING option is the > only difference, so I thought that this would work.

Don't rely on your eyes, use diff, and you'll see more differences, among them usemyalloc=n vs. usemyalloc=y. Show quoted text

> The best solution to this would be to find a way of compiling a Coro > that can work with debugperl. Any ideas?

Recompile your perl or debugperl with the same options as debugperl or perl. Compile your own perl with -DDEBUGGING and compile coro against it, or recompile your normal perl with -DDEBUGGING. However, -DDEBUGGING slows down your perl, and doesn't give you a backtrace. What you really want is "-g" (with or without optimization), i..e an unstripped perl. -- The choice of a -----==- _GNU_ ----==-- _ generation Marc Lehmann ---==---(_)__ __ ____ __ pcg@goof.com --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE

Mon Jun 05 19:32:35 2006 MLEHMANN [...] cpan.org - Status changed from 'open' to 'resolved'