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).
*** Bug 239315 has been marked as a duplicate of this bug. ***
Can you give the exact mod_perl configuration used?
> 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
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"; }
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.
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.
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.