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)

History Show all quoted text
  Sat Jan 28 20:57:37 2012 joey [...] kitenet.net - Ticket created
Subject: Undefined subroutine &main::main:: called at /usr/share/perl5/YAML/Mo.pm line 5
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.
  Sat Jan 28 21:40:57 2012 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added
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>?
  Sat Jan 28 21:40:58 2012 The RT System itself - Status changed from 'new' to 'open'
  Sun Jan 29 00:41:51 2012 ingy [...] ingy.net - Correspondence added
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>
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. >
  Wed Apr 18 13:01:09 2012 ovid [...] cpan.org - Correspondence added
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
  Wed Apr 18 13:03:38 2012 ovid [...] cpan.org - Correspondence added
Damien Krotkine got the error even shorter: perl -e 'BEGIN { \&main:: } use Mo' Cheers, Ovid
  Wed Apr 18 13:30:37 2012 DAMS [...] cpan.org - Correspondence added
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.
  Thu Apr 19 14:47:57 2012 ingy [...] cpan.org - Correspondence added
fixed in 0.81
  Thu Apr 19 14:47:58 2012 ingy [...] cpan.org - Status changed from 'open' to 'resolved'