Item14399: Deep recursion in Foswiki::Engine::Legacy line 44

  DB<1> n
Installing extensions: MetaDataPlugin
Processing MetaDataPlugin
Foswiki::Engine::Legacy::CODE(0x33230d8)(lib/Foswiki/Engine/Legacy.pm:44):
44:             if ( defined $request ) {
1000 levels deep in subroutine calls!
  DB<1> q

pseudoInstall.pl MetaDataPlugin causes the issue, while checking dependency JsonRpcContrib.

Some comments on the need for the Legacy engine are in Item714. In this case, the issue is prevented by forcing one of the other engines in pseudo-install.pl

diff --git a/core/pseudo-install.pl b/core/pseudo-install.pl
index 84a7989..1b80d00 100755
--- a/core/pseudo-install.pl
+++ b/core/pseudo-install.pl
@@ -590,6 +590,10 @@ sub installFromMANIFEST {
 
     trace "Using manifest from $manifest";
 
+# SMELL: If engine falls back to the Legacy engine, under some conditions
+# a deep recursion loop occurrs, checking the dependency on JsonRpcContrib.  This avoids the issue.
+    $Foswiki::cfg{Engine} = 'Foswiki::Engine::CLI';
+
     open( my $df, '<', $manifest )
       or die "Cannot open manifest $manifest for reading: $!";
     my @files = (<$df>);

The legacy engine is used successfully when running tools/dependencies.

-- GeorgeClark - 16 May 2017

The following is a minimal recreation:

perl -d -I lib -e "require Foswiki::Contrib::JsonRpcContrib"

Loading DB routines from perl5db.pl version 1.51
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main::(-e:1):   require Foswiki::Contrib::JsonRpcContrib
  DB<1> r
Foswiki::Engine::Legacy::CODE(0x2eb19f0)(lib/Foswiki/Engine/Legacy.pm:44):
44:             if ( defined $request ) {
1000 levels deep in subroutine calls!
  DB<1> q

-- GeorgeClark - 16 May 2017

The issue is caused because JsonRpcContrib.pm has a "use Foswiki::Request" to support the BEGIN block for backwards compatibility with the multi_param function. This causes the Foswiki::Request to run with an incomplete environment.

-- GeorgeClark - 16 May 2017

Found all of the plugins that have this structure, and tried them as above. The other plugins that can trigger this with a "require ..." are the EditRowPlugin, TablePlugin, and SlideShowPlugin.

The EditTablePlugin, MetaDataPlugin, WysiwygPlugin, NatEditPlugin and JQueryPlugin have a similar implementation, but do not trigger the issue.

It doesn't seem to have anything to do with the enable status of the plugin. I don't see why it fails on some works fine on others. But I think that the bottom line is that the plugin code is executing without a properly established environment. I'm not sure how to resolve this.

-- GeorgeClark - 16 May 2017

The issue appears to be the "use Foswiki::Request" without a "use Foswiki" If I change the extension module to also have a "use Foswiki", then the problem resolves. I'm guessing that this has to do with the order of the BEGIN block execution.

-- GeorgeClark - 16 May 2017

Given that the Legacy engine is for "Pre-1.0 CGI scripts", maybe we can just eliminate it. Moving the code that auto-detects CGI vs CLI into Foswiki.pm rather than defaulting to Legacy appears to work fine.

-- GeorgeClark - 17 May 2017

Commenting is disabled while not logged in