Bug 239314 - mod_perl do NOT handle lexical scope correctly.
mod_perl do NOT handle lexical scope correctly.
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: mod_perl (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
Kevin Baker
: 239315 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2007-05-07 11:02 EDT by Klaus Ethgen
Modified: 2014-12-01 18:08 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-06-20 12:13:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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

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

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
         print <<"EOF";
Content-Type: text/plain

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

} # 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 09:36:05 EDT
*** Bug 239315 has been marked as a duplicate of this bug. ***
Comment 2 Joe Orton 2007-05-21 11:08:39 EDT
Can you give the exact mod_perl configuration used?
Comment 3 Klaus Ethgen 2007-05-21 12:04:26 EDT
> Can you give the exact mod_perl configuration used?

LoadModule perl_module modules/mod_perl.so
SetHandler perl-script
PerlSwitches -T
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Comment 4 erik aronesty 2009-02-12 08:34:01 EST
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');


print "1: $t $x";

sub y {
   print "2: $t $x";
Comment 5 erik aronesty 2009-02-20 21:09:52 EST
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 09:18:42 EDT
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 12:13:52 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.