Re: Scalar leaked in 'local $0' under ithreads + taint mode
Dave Mitchell wrote: >On Mon, Jul 11, 2005 at 01:29:37PM +0100, Steve Hay wrote: > > >>The patch below fixes it, and all tests still pass. Is it OK? >> >> > >looks good to me > Marvellous. Now applied. Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: Scalar leaked in 'local $0' under ithreads + taint mode
On Mon, Jul 11, 2005 at 01:29:37PM +0100, Steve Hay wrote: > The patch below fixes it, and all tests still pass. Is it OK? looks good to me -- A power surge on the Bridge is rapidly and correctly diagnosed as a faulty capacitor by the highly-trained and competent engineering staff. -- Things That Never Happen in "Star Trek" #9
Re: Scalar leaked in 'local $0' under ithreads + taint mode
Dave Mitchell wrote:
>On Fri, Jul 08, 2005 at 09:36:19AM +0100, Steve Hay wrote:
>
>
>>The crash is deliberately forced by win32_checkTLS(), but I don't
>>understand for what reason. PerlEnvGetenv() takes an IPerlEnv* and uses
>>the IPERL2HOST() macro (which is set to IPerlEnv2Host()) to locate the
>>CPerlHost* which that IPerlEnv* is a member of. It then calls
>>win32_checkTLS() to check that the host_perl in the CPerlHost* that has
>>been found is my_perl. Evidently, in this case host_perl != my_perl, so
>>it bombs out.
>>
>>Does anyone know what this my_perl is? What is the purpose of the
>>host_perl != my_perl check, and why might it be failing?
>>
>>
>
>my_perl is a pointer to the current perl interpreter; in a threaded build,
>it's normally passed as an extra 1st arg to most functions (that's what all
>the pTHX/aTHX stuff is for); functions that don't get it passed can
>have 'dTHX;' at their start, which declares my_perl and determines it from
>thread-local storage (this is slow).
>
>win32_checkTLS() appears to be sanity checking that the passed host_perl is
>the same as the my_perl determined by dTHX; since is this happening during the
>middle of cloning, this isn't likely to be the case.
>
>
Thanks for the explanation. I've learnt something there.
>The real question is why is PerlIO_debug() getting called for the first time
>during cloning? On my system, it's getting called much earlier, during
>perl_parse(). A second possibility is that it's not being called for the
>first time, but that in this code:
>
>PerlIO_debug(const char *fmt, ...)
>{
> va_list ap;
> dSYS;
> va_start(ap, fmt);
> if (!PL_perlio_debug_fd && !PL_tainting && PL_uid == PL_euid && PL_gid
> == PL_egid) {
> const char *s = PerlEnv_getenv("PERLIO_DEBUG");
> if (s && *s)
> PL_perlio_debug_fd = PerlLIO_open3(s, O_WRONLY | O_CREAT |
> O_APPEND, 0666);
> else
> PL_perlio_debug_fd = -1;
>
>for some reason PerlLIO_open3() is setting PL_perlio_debug_fd to 0, so
>that each time PerlIO_debug is called, it will still do a
>PerlEnv_getenv("PERLIO_DEBUG"). Perhaps?
>
>Can you detemine when PerlIO_debug() is being called, and if whether it's
>calling PerlLIO_open3() and whether that's rturning 0?
>
I have PerlIO_debug() being called many times over from perl_parse() but
every time the PerlEnv_getenv() call is not reached because PL_tainting
is true.
However, as soon as PerlIO_debug() gets called during cloning, I find
that PL_tainting is now false and hence the PerlEnv_getenv() call is
reached and crashes as you explained above.
It looks like PL_tainting isn't getting set soon enough for the above
code to be happy. Line 11382 of sv.c:
PL_envgv= gv_dup(proto_perl->Ienvgv, param);
is the line inside perl_clone_using() from which PerlIO_debug() gets
called, but PL_tainting isn't set until line 11498:
PL_tainting= proto_perl->Itainting;
The patch below fixes it, and all tests still pass. Is it OK?
//depot/perl/sv.c#951 - C:\p5p\bleadperl\sv.c
@@ -11374,6 +11374,10 @@
param->stashes = newAV(); /* Setup array of objects to call
clone on
*/
+/* Set tainting stuff before PerlIO_debug can possibly get called */
+PL_tainting= proto_perl->Itainting;
+PL_taint_warn = proto_perl->Itaint_warn;
+
#ifdef PERLIO_LAYERS
/* Clone PerlIO tables as soon as we can handle general xx_dup() */
PerlIO_clone(aTHX_ proto_perl, param);
@@ -11495,8 +11499,6 @@
PL_fdpid = av_dup_inc(proto_perl->Ifdpid, param);
/* internal state */
-PL_tainting= proto_perl->Itainting;
-PL_taint_warn = proto_perl->Itaint_warn;
PL_maxo= proto_perl->Imaxo;
if (proto_perl->Iop_mask)
PL_op_mask = SAVEPVN(proto_perl->Iop_mask, PL_maxo);
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should
check it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
Re: Scalar leaked in 'local $0' under ithreads + taint mode
On Fri, Jul 08, 2005 at 09:36:19AM +0100, Steve Hay wrote:
> The crash is deliberately forced by win32_checkTLS(), but I don't
> understand for what reason. PerlEnvGetenv() takes an IPerlEnv* and uses
> the IPERL2HOST() macro (which is set to IPerlEnv2Host()) to locate the
> CPerlHost* which that IPerlEnv* is a member of. It then calls
> win32_checkTLS() to check that the host_perl in the CPerlHost* that has
> been found is my_perl. Evidently, in this case host_perl != my_perl, so
> it bombs out.
>
> Does anyone know what this my_perl is? What is the purpose of the
> host_perl != my_perl check, and why might it be failing?
my_perl is a pointer to the current perl interpreter; in a threaded build,
it's normally passed as an extra 1st arg to most functions (that's what all
the pTHX/aTHX stuff is for); functions that don't get it passed can
have 'dTHX;' at their start, which declares my_perl and determines it from
thread-local storage (this is slow).
win32_checkTLS() appears to be sanity checking that the passed host_perl is
the same as the my_perl determined by dTHX; since is this happening during the
middle of cloning, this isn't likely to be the case.
The real question is why is PerlIO_debug() getting called for the first time
during cloning? On my system, it's getting called much earlier, during
perl_parse(). A second possibility is that it's not being called for the
first time, but that in this code:
PerlIO_debug(const char *fmt, ...)
{
va_list ap;
dSYS;
va_start(ap, fmt);
if (!PL_perlio_debug_fd && !PL_tainting && PL_uid == PL_euid && PL_gid
== PL_egid) {
const char *s = PerlEnv_getenv("PERLIO_DEBUG");
if (s && *s)
PL_perlio_debug_fd = PerlLIO_open3(s, O_WRONLY | O_CREAT |
O_APPEND, 0666);
else
PL_perlio_debug_fd = -1;
for some reason PerlLIO_open3() is setting PL_perlio_debug_fd to 0, so
that each time PerlIO_debug is called, it will still do a
PerlEnv_getenv("PERLIO_DEBUG"). Perhaps?
Can you detemine when PerlIO_debug() is being called, and if whether it's
calling PerlLIO_open3() and whether that's rturning 0?
--
The perl5 internals are a complete mess. It's like Jenga - to get the
perl5 tower taller and do something new you select a block somewhere in
the middle, with trepidation pull it out slowly, and then carefully
balance it somewhere new, hoping the whole edifice won't collapse as a
result.
- Nicholas Clark, based on an original by Simon Cozens.
Re: Scalar leaked in 'local $0' under ithreads + taint mode
Dave Mitchell wrote: >On Thu, Jul 07, 2005 at 01:56:39PM +0100, Steve Hay wrote: > > >>Hmm. I just retried this with current blead and I find that it >>(apparently) works OK with a debug build, but crashes with a release build. >> >> > >I can't get it to crash on either type of build (Linux). > > :-( >>Fortunately, release builds on Win32 have debugging symbols anyway >>(since they are stored in separate files), so I am able to get a stack >>trace: >> >>win32_checkTLS(interpreter * 0x73204441) line 57 >>PerlEnvGetenv(IPerlEnv * 0x01857670, const char * 0x280b79b8 `string') >>line 454 + 19 bytes >>PerlIO_debug(const char * 0x280b79e0 `string') line 461 + 14 bytes >>PerlIO_clone(interpreter * 0x018b2ad4, interpreter * 0x00234494, >>clone_params * 0x0140fc80) line 643 >>perl_clone_using(interpreter * 0x00234494, unsigned long 6, IPerlMem * >>0x0185761c, IPerlMem * 0x01857638, IPerlMem * 0x01857654, IPerlEnv * >>0x01857670, IPerlStdIO * 0x018576a8, IPerlLIO * 0x01857744, IPerlDir * >>0x018577ac, IPerlSock * 0x018577d8, IPerlProc * 0x01857888) line 11383 >>perl_clone_host(interpreter * 0x00234494, unsigned long 6) line 315 + 67 >>bytes >>perl_clone(interpreter * 0x00234494, unsigned long 6) line 11183 + 11 bytes >>Perl_ithread_create(interpreter * 0x, sv * 0x, char * >>0x018325e4, sv * 0x002354cc, sv * 0x01828c64) line 424 + 8 bytes >>XS_threads_new(interpreter * 0x0002, cv * 0x018a83f4) line 687 + 32 >>bytes >>Perl_pp_entersub(interpreter * 0x01234494) line 2789 >>Perl_runops_standard(interpreter * 0x00234494) line 38 + 45 bytes >>S_run_body(interpreter * 0x00234494, long 1) line 2231 + 10 bytes >>perl_run(interpreter * 0x00234494) line 2160 + 10 bytes >>RunPerl(int 3, char * * 0x00232440, char * * 0x00232d08) line 217 + 6 bytes >>PERL! mainCRTStartup + 227 bytes >>KERNEL32! 77e8141a() >> >> > >threads->new() tries to clone an intepreter; this calls PerlIO_clone(), >which calls PerlIO_debug(), which tries to get the value (if any) of >the env var PERLIO_DEBUG. At this point it jumps into windows-specific >code, where it then crashes. > >Does it still fail after change 25094? I'm pretty much clutching at straws >here, but that does hapen to fix an unrelated bug associated with doing >'local $0' > No, it still crashes with much the same stack trace. The crash is deliberately forced by win32_checkTLS(), but I don't understand for what reason. PerlEnvGetenv() takes an IPerlEnv* and uses the IPERL2HOST() macro (which is set to IPerlEnv2Host()) to locate the CPerlHost* which that IPerlEnv* is a member of. It then calls win32_checkTLS() to check that the host_perl in the CPerlHost* that has been found is my_perl. Evidently, in this case host_perl != my_perl, so it bombs out. Does anyone know what this my_perl is? What is the purpose of the host_perl != my_perl check, and why might it be failing? Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: Scalar leaked in 'local $0' under ithreads + taint mode
On Thu, Jul 07, 2005 at 01:56:39PM +0100, Steve Hay wrote: > Hmm. I just retried this with current blead and I find that it > (apparently) works OK with a debug build, but crashes with a release build. I can't get it to crash on either type of build (Linux). > > Fortunately, release builds on Win32 have debugging symbols anyway > (since they are stored in separate files), so I am able to get a stack > trace: > > win32_checkTLS(interpreter * 0x73204441) line 57 > PerlEnvGetenv(IPerlEnv * 0x01857670, const char * 0x280b79b8 `string') > line 454 + 19 bytes > PerlIO_debug(const char * 0x280b79e0 `string') line 461 + 14 bytes > PerlIO_clone(interpreter * 0x018b2ad4, interpreter * 0x00234494, > clone_params * 0x0140fc80) line 643 > perl_clone_using(interpreter * 0x00234494, unsigned long 6, IPerlMem * > 0x0185761c, IPerlMem * 0x01857638, IPerlMem * 0x01857654, IPerlEnv * > 0x01857670, IPerlStdIO * 0x018576a8, IPerlLIO * 0x01857744, IPerlDir * > 0x018577ac, IPerlSock * 0x018577d8, IPerlProc * 0x01857888) line 11383 > perl_clone_host(interpreter * 0x00234494, unsigned long 6) line 315 + 67 > bytes > perl_clone(interpreter * 0x00234494, unsigned long 6) line 11183 + 11 bytes > Perl_ithread_create(interpreter * 0x, sv * 0x, char * > 0x018325e4, sv * 0x002354cc, sv * 0x01828c64) line 424 + 8 bytes > XS_threads_new(interpreter * 0x0002, cv * 0x018a83f4) line 687 + 32 > bytes > Perl_pp_entersub(interpreter * 0x01234494) line 2789 > Perl_runops_standard(interpreter * 0x00234494) line 38 + 45 bytes > S_run_body(interpreter * 0x00234494, long 1) line 2231 + 10 bytes > perl_run(interpreter * 0x00234494) line 2160 + 10 bytes > RunPerl(int 3, char * * 0x00232440, char * * 0x00232d08) line 217 + 6 bytes > PERL! mainCRTStartup + 227 bytes > KERNEL32! 77e8141a() threads->new() tries to clone an intepreter; this calls PerlIO_clone(), which calls PerlIO_debug(), which tries to get the value (if any) of the env var PERLIO_DEBUG. At this point it jumps into windows-specific code, where it then crashes. Does it still fail after change 25094? I'm pretty much clutching at straws here, but that does hapen to fix an unrelated bug associated with doing 'local $0' -- "Strange women lying in ponds distributing swords is no basis for a system of government. Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony." -- Dennis - Monty Python and the Holy Grail.
Re: Scalar leaked in 'local $0' under ithreads + taint mode
Dave Mitchell wrote:
>On Thu, Feb 24, 2005 at 01:32:25PM +, Steve Hay wrote:
>
>
>>Stas Bekman wrote:
>>
>>
>>
>>>The following scalar leak is reproduced under any perl 5.8+ w/ithreads:
>>>
>>>#!/usr/bin/perl -T
>>>use Devel::Peek;
>>>use threads;
>>>
>>>local $0 = "test"; # <== XXX: leaks scalar
>>>my $thr = threads->new(sub { Dump $0 });
>>>$thr->join;# <== XXX: triggers the leak
>>>
>>>[...]
>>>Scalars leaked: 1
>>>leaked: sv=0x816dc1c flags=0x084046007 refcnt=0, Perl interpreter: 0x8102770
>>>
>>>As the dump shows that leaked scalar is MG_OBJ = 0x816dc1c. This magic
>>>object is a taint magic (and it happens under -T).
>>>
>>>
>>>
>>Is this anything to do with the following comment found in
>>scope.c::S_save_scalar_at()
>>
>>/* XXX SvMAGIC() is *shared* between osv and sv. This can
>> * lead to coredumps when both SVs are destroyed without one
>> * of their SvMAGIC() slots being NULLed. */
>>
>>
>
>Looks like the leak has been fixed by my change #24942, which fixed
>local() and magic (and specifically removed the code related to that XXX
>comment above)
>
Hmm. I just retried this with current blead and I find that it
(apparently) works OK with a debug build, but crashes with a release build.
Fortunately, release builds on Win32 have debugging symbols anyway
(since they are stored in separate files), so I am able to get a stack
trace:
win32_checkTLS(interpreter * 0x73204441) line 57
PerlEnvGetenv(IPerlEnv * 0x01857670, const char * 0x280b79b8 `string')
line 454 + 19 bytes
PerlIO_debug(const char * 0x280b79e0 `string') line 461 + 14 bytes
PerlIO_clone(interpreter * 0x018b2ad4, interpreter * 0x00234494,
clone_params * 0x0140fc80) line 643
perl_clone_using(interpreter * 0x00234494, unsigned long 6, IPerlMem *
0x0185761c, IPerlMem * 0x01857638, IPerlMem * 0x01857654, IPerlEnv *
0x01857670, IPerlStdIO * 0x018576a8, IPerlLIO * 0x01857744, IPerlDir *
0x018577ac, IPerlSock * 0x018577d8, IPerlProc * 0x01857888) line 11383
perl_clone_host(interpreter * 0x00234494, unsigned long 6) line 315 + 67
bytes
perl_clone(interpreter * 0x00234494, unsigned long 6) line 11183 + 11 bytes
Perl_ithread_create(interpreter * 0x, sv * 0x, char *
0x018325e4, sv * 0x002354cc, sv * 0x01828c64) line 424 + 8 bytes
XS_threads_new(interpreter * 0x0002, cv * 0x018a83f4) line 687 + 32
bytes
Perl_pp_entersub(interpreter * 0x01234494) line 2789
Perl_runops_standard(interpreter * 0x00234494) line 38 + 45 bytes
S_run_body(interpreter * 0x00234494, long 1) line 2231 + 10 bytes
perl_run(interpreter * 0x00234494) line 2160 + 10 bytes
RunPerl(int 3, char * * 0x00232440, char * * 0x00232d08) line 217 + 6 bytes
PERL! mainCRTStartup + 227 bytes
KERNEL32! 77e8141a()
Do you guys get a similar effect with release vs debug builds?
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should
check it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
Re: Scalar leaked in 'local $0' under ithreads + taint mode
On Thu, Feb 24, 2005 at 01:32:25PM +, Steve Hay wrote:
> Stas Bekman wrote:
>
> >The following scalar leak is reproduced under any perl 5.8+ w/ithreads:
> >
> >#!/usr/bin/perl -T
> >use Devel::Peek;
> >use threads;
> >
> >local $0 = "test"; # <== XXX: leaks scalar
> >my $thr = threads->new(sub { Dump $0 });
> >$thr->join;# <== XXX: triggers the leak
> >
> >[...]
> >Scalars leaked: 1
> >leaked: sv=0x816dc1c flags=0x084046007 refcnt=0, Perl interpreter: 0x8102770
> >
> >As the dump shows that leaked scalar is MG_OBJ = 0x816dc1c. This magic
> >object is a taint magic (and it happens under -T).
> >
> Is this anything to do with the following comment found in
> scope.c::S_save_scalar_at()
>
> /* XXX SvMAGIC() is *shared* between osv and sv. This can
> * lead to coredumps when both SVs are destroyed without one
> * of their SvMAGIC() slots being NULLed. */
Looks like the leak has been fixed by my change #24942, which fixed
local() and magic (and specifically removed the code related to that XXX
comment above)
--
"Do not dabble in paradox, Edward, it puts you in danger of fortuitous
wit." -- Lady Croom - Arcadia
Re: [perl #34341] Scalar leaked in 'local $0' under ithreads + taint mode
(resubmitting Steve Hay's followup so it'll be stored in rt)
Stas Bekman (via RT) wrote:
# New Ticket Created by Stas Bekman
# Please include the string: [perl #34341]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=34341 >
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.8.6.
-
[Please enter your report here]
The following scalar leak is reproduced under any perl 5.8+ w/ithreads:
#!/usr/bin/perl -T
use Devel::Peek;
use threads;
local $0 = "test"; # <== XXX: leaks scalar
my $thr = threads->new(sub { Dump $0 });
$thr->join;# <== XXX: triggers the leak
[...]
Scalars leaked: 1
leaked: sv=0x816dc1c flags=0x084046007 refcnt=0, Perl interpreter:
0x8102770
As the dump shows that leaked scalar is MG_OBJ = 0x816dc1c. This magic
object is a taint magic (and it happens under -T).
From: Steve Hay <[EMAIL PROTECTED]>
Is this anything to do with the following comment found in
scope.c::S_save_scalar_at()
/* XXX SvMAGIC() is *shared* between osv and sv. This can
* lead to coredumps when both SVs are destroyed without one
* of their SvMAGIC() slots being NULLed. */
There's certiainly some stuff to do with taint magic and localizing
going on in that function, so since that's what this particular problem
revolves around, maybe its worth a closer look by someone that
understands it?
I'm not sure what the following chunk from that function is trying to
achieve:
if (PL_tainting && PL_tainted &&
(mg = mg_find(osv, PERL_MAGIC_taint))) {
SAVESPTR(mg->mg_obj);
mg->mg_obj = osv;
}
but could it be related to the leaked MG_OBJ?
- Steve
[perl #34341] Scalar leaked in 'local $0' under ithreads + taint mode
# New Ticket Created by Stas Bekman
# Please include the string: [perl #34341]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=34341 >
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.8.6.
-
[Please enter your report here]
The following scalar leak is reproduced under any perl 5.8+ w/ithreads:
#!/usr/bin/perl -T
use Devel::Peek;
use threads;
local $0 = "test"; # <== XXX: leaks scalar
my $thr = threads->new(sub { Dump $0 });
$thr->join;# <== XXX: triggers the leak
% perl -T leak.pl
SV = PVMG(0x81129a0) at 0x816dc10
REFCNT = 1
FLAGS = (GMG,SMG,pPOK)
IV = 0
NV = 0
PV = 0x816e370 "test"\0
CUR = 4
LEN = 5
MAGIC = 0x816e2a8
MG_VIRTUAL = &PL_vtbl_sv
MG_TYPE = PERL_MAGIC_sv(\0)
MG_OBJ = 0x816dc04
MG_LEN = 1
MG_PTR = 0x816e2c8 "0"
MAGIC = 0x816e2d8
MG_VIRTUAL = &PL_vtbl_taint
MG_TYPE = PERL_MAGIC_taint(t)
MG_OBJ = 0x816dc1c
MG_LEN = 2
Scalars leaked: 1
leaked: sv=0x816dc1c flags=0x084046007 refcnt=0, Perl interpreter:
0x8102770
As the dump shows that leaked scalar is MG_OBJ = 0x816dc1c. This magic
object is a taint magic (and it happens under -T).
It happens so that ModPerl::Registry localizes $0, so anybody trying to
spawn a thread is going to get this leak. There are probably other cases
where this happens in the same way, but at the moment I've only one *easy*
testcase.
[Please do not change anything below this line]
-
---
Flags:
category=core
severity=medium
---
Site configuration information for perl v5.8.6:
Configured by stas at Thu Mar 3 21:57:12 EST 2005.
Summary of my perl5 (revision 5 version 8 subversion 6) configuration:
Platform:
osname=linux, osvers=2.6.8.1-12mdk, archname=i686-linux-thread-multi
uname='linux rabbit.stason.org 2.6.8.1-12mdk #1 fri oct 1 12:53:41
cest 2004 i686 mobile intel(r) pentium(r) 4 - m cpu 2.00ghz unknown gnulinux '
config_args='-des -Dprefix=/home/stas/perl/5.8.7-ithread -Dusethreads
-Doptimize=-g -Duseshrplib -Dusedevel -Accflags=-DDEBUG_LEAKING_SCALARS'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DDEBUG_LEAKING_SCALARS -DDEBUGGING -fno-strict-aliasing -pipe
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/include/gdbm',
optimize='-g',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DDEBUG_LEAKING_SCALARS -DDEBUGGING -fno-strict-aliasing -pipe
-I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=/lib/libc-2.3.3.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.3'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E
-Wl,-rpath,/home/stas/perl/5.8.7-ithread/lib/5.8.6/i686-linux-thread-multi/CORE'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Locally applied patches:
MAINT23940
---
@INC for perl v5.8.6:
/home/stas/perl/5.8.7-ithread/lib/5.8.6/i686-linux-thread-multi
/home/stas/perl/5.8.7-ithread/lib/5.8.6
/home/stas/perl/5.8.7-ithread/lib/site_perl/5.8.6/i686-linux-thread-multi
/home/stas/perl/5.8.7-ithread/lib/site_perl/5.8.6
/home/stas/perl/5.8.7-ithread/lib/site_perl
.
---
Environment for perl v5.8.6:
HOME=/home/stas
LANG=en_GB
LANGUAGE=en_GB:en
LC_ADDRESS=en_CA
LC_COLLATE=en_GB
LC_CTYPE=en_GB
LC_IDENTIFICATION=en_CA
LC_MEASUREMENT=en_CA
LC_MESSAGES=en_GB
LC_MONETARY=en_CA
LC_NAME=en_CA
LC_NUMERIC=en_CA
LC_PAPER=en_CA
LC_SOURCED=1
LC_TELEPHONE=en_CA
LC_TIME=en_GB
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/usr//bin:/bin:/usr/bin:.:/usr/local/bin:/usr/X11R6/bin/:/usr/games:/home/stas/bin:/home/stas/bin:/usr/local/bin:/usr/X11R6/bin:/usr/java/j2re1.4.0/bin/
PERLDOC_PAGER=less -R
PERL_BADLANG (unset)
SHELL=
Re: Scalar leaked in 'local $0' under ithreads + taint mode
Stas Bekman wrote:
>The following scalar leak is reproduced under any perl 5.8+ w/ithreads:
>
>#!/usr/bin/perl -T
>use Devel::Peek;
>use threads;
>
>local $0 = "test"; # <== XXX: leaks scalar
>my $thr = threads->new(sub { Dump $0 });
>$thr->join;# <== XXX: triggers the leak
>
>[...]
>Scalars leaked: 1
>leaked: sv=0x816dc1c flags=0x084046007 refcnt=0, Perl interpreter: 0x8102770
>
>As the dump shows that leaked scalar is MG_OBJ = 0x816dc1c. This magic
>object is a taint magic (and it happens under -T).
>
Is this anything to do with the following comment found in
scope.c::S_save_scalar_at()
/* XXX SvMAGIC() is *shared* between osv and sv. This can
* lead to coredumps when both SVs are destroyed without one
* of their SvMAGIC() slots being NULLed. */
There's certiainly some stuff to do with taint magic and localizing
going on in that function, so since that's what this particular problem
revolves around, maybe its worth a closer look by someone that
understands it?
I'm not sure what the following chunk from that function is trying to
achieve:
if (PL_tainting && PL_tainted &&
(mg = mg_find(osv, PERL_MAGIC_taint))) {
SAVESPTR(mg->mg_obj);
mg->mg_obj = osv;
}
but could it be related to the leaked MG_OBJ?
- Steve
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should
check it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
Scalar leaked in 'local $0' under ithreads + taint mode
The following scalar leak is reproduced under any perl 5.8+ w/ithreads:
#!/usr/bin/perl -T
use Devel::Peek;
use threads;
local $0 = "test"; # <== XXX: leaks scalar
my $thr = threads->new(sub { Dump $0 });
$thr->join;# <== XXX: triggers the leak
% perl -T leak.pl
SV = PVMG(0x81129a0) at 0x816dc10
REFCNT = 1
FLAGS = (GMG,SMG,pPOK)
IV = 0
NV = 0
PV = 0x816e370 "test"\0
CUR = 4
LEN = 5
MAGIC = 0x816e2a8
MG_VIRTUAL = &PL_vtbl_sv
MG_TYPE = PERL_MAGIC_sv(\0)
MG_OBJ = 0x816dc04
MG_LEN = 1
MG_PTR = 0x816e2c8 "0"
MAGIC = 0x816e2d8
MG_VIRTUAL = &PL_vtbl_taint
MG_TYPE = PERL_MAGIC_taint(t)
MG_OBJ = 0x816dc1c
MG_LEN = 2
Scalars leaked: 1
leaked: sv=0x816dc1c flags=0x084046007 refcnt=0, Perl interpreter: 0x8102770
As the dump shows that leaked scalar is MG_OBJ = 0x816dc1c. This magic
object is a taint magic (and it happens under -T).
It happens so that ModPerl::Registry localizes $0, so anybody trying to
spawn a thread is going to get this leak. There are probably other cases
where this happens in the same way, but at the moment I've only one *easy*
testcase.
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
