This distribution has been tested as part of the cpan-testers
effort to test as many new uploads to CPAN as possible. See
http://testers.cpan.org/

Please cc any replies to cpan-testers@perl.org to keep other
test volunteers informed and to prevent any duplicate effort.

--
Dear Marc Lehmann,

This is a computer-generated test report for AnyEvent-2.1, created
automatically by CPAN::Reporter, version 0.35, and sent to the CPAN
Testers mailing list. If you have received this email directly, it is
because the person testing your distribution chose to send a copy to your
CPAN email address.

Thank you for uploading your work to CPAN. However, it appears that
there were some problems testing your distribution.

Sections of this report:

* Tester comments
* Prerequisites
* Environment and other context
* Test output

On Thu, 30 Nov 2006, David Precious wrote:

Hmm. I deleted it and redownloaded, same issue (that was using the CPAN
module), also downloaded it myself and did perl Makefile.PL; make; make
test and got the same error.

I don't believe this is machine related.

I've just had the same error from a different machine:

t/01_basic....nyEven: not a valid method for AnyEvent objects at
t/01_basic.t line 8

I also see some other failures which look like the same problem, for an
example:
http://www.nntp.perl.org/group/perl.cpan.testers/379277

and some others which don't give the error message but are also failing at
01_basic.t (could be completely unrelated).

On Wed, Nov 29, 2006 at 01:50:28PM +0000, David Precious preshweb.co.uk> wrote:

Are you sure your hardware is working?

There is no such thing in t/01 basic.t. The line looks like:

my $cv = AnyEvent->condvar;

Please note that your error message contains a binary zero, which can only
be caused by some form of memory corruption, as you can't specify 0 bytes
as method names unquoted.

Can you retry the test on a non-faulty machine?

--
The choice of a

On 11/30/06, David Precious preshweb.co.uk> wrote:

Ditto. After some digging, it looks like $AUTOLOAD is getting mangled
before the method call (somewhere during detection of event modules),
so that the method call turns into another call to AUTOLOAD().

I saved it away in a lexical instead

(my $fcn = $AUTOLOAD) =~ s/.*://;

and changed all references to $AUTOLOAD accordingly and it seemed to
work. (Well, it hung up at first, then I upgraded Event.pm and then
it worked, but it didn't die the way it was.)

Also, for testing, you might want to force a particular event module
rather than rely upon whatever gets detected. You could even re-run
the tests for each event module that is available. You'd probably
have to use a code reference in @INC to make it work, but it would
probably lead to better information back from your test reports as
you'd be able to know exactly what the underlying module is.

On Thu, Nov 30, 2006 at 03:25:50PM +0000, David Precious preshweb.co.uk> wrote:

(Sorry for answering in reverse order).

Thats not the same symptom.

That neither.

On Fri, Dec 01, 2006 at 07:50:39AM -0500, David Golden gmail.com> wrote:

This looks like a rather disastrous case of memory corruption. If hardware
can be ruled out, and issues like compilers too, it is likely a bug in perl.

As I cannot reproduce this with 5.8.8, could you try it with a current
version of perl to see wether this bug has been fixed in the meantime?

On 12/1/06, Marc Lehmann wrote:

It is.

$ perl -V
Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
Platform:
osname=linux, osvers=2.6.17-10-generic, archname=i686-linux-64int-ld
uname='linux vulcan 2.6.17-10-generic...

On 12/2/06, Marc Lehmann wrote:

OK. I can understand that

On Sat, Dec 02, 2006 at 09:13:47AM -0500, David Golden gmail.com> wrote:

Thanks, thats good, although at least one very similar failure was
reported with a 5.8.8 perl.

I do not think so, but you might know better than me, of course.

I am. What makes you think differently?