You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Tom Murphy <tm...@netchemistry.com> on 2004/10/14 20:13:23 UTC
MP1: Odd localized variable behavior
I've inherited a bunch of code which occasionally uses localized my
variables in subroutines routines within file scope. I thought that this
was legit, if not the cleanest use of "my" variables. Note that this pared
down script gives a
The Code:
---------------------------------
use strict;
use Devel::Peek;
## create a file scoped localized variable
my $url = "top of main";
Dump( $url );
runit();
## take a look after the subroutine invocation.
Dump( $url );
return ;
sub runit{
## set the my variable in the subroutine
$url = "top of runit";
Dump( $url );
}
The error_log from running in -X mode.
##### inserted for clarity, the first invocation
SV = PV(0x3e08b8) at 0x3ae520
REFCNT = 2
FLAGS = (PADBUSY,PADMY,POK,pPOK)
PV = 0x4dd880 "top of main"\0
CUR = 11
LEN = 12
SV = PV(0x3e08b8) at 0x3ae520
REFCNT = 2
FLAGS = (PADBUSY,PADMY,POK,pPOK)
PV = 0x4dd880 "top of runit"\0
CUR = 12
LEN = 13
SV = PV(0x3e08b8) at 0x3ae520
REFCNT = 2
FLAGS = (PADBUSY,PADMY,POK,pPOK)
PV = 0x4dd880 "top of runit"\0
CUR = 12
LEN = 13
#### inserted for clarity, the second invocation
SV = PV(0x4e2c64) at 0x4da380
REFCNT = 1
FLAGS = (PADBUSY,PADMY,POK,pPOK)
PV = 0x4dd6e8 "top of main"\0
CUR = 11
LEN = 12
SV = PV(0x3e08b8) at 0x3ae520
REFCNT = 1
FLAGS = (PADBUSY,PADMY,POK,pPOK)
PV = 0x4dd880 "top of runit"\0
CUR = 12
LEN = 13
SV = PV(0x4e2c64) at 0x4da380
REFCNT = 1
FLAGS = (PADBUSY,PADMY,POK,pPOK)
PV = 0x4dd6e8 "top of main"\0
CUR = 11
LEN = 12
### A third invocation
SV = PV(0x4e2c64) at 0x4da380
REFCNT = 1
FLAGS = (PADBUSY,PADMY,POK,pPOK)
PV = 0x4dd6e8 "top of main"\0
CUR = 11
LEN = 12
SV = PV(0x3e08b8) at 0x3ae520
REFCNT = 1
FLAGS = (PADBUSY,PADMY,POK,pPOK)
PV = 0x4dd880 "top of runit"\0
CUR = 12
LEN = 13
SV = PV(0x4e2c64) at 0x4da380
REFCNT = 1
FLAGS = (PADBUSY,PADMY,POK,pPOK)
PV = 0x4dd6e8 "top of main"\0
CUR = 11
LEN = 12
According to how I understand perl/mod_perl workings, the actual address of
the SV shouldn't change regardless of the number of invocations of the
script ( assuming the file modification time doesn't change ). Upon the
second invocation it looks like the sub has retained the original SV and the
file level usage has created a new SV. Oddly, after the second invocation,
none of the address change.
Any ideas?
Tom Murphy
Config as follows:
Server version: Apache/1.3.29 (Unix)
Server built: Nov 11 2003 15:44:23
Server's Module Magic Number: 19990320:15
Server compiled with....
-D EAPI
-D HAVE_MMAP
-D USE_MMAP_SCOREBOARD
-D USE_MMAP_FILES
-D HAVE_FCNTL_SERIALIZED_ACCEPT
-D HAVE_SYSVSEM_SERIALIZED_ACCEPT
-D HAVE_PTHREAD_SERIALIZED_ACCEPT
-D DYNAMIC_MODULE_LIMIT=64
-D HARD_SERVER_LIMIT=256
-D HTTPD_ROOT="/usr/local/apachessl"
-D SUEXEC_BIN="/usr/local/apachessl/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/httpd.scoreboard"
-D DEFAULT_LOCKFILE="logs/httpd.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
-D ACCESS_CONFIG_FILE="conf/access.conf"
-D RESOURCE_CONFIG_FILE="conf/srm.conf"
ncsun36:bin-> perl -V
Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
Platform:
osname=solaris, osvers=2.7, archname=sun4-solaris
uname='sunos ncsun25 5.7 generic_106541-34 sun4u sparc sunw,ultra-5_10 '
config_args='-Dprefix=/local/apps/perl -Dcc=gcc -des'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-fno-strict-aliasing -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O',
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='egcs-2.91.66 19990314 (egcs-1.1.2 release)',
gccosandvers='solaris2.7'
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib '
libpth=/usr/local/lib /usr/lib /usr/ccs/lib
libs=-lsocket -lnsl -ldl -lm -lc
perllibs=-lsocket -lnsl -ldl -lm -lc
libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under solaris
Compiled at Jul 6 2004 10:46:01
%ENV:
PERL5LIB="/local/apps/ospomv4/lib:/local/apps/ospomv4/bin"
@INC:
/local/apps/ospomv4/lib
/local/apps/ospomv4/bin
/local/apps/perl/lib/5.8.4/sun4-solaris
/local/apps/perl/lib/5.8.4
/local/apps/perl/lib/site_perl/5.8.4/sun4-solaris
/local/apps/perl/lib/site_perl/5.8.4
/local/apps/perl/lib/site_perl
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: MP1: Odd localized variable behavior
Posted by Perrin Harkins <pe...@elem.com>.
On Thu, 2004-10-14 at 14:13, Tom Murphy wrote:
> According to how I understand perl/mod_perl workings, the actual address of
> the SV shouldn't change regardless of the number of invocations of the
> script ( assuming the file modification time doesn't change ). Upon the
> second invocation it looks like the sub has retained the original SV and the
> file level usage has created a new SV. Oddly, after the second invocation,
> none of the address change.
>
> Any ideas?
It's just creating a closure. That's what happens when you reference a
lexical declared in a higher-level scope from inside a sub. If you were
not intending to create a closure, you need to pass the variable to the
sub instead.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html