You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by ri...@ecos.de on 2011/08/06 20:02:20 UTC
mod_perl 2.0.5 -> Attempt to free unreferenced scalar on startup
Hi,
while trying to get Embperl ready with Perl 5.14.1, I found an the following message in the error log:
Attempt to free unreferenced scalar: SV 0x7fc218, Perl interpreter: 0x7cfdb0 during global destruction.
I spent a lot of time to track it down and I think it's an mod_perl problem and not an Embperl one (because it also happens if Embperl is not loaded at all).
It happens when the perl interpreter gets destructed for the first time, after parsing the configuration. No request is happing, simply starting Apache is enough to see the error.
It has no negative impact, beside that it doesn't look very nice in the log file and that it let Embperl's test suite fail.
I compiled Perl with DEBUG_LEAKING_SCALARS which shows the following in the error log:
----
ALLOCATED at -e:0 by (none) (parent 0x0); serial 356
SV = UNKNOWN(0xff) (0x7fc138) at 0x7fc218
REFCNT = 0
FLAGS = ()
Attempt to free unreferenced scalar: SV 0x7fc218, Perl interpreter: 0x7cfdb0 during global destruction.
----
While the source location of the allocation seems to be uninitialized, the serial is quite useful. Setting a breakpoint inside the S_new_SV in sv.c shows where the SV is allocated:
----
(gdb) p sv->sv_debug_serial
$2 = 356
(gdb) bt
#0 S_new_SV (my_perl=0x7cfdb0, line=8667, func=0x7ffff5b6a070 "Perl_newSV_type", file=0x7ffff5b4dbc0 "sv.c") at sv.c:283
#1 0x00007ffff59d5b69 in Perl_newSV_type (my_perl=0x7cfdb0, type=SVt_PVAV) at sv.c:8667
#2 0x00007ffff5a3b8fb in Perl_new_stackinfo (my_perl=0x7cfdb0, stitems=128, cxitems=101) at scope.c:57
#3 0x00007ffff58fba33 in Perl_init_stacks (my_perl=0x7cfdb0) at perl.c:3882
#4 0x00007ffff58fc077 in perl_construct (my_perl=0x7cfdb0) at perl.c:280
#5 0x00007ffff58ae525 in modperl_startup (s=0x718f90, p=0x709138) at mod_perl.c:246
#6 0x00007ffff58ae4f0 in modperl_startup (s=0x718f90, p=0x709138) at mod_perl.c:207
#7 0x00007ffff58aeb0b in modperl_init (base_server=0x718f90, p=0x709138) at mod_perl.c:458
#8 0x00007ffff58aec6b in modperl_hook_init (pconf=0x709138, plog=<value optimized out>, ptemp=<value optimized out>, s=0x718f90)
at mod_perl.c:631
#9 0x000000000044bbfd in ap_run_open_logs ()
#10 0x0000000000432285 in main ()
(gdb)
----
I stopped further digging inside mod_perl here, because I already spent several hours and I am not so familiar with mod_perl internals anymore, but somebody on the list might have an idea what's going wrong here.
Here is the httpd.conf I used for this test:
--------
HostnameLookups off
ServerAdmin webmaster
ServerRoot "/usr/msrc/embperl/test"
ServerName localhost
DocumentRoot "/usr/msrc/embperl/test"
Listen 8531
User nobody
Group root
MinSpareServers 1
MaxSpareServers 30
StartServers 3
MaxClients 10
MaxRequestsPerChild 0
LoadModule perl_module "/opt/apache2.2.19-perl5141/modules/mod_perl.so"
ErrorLog tmp/httpd.err.log
PidFile tmp/httpd.pid
TypesConfig conf/null
LockFile tmp/httpd.lock
----
Everything is running on a 64Bit OpenSuSE 11.4, here is the output from perl -V
----
Summary of my perl5 (revision 5 version 14 subversion 1) configuration:
Platform:
osname=linux, osvers=2.6.37.1-1.2-xen, archname=x86_64-linux-thread-multi
uname='linux venus 2.6.37.1-1.2-xen #1 smp 2011-02-21 10:34:10 +0100 x86_64 x86_64 x86_64 gnulinux '
config_args='-des -A ccflags=-fPIC -DDEBUGGING -A ccflags=-DDEBUG_LEAKING_SCALARS -Dusedevel -Uinstallusrbinperl -Dusethreads -Duseithreads -Dusemultiplicity -Dprefix=/opt/perlt5.14.1 -Dnoextensions=ODBM_File'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fPIC -DDEBUG_LEAKING_SCALARS -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2 -g',
cppflags='-D_REENTRANT -D_GNU_SOURCE -fPIC -DDEBUG_LEAKING_SCALARS -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.5.1 20101208 [gcc-4_5-branch revision 167585]', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /lib/../lib64 /usr/lib/../lib64 /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64
libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc -lgdbm_compat
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=/lib/libc-2.11.3.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.11.3'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'
Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING DEBUG_LEAKING_SCALARS MULTIPLICITY
PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT
PERL_MALLOC_WRAP PERL_PRESERVE_IVUV
PERL_TRACK_MEMPOOL PERL_USE_DEVEL USE_64_BIT_ALL
USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
USE_PERLIO USE_PERL_ATOF USE_REENTRANT_API
Built under linux
Compiled at Aug 6 2011 13:47:52
@INC:
/opt/perlt5.14.1/lib/site_perl/5.14.1/x86_64-linux-thread-multi
/opt/perlt5.14.1/lib/site_perl/5.14.1
/opt/perlt5.14.1/lib/5.14.1/x86_64-linux-thread-multi
/opt/perlt5.14.1/lib/5.14.1
.
----
Apache is 2.2.19 and Perl, mod_perl and Apache are compiled from the sources. I am using prefork MPM.
I would be happy if anybody has an idea how to fix this.
Thanks
Gerald
Re: mod_perl 2.0.5 -> Attempt to free unreferenced scalar on startup
Posted by Niko Tyni <nt...@debian.org>.
[I sent earlier versions of these to dev@perl.apache.org on Dec 14th and 17th,
Message-ID: <20...@madeleine.local.invalid> and
Message-ID: <20...@madeleine.local.invalid>,
but they never made it through to the list for some reason. Retrying on the
modperl list, apologies for any duplicates.]
On Sat, Aug 06, 2011 at 08:02:20PM +0200, richter@ecos.de wrote:
> while trying to get Embperl ready with Perl 5.14.1, I found an the
> following message in the error log:
> Attempt to free unreferenced scalar: SV 0x7fc218, Perl interpreter:
> 0x7cfdb0 during global destruction.
We're also seeing this in Debian now that we've switched to Perl 5.14,
(see http://bugs.debian.org/650675 [cc'd.])
I managed to cut the problem down to the small attached program,
which embeds perl and mimics modperl_perl_core_global_init() for the
essential part of
GV *gv = gv_fetchpv("myglob", TRUE, SVt_PVCV);
GvCV_set(gv, get_cv("myfunc", TRUE));
The warnings only seem to happen with -Dusethreads, and I've bisected that
they started with 5.13.6 - specifically
http://perl5.git.perl.org/perl.git/commit/ca556bcdca736b2f85c11650c70b2371169c0225
commit ca556bcdca736b2f85c11650c70b2371169c0225
Author: David Mitchell <da...@iabyn.com>
Date: Sun Sep 19 12:33:04 2010 +0100
[perl #40389] perl_destruct() leaks PL_defstash
With PERL_DESTRUCT_LEVEL >= 1, PL_defstash is explicitly freed,
but doesn't actually get freed at that point due to a reference loop
between %:: and *::. Break that loop to ensure that PL_defstash gets freed
at that point. Actually, its not as serious as it sounds, as it would get
freed a bit later anyway by sv_clean_all(), but this new way has these
benefits:
* it gets freed where you expect it to be
* it gets freed cleanly, rather than by the more brutal sv_clean_all()
(which can leave dangling pointers to freed SVs)
* since its freed while *not* under the influence of
PL_in_clean_all = TRUE, it's more likely to flag up bugs related to
double-freeing etc. Indeed, the two previous commits to this are a
result of that.
My limited understanding is that the CV pointer needs its refcount
incremented along with the GvCV_set() call. See the attached proposed
patches which fix all the dozens of such warnings in t/logs/error_log
after running the whole test suite.
Feel free to tell me if I got it all wrong, though :)
Cheers,
--
Niko Tyni ntyni@debian.org