Bug 239314

Summary: mod_perl do NOT handle lexical scope correctly.
Product: Red Hat Enterprise Linux 4 Reporter: Klaus Ethgen <Klaus+rhbz>
Component: mod_perlAssignee: Joe Orton <jorton>
Status: CLOSED WONTFIX QA Contact: Kevin Baker <kbaker>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.5CC: erik, ineilsen
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 16:13:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Klaus Ethgen 2007-05-07 15:02:09 UTC
Description of problem:
mod_perl do NOT handle lexical scope correctly. (See the script below.)

Version-Release number of selected component (if applicable):
1.99_16-4

Steps to Reproduce:
1. Set up a http server
2. Configure it to execute the following script with mod_perl
3. Load (force) the following script _several times_ with a browser

--- script begin ---
#! /usr/bin/perl

sub test1
{
   my $test = join "", map {('a' .. 'z')[int(rand(26))]} (1 .. 6);

   sub _test2
   {
      my $par = shift;

      if ($par eq $test)
      {
         print <<"EOF";
Content-Type: text/plain

Variables identical: $test
EOF
      }
      else
      {
         print <<"EOF";
Content-Type: text/plain

Variables NOT identical: $par != $test
EOF
      } # if ($par eq $test) { ... } els...
   } # _test2

   _test2($test);
} # test1

test1;
--- script end ---
  
Actual results:
Several times: "Variables identical: dfhkdf"
Then most time: "Variables NOT identical: uskeoy != crmcsm"

Expected results:
Always "Variables identical: dfhkdf"

Additional info:
As you can see in the test script there is a function defined in the logical 
scope of a other function (block).

Comment 1 Joe Orton 2007-05-15 13:36:05 UTC
*** Bug 239315 has been marked as a duplicate of this bug. ***

Comment 2 Joe Orton 2007-05-21 15:08:39 UTC
Can you give the exact mod_perl configuration used?

Comment 3 Klaus Ethgen 2007-05-21 16:04:26 UTC
> Can you give the exact mod_perl configuration used?

Sure:
LoadModule perl_module modules/mod_perl.so
SetHandler perl-script
PerlSwitches -T
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders


Comment 4 erik aronesty 2009-02-12 13:34:01 UTC
This bug in file-scoped lexicals took me 3 months to resolve. (mod_perl-2.0.3-9.1.fc7)

It's really horrible, since it only causes problems in certain conditions, and apparently it's systemic (bug exists on other platforms & setups)

Same setup as previous comment (ModPerl::Registry, etc.) 

Sometimes I get a different 1: $t $x  from 2: $t $x, even though they should always be the same.  I can't exactly predict when it occurs.  But if I NEVER use file-scoped lexicals, my code works.   This should be a big fat warning for mod_perl developers.  

use CGI;

our $t;
local $t = time();

$x = CGI::param('foo');

y();

print "1: $t $x";

sub y {
   print "2: $t $x";
}

Comment 5 erik aronesty 2009-02-21 02:09:52 UTC
This is a documentation problem.  Not a bug in mod_perl.

File-scoped lexicals cannot work in mod_perl because of the way that mod_perl works and the way that perl works.

Documenting this is "sort of done" poorly and in various places.

I think it needs to be more prominent, considering how many people have the problem.  imo, mod_perl should probably force warnings about shared vars and/or escalate to and error as the default.

Comment 6 Klaus Ethgen 2009-03-24 13:18:42 UTC
Lets put your eyes to my code fragment above. I did not use file scoped lexicals. All "my" variables are block scoped (local to a function.)

The code above is absolutely correct perl and should be no problem with mod_perl as block scoped variables should be safe.

Comment 8 Jiri Pallich 2012-06-20 16:13:52 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.