CPAN
view release on metacpan or search on metacpan
# Looks like you planned 72 tests but only ran 43.
# Looks like your test died just after 43.
t/Devel-Caller....dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 44-72
Failed 29/72 tests, 59.72% okay
32195:
t/Devel-Caller....
# Failed (TODO) test 'with lexical $foo'
# at t/Devel-Caller.t line 36.
# got: 'GLOB(0x838b8d0)'
# expected: 'SCALAR(0x83a47b0)'
# Failed (TODO) test 'with lexical @foo'
# at t/Devel-Caller.t line 37.
# got: 'SCALAR(0x84af790)'
# expected: 'ARRAY(0x84b6690)'
# Failed (TODO) test 'with lexical %foo'
# at t/Devel-Caller.t line 38.
# got: 'GLOB(0x84af678)'
# expected: 'HASH(0x84b66b8)'
dubious
Test returned status 0 (wstat 11, 0xb)
DIED. FAILED tests 44-72
Failed 29/72 tests, 59.72% okay
Ah, das heisst doch coredump, oder?
% gdb /home/src/perl/repoperls/installed-perls/perl/pbCbNp9/perl-5.8.0@32195/bin/perl core
GNU gdb 6.6.90.20070912-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1".
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/i686/cmov/libnsl.so.1...done.
Loaded symbols for /lib/i686/cmov/libnsl.so.1
Reading symbols from /lib/i686/cmov/libdl.so.2...done.
Loaded symbols for /lib/i686/cmov/libdl.so.2
Reading symbols from /lib/i686/cmov/libm.so.6...done.
Loaded symbols for /lib/i686/cmov/libm.so.6
Reading symbols from /lib/i686/cmov/libcrypt.so.1...done.
Loaded symbols for /lib/i686/cmov/libcrypt.so.1
Reading symbols from /lib/i686/cmov/libutil.so.1...done.
Loaded symbols for /lib/i686/cmov/libutil.so.1
Reading symbols from /lib/i686/cmov/libpthread.so.0...done.
Loaded symbols for /lib/i686/cmov/libpthread.so.0
Reading symbols from /lib/i686/cmov/libc.so.6...done.
Loaded symbols for /lib/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /home/src/perl/repoperls/installed-perls/perl/pbCbNp9/perl-5.8.0@32195/lib/site_perl/5.10.0/i686-linux-thread-multi-64int/auto/PadWalker/PadWalker.so...done.
Loaded symbols for /home/src/perl/repoperls/installed-perls/perl/pbCbNp9/perl-5.8.0@32195/lib/site_perl/5.10.0/i686-linux-thread-multi-64int/auto/PadWalker/PadWalker.so
Reading symbols from /home/sand/.cpan/build/Devel-Caller-0.11-4u9D7a/blib/arch/auto/Devel/Caller/Caller.so...done.
Loaded symbols for /home/sand/.cpan/build/Devel-Caller-0.11-4u9D7a/blib/arch/auto/Devel/Caller/Caller.so
Failed to read a valid object file image from memory.
Core was generated by `/home/src/perl/repoperls/installed-perls/perl/pbCbNp9/perl-5.8.0@32195/bin/perl'.
Program terminated with signal 11, Segmentation fault.
#0 0xb7f7b51c in glob_out (sigil=36 '$', op=0x84c2cc8, want_name=0)
at lib/Devel/Caller.xs:49
49 case '$': ret = (SV*) GvSV(gv); break;
Hey, it even has debugging symbols. But what's that 'Failed to read a
valid object file image from memory.'?
27705:
/home/src/perl/repoperls/installed-perls/perl/pBY7a0s/perl-5.8.0@27705/bin/perl Build --makefile_env_macros 1 test
t/Devel-Caller....ok 1/72
# Failed (TODO) test 'with lexical $foo'
# in t/Devel-Caller.t at line 36.
# got: 'GLOB(0x82bac48)'
# expected: 'SCALAR(0x839aedc)'
# Failed (TODO) test 'with lexical @foo'
# in t/Devel-Caller.t at line 37.
# got: 'SCALAR(0x83f58c0)'
# expected: 'ARRAY(0x8401304)'
# Failed (TODO) test 'with lexical %foo'
# in t/Devel-Caller.t at line 38.
# got: 'GLOB(0x83f5758)'
# expected: 'HASH(0x840132c)'
t/Devel-Caller....dubious
Test returned status 0 (wstat 11, 0xb)
DIED. FAILED tests 44-72
Failed 29/72 tests, 59.72% okay
Core dump looks the same.
27048:
Same thing, core dump without symbols:
(gdb) bt
#0 0xb7f39941 in glob_out ()
from /home/sand/.cpan/build/Devel-Caller-0.11-K2jwTc/blib/arch/auto/Devel/Caller/Caller.so
#1 0xb7f39eb4 in XS_Devel__Caller__called_with ()
from /home/sand/.cpan/build/Devel-Caller-0.11-K2jwTc/blib/arch/auto/Devel/Caller/Caller.so
#2 0x080d090b in Perl_pp_entersub ()
#3 0x080c85a9 in Perl_runops_standard ()
#4 0x0806559b in perl_run ()
#5 0x0806034d in main ()
16500:
Ahh, PadWalker 1.5 denies working with 5.7.3, demands minimum 5.8.2
19367:
Everything like in 27048 and the others above.
17706:
PadWalker 1.5 does not pass its own tests:
t/test........FAILED tests 9, 15
Failed 2/15 tests, 86.67% okay
t/tt..........FAILED tests 3-4
Failed 2/5 tests, 60.00% okay
I do a 'force install' on it. I then have to install Module::Build and
ExtUtils::CBuilder and then I can install Devel::Caller and it tests OK:
cc -shared -L/usr/local/lib -o blib/arch/auto/Devel/Caller/Caller.so lib/Devel/Caller.o
Manifying blib/lib/Devel/Caller.pm -> blib/libdoc/Devel::Caller.3
RCLAMP/Devel-Caller-0.11.tar.gz
/usr/bin/make -- OK
Warning (usually harmless): 'YAML' not installed, will not store persistent state
Running make test
/home/src/perl/repoperls/installed-perls/perl/pY6kBLf/perl-5.8.0@17706/bin/perl Build --makefile_env_macros 1 test
t/Devel-Caller....ok
26/72 unexpectedly succeeded
All tests successful (26 subtests UNEXPECTEDLY SUCCEEDED).
Files=1, Tests=72, 0 wallclock secs ( 0.09 cusr + 0.01 csys = 0.10 CPU)
RCLAMP/Devel-Caller-0.11.tar.gz
/usr/bin/make test -- OK
Warning (usually harmless): 'YAML' not installed, will not store persistent state
A few minutes later I have installed several other modules for a
frictionless binary search and these programs then find a Devel::Caller
that does not pass its own test anymore. Why?
I remove the installation and reinstall with ./installperl from the
build directory. I install as above the three PadWalker, M:B and EU:CB
I see Devel::Caller working again. I make a backup or this tree. I
re-run './Build test' several times in the Devel-Caller-0.11-iL3qS5/
directory, always success.
Now I try to install the Bundle::CPANxxl piece by piece. YAML::Syck
fails. IO::Tty OK. Expect OK. YAML fails. Test::Harness OK.
% ./Build test
t/Devel-Caller....ok
26/72 unexpectedly succeeded
TODO PASSED tests 12-14, 44-66
All tests successful (26 subtests UNEXPECTEDLY SUCCEEDED).
Passed TODO Stat Wstat TODOs Pass List of Passed
-------------------------------------------------------------------------------
t/Devel-Caller.t 26 26 12-14 44-66
Files=1, Tests=72, 0 wallclock secs ( 0.07 cusr + 0.03 csys = 0.10 CPU)
Arrrrgrrrr, I misread this as a fail in my previous look at the terminal.
18554:
PadWalker passes its tests but D:C dumps core
18037:
PadWalker fails the two tests mentioned above and I force the install.
Devel::Caller passes its tests.
18300:
PadWalker is installed, so must have passed its test. D:C has its SEGV.
18150:
Padwalker fails as above. force install. D:C SEGV.
18078:
Padwalker fails as above. force install. D:C SEGV.
18057:
Padwalker fails as above. force install. D:C SEGV.
18048:
Padwalker fails as above. force install. D:C SEGV.
18047: no SEGV
2007-10-27 Andreas J. Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de>
* Net-Daemon's recent FAILS under threads seems to be due to the way the
old Thread.pm has now become a compatibility layer. Its t/thread.t tests
if (!eval { require Thread; my $t = Thread->new(sub { }) }) {
print "1..0\n";
exit 0;
}
The compat layer seems to have started working between 30910 and 32032:
% for p in `binsearchaperl --show-cache --bounds 27048-33000 --apcdir /home/src/perl/repoperls/APC --prefix /home/src/perl/repoperls/installed-perls --cachefilter tests/filter-threaded.pl `; do
$p -MThread -e 'print substr($^X,64), ": ", eval{Thread->new(sub { })} ? "" : "not ", "ok\n"'
done 2>/dev/null
@27048/bin/perl: ok
@29353/bin/perl: not ok
@30910/bin/perl: not ok
@31500/bin/perl: ok
@32032/bin/perl: ok
@32174/bin/perl: ok
@32186/bin/perl: ok
@32194/bin/perl: ok
@32195/bin/perl: ok
but probably not good enough to run the whole code in t/thread.t.
I would guess that somewhere between 27048 and 29353 the compatibility
layer broke heavily and somewhere between 30910 and 31500 they
fixed it a bit. 30955 was the last change to Thread.pm. The fix for our
minimal testcase came a bit before that:
----Program----
require Thread;
print eval{Thread->new(sub { })} ? "ok\n" : "not ok\n";
----Output of .../pCY4xFO/perl-5.8.0@30952/bin/perl----
not ok
----EOF ($?='0')----
----Output of .../pQ8RfLX/perl-5.8.0@30953/bin/perl----
Yesterday I resolved it by putting YAML on the dont_load_list. Today I
would prefer to find some indications towards a possible reason. The
program hangs while parsing or writing FTPstats.yml such that no other
program can use CPAN.pm because it waits for the lock.
(Note: 29704 has arrived while I'm investigating)
% gdb -p 17086
GNU gdb 6.4.90-debian
Copyright (C) 2006 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 "i486-linux-gnu".
Attaching to process 17086
Reading symbols from /home/src/perl/repoperls/installed-perls/perl/pU42elH/perl-5.8.0@29672/bin/perl...done.
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
Reading symbols from /lib/tls/i686/cmov/libnsl.so.1...done.
Loaded symbols for /lib/tls/i686/cmov/libnsl.so.1
[...]
Reading symbols from /home/src/perl/repoperls/installed-perls/perl/pU42elH/perl-5.8.0@29672/lib/5.9.5/i686-linux-64int/auto/B/B.so...done.
Loaded symbols for /home/src/perl/repoperls/installed-perls/perl/pU42elH/perl-5.8.0@29672/lib/5.9.5/i686-linux-64int/auto/B/B.so
Failed to read a valid object file image from memory.
0x08179c8b in Perl_leave_scope (base=497) at scope.c:627
627 switch (SSPOPINT) {
(gdb) bt
#0 0x08179c8b in Perl_leave_scope (base=497) at scope.c:627
#1 0x08177214 in Perl_pop_scope () at scope.c:99
#2 0x0818ddf8 in Perl_pp_return () at pp_ctl.c:2077
#3 0x080bd3eb in Perl_runops_debug () at dump.c:1875
#4 0x080ef6cc in S_run_body (oldscope=1) at perl.c:2398
#5 0x080eecfe in perl_run (my_perl=0x82d9008) at perl.c:2323
#6 0x0805e791 in main (argc=2, argv=0xbfd69b34, env=0xbfd69b40)
at perlmain.c:113
(gdb)
By stepping with "n" I reach the seemingly endless loop:
1855 PERL_ASYNC_CHECK();
(gdb)
1856 if (PL_debug) {
(gdb)
1875 } while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX)));
(gdb)
1855 PERL_ASYNC_CHECK();
This is with 29672. I just retried to load YAML again and the hosts
command did succeed, but it was slow (several minutes for 10000
downloads)
* Spreadsheet::ParseExcel broken recently. Also seems to affect
Module::Plan::Lite. But binary search points to 29672 which cannot be to
blame. SOLVED in rt.cpan.org
2007-01-05 Andreas J. Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de>
* is match/module compatible with SQLite? Is match/module the single
cause for the slowness I encounter today? Is just 29679 broken? It
cannot build PadWalker or it's just slow? Yes, it's only 29679. Something
between YAML and the core. 78 and 80 are OK.
I can add YAML to dont_load_list for 79, then build YAML::Syck and all
goes well.
* bug: force get on a dot distro removes {archived} which confuses make
FIXED
* distcc/ccache: I should use it for Tk. USING IT
* Xvfb for testing Tk: Slaven writes
Xvfb -fp /usr/X11R6/lib/X11/fonts/misc -ac :121 &
env DISPLAY=:121 make test
Also needed for POE which opens Tk windows.
2007-01-04 Andreas J. Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de>
* maybe have a is_tested command? The SVK revision 1694 is just a trial,
probably needs a rollback. The problems come from concurrency. We
currently are not supporting modules tested by a different process that
runs simultaneously. So we should test it with a perl that has already
finished megainstall.
* Port auto_commit to 1.8803 . NOT NEEDED
2007-01-03 Andreas J. Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de>
* Paul Johnson has put out Devel::Cover 0.60
make test did not succeed for me on the SVN version. Must retry with
0.60 proper. Same thing. Must try other perls.
* concurrency: the most critical point at the moment seems to be the
cleanup of the build directory and another process trying to access one
of the directories with chdir to build_dir. This dies without a
Distrostatus in
Couldn't chdir to /home/k/.cpan/build/Term-ReadLine-Gnu-1.16-MacKnJ at lib/CPAN.pm line 8839
Stupid use of croak(), we want die or confess and want to fix it when it
happens again.
Turned into confess in SVK rev. 1632
* Are the dot directories documented? Where? Is chdir mentioned there?
Yes, it was documented in the section "Integrating local directories"
and I rewrote it a bit, it sounded too boring. It still sounds boring
and leads me to the idea to support
get:
commandline:
I'll have to think some more about it. (Also consider Ingy's move to
prefer SVN over CPAN)
* somebody sending a Tk window during a test just waiting to be clicked
away? Who is it? Tk itself? Maybe this was just a single revision? NO,
only read them (by setting expiration time to inf). DONE 1181 Actually,
this was nonsense. the expiration time must not be changed. The user
wants to read index files from time to time... REVERTED in 1188
ability to reload index: turn off for the second DONE 1181
storing/listing local bundles: risk REVISIT LATER
local directories with the dot: risk REVISIT LATER
shared source: make it atomic to download (if it isn't yet) DONE 1180
Different perspective: batch jobs have not had a lock ever since CPAN.pm
exists. They could break each other on any occasion. Did they write the
histfile? Seems not so. Timestamp does not change with my tests and it
does not say "Lockfile removed". Yes, checklock is only called from the
shell (and from mkmyconfig but this is negligible). REVISIT mkmyconfig
But they read metadata and shouldn't. Disable! DONE 1181
And they reuse build_dir. Disable! DONE 1181
But they MUST read the index files: make writing atomic! DONE 1180
Is CPAN::FTP::localize doing its storage management atomicly? YES, since 1180
Todo: consider setting scan_cache to "never" or maybe not.
* Todo: compare the output of the 'failed' command within megainstall
and after reentering the shell. DONE and found one bug and fixed it in
rev. 1178
* I wanted to watch some scenarios with persistent data. Especially with
modules that work and that are being tested again and again with prereqs
and without or within bundles and if they are retested or not, installed
or not with persistence and within the same session.
Write a megatest?
* Wondering why I find this in the build directory in Crypt-CBC-2.22.yml:
writemakefile: !!perl/hash:CPAN::Distrostatus
COMMANDID: 0
FAILED: ''
TEXT: YES
Note the 0 in COMMANDID.
A: The reason is that we only issued one command with 'make
megainstall', so this is correct.
* Does the shell still do locking? Under which circumstances is locking
turned off? Console/terminal I suppose.
A: yes.
2006-10-31 Andreas J. Koenig <andreas.koenig.gmwojprw@franz.ak.mind.de>
* just a memo what I usually install:
install Bundle::CPANxxl Math::BigInt::GMP Plagger Bundle::Phalanx100 Jifty Coro Getopt::Euclid DBIx::Class IPC::PubSub Bundle::Pause PadWalker Graph::Easy
YAML::Syck after Bundle::CPAN did not turn off interactivity.
YAML::Syck before Bundle::CPAN worked well.
CPAN::Reporter before YAML worked well but we want to catch the early
YAML interactivity (which in turn can be avoided with YAML::Syck).
Now all in "make megainstall" including logging.
* Todo: some capture stuff maybe collected into the YAML files in
build_dir that contains all relevant output of that distro so we can
study the nonsense that currently goes on when I do my mega install on
maint-5.8.
For some reason some modules failed early in the cycle and then never
got re-tested. And they broke others which also didn't get re-tested. In
the end we had a lot of modules uninstalled that would test individually
well but all refused to re-test without force.
One simple solution was to 'force test Bundle::CPANxxl' but that took
many minutes again.
[What's the deal with PathTools? Ahh, the dependency on
ExtUtils::CBuilder again. I have reported the bug but it is not yet
fixed. FIXED in Bundle::CPAN by pulling CBuilder to the front,]
For example the chain broke: CPAN::Checksums -> Data::Compare ->
File::Find::Rule -> Number::Compare. I could install Number::Compare now
when I asked for it (without force!), and then the chain could be
resolved step after step.
Something's fishy.
2006-10-30 Andreas J. Koenig <andreas.koenig.gmwojprw@franz.ak.mind.de>
* Q: Why is this: during install Bundle::Phalanx100 I get for
DBD::Oracle a writemakefile NO
'/home/src/perl/repoperls/installed-perls/perl/pIOeQkH/perl-5.8.0@29165/bin/perl
Makefile.PL' returned status 65280
When I leave the shell and start it again and call 'failed' it is gone.
A: because we did not care for the state safe
Fixed in rev. 1172
2006-10-30 Andreas J Koenig <akoenig@*c*nm*b*l*.com>
* From: "David Golden" <xdaveg@gmail.com>
Subject: CPAN::Reporter and Bundle::CPAN
To: "Andreas J. Koenig" <andreas.koenig.gmwojprw@franz.ak.mind.de>
Date: Mon, 30 Oct 2006 10:04:05 -0500
With CPAN::Reporter 0.29, all the config items are switched over. The
Todo backlog is still non-trivial, but I don't think any of the items
will cause back-compatibilty problems down the line. Given that,
please feel free to add CPAN::Reporter to Bundle::CPAN whenever you
have a chance.
( run in 1.635 second using v1.01-cache-2.11-cpan-d8267643d1d )