Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the YAML CPAN distribution.

Report information
The Basics
Id: 74487
Status: resolved
Priority: 0/
Queue: YAML

People
Owner: Nobody in particular
Requestors: joey [...] kitenet.net
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.78
Fixed in: (no value)



Subject: Undefined subroutine &main::main:: called at /usr/share/perl5/YAML/Mo.pm line 5
Download (untitled) / with headers
text/plain 858b
Error: Undefined subroutine &main::main:: called at /usr/share/perl5/YAML/Mo.pm line 5. Compilation failed in require at /usr/share/perl5/YAML.pm line 3. BEGIN failed--compilation aborted at /usr/share/perl5/YAML.pm line 3. Compilation failed in require at (eval 1437) line 2. BEGIN failed--compilation aborted at (eval 1437) line 2. I sadly have no test case that can reproduce this easily, but two of us have seen it when using a particular CGI application that contains eval q{use {YAML}}; Changing the code to use YAML; Or even to eval q{use {YAML::XS}}; Avoids the problem. Also, moving the eval to happen before a call to CGI::Session->new avoids the problem. For details, see http://bugs.debian.org/657533 Line 5 of Yaml::Mo, besides being an impressive feat of obfuscation, is apparently doing something very dire with the symbol table.
On Sat Jan 28 20:57:37 2012, JOEY wrote: Show quoted text
> Error: Undefined subroutine &main::main:: called at > /usr/share/perl5/YAML/Mo.pm line 5. Compilation failed in require at > /usr/share/perl5/YAML.pm line 3. BEGIN failed--compilation aborted at > /usr/share/perl5/YAML.pm line 3. Compilation failed in require at > (eval 1437) line 2. BEGIN failed--compilation aborted at (eval 1437) > line 2. > > I sadly have no test case that can reproduce this easily, but two of > us have seen it > when using a particular CGI application that contains > > eval q{use {YAML}}; > > Changing the code to > > use YAML; > > Or even to > > eval q{use {YAML::XS}}; > > Avoids the problem. Also, moving the eval to happen before a call to > CGI::Session->new > avoids the problem. > > For details, see http://bugs.debian.org/657533 > > Line 5 of Yaml::Mo, besides being an impressive feat of obfuscation, > is apparently > doing something very dire with the symbol table.
Could this be related to <https://rt.perl.org/rt3/Ticket/Display.html?id=107370>?
Subject: Re: [rt.cpan.org #74487] Undefined subroutine &main::main:: called at /usr/share/perl5/YAML/Mo.pm line 5
Date: Sat, 28 Jan 2012 21:41:42 -0800
To: bug-YAML [...] rt.cpan.org
From: Ingy dot Net <ingy [...] ingy.net>
Download (untitled) / with headers
text/plain 1.5k
What happens if you change line 2 of YAML::Mo to # use Mo qw[builder default import]; then run the script: mo-inline then install YAML: perl Makefile.PL make install Let me know. I saw errors related to xxx and that's not needed, per se. On Sat, Jan 28, 2012 at 5:57 PM, Joey Hess via RT <bug-YAML@rt.cpan.org>wrote: Show quoted text
> Sat Jan 28 20:57:37 2012: Request 74487 was acted upon. > Transaction: Ticket created by JOEY > Queue: YAML > Subject: Undefined subroutine &main::main:: called at > /usr/share/perl5/YAML/Mo.pm > line 5 > Broken in: 0.78 > Severity: (no value) > Owner: Nobody > Requestors: joey@kitenet.net > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=74487 > > > > Error: Undefined subroutine &main::main:: called at > /usr/share/perl5/YAML/Mo.pm line 5. Compilation failed in require at > /usr/share/perl5/YAML.pm line 3. BEGIN failed--compilation aborted at > /usr/share/perl5/YAML.pm line 3. Compilation failed in require at > (eval 1437) line 2. BEGIN failed--compilation aborted at (eval 1437) > line 2. > > I sadly have no test case that can reproduce this easily, but two of us > have seen it > when using a particular CGI application that contains > > eval q{use {YAML}}; > > Changing the code to > > use YAML; > > Or even to > > eval q{use {YAML::XS}}; > > Avoids the problem. Also, moving the eval to happen before a call to > CGI::Session->new > avoids the problem. > > For details, see http://bugs.debian.org/657533 > > Line 5 of Yaml::Mo, besides being an impressive feat of obfuscation, is > apparently > doing something very dire with the symbol table. >
Download (untitled) / with headers
text/plain 540b
This may be related to a bug I reported in Safe.pm. https://rt.cpan.org/Ticket/Display.html? id=76664&results=b7af04d4df5e37ff7fa08a96454c6848 This: use Safe; BEGIN { Safe->new } use YAML 0.80; That can actually be reduced to this one-liner: perl -e 'BEGIN { \&main:: } use YAML 0.80' Bad logic in the top of Safe.pme leaves empty strings in the $default_share variable, causing &main:: to be shared (and very strange YAML::Mo code didn't help). Grepping out the empty strings makes the error go away. Cheers, Ovid
Damien Krotkine got the error even shorter: perl -e 'BEGIN { \&main:: } use Mo' Cheers, Ovid
Download (untitled) / with headers
text/plain 140b
And here is the fix : https://github.com/ingydotnet/mo-pm/pull/16 As Mo is inlined into YAML::Mo, you'll want to apply the fix here too.
fixed in 0.81


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.