Skip Menu |
Report information
Id: 121676
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: bulk88 <bulk88 [at] hotmail.com>
Cc:
AdminCc:

Operating System: mswin32
PatchStatus: (no value)
Severity: low
Type: core
Perl Version: 5.19.10
Fixed In: (no value)



Subject: Memory leak in backticks and system
Date: Thu, 17 Apr 2014 02:36:52 -0400
To: perlbug [...] perl.org
From: bulk88 <bulk88 [...] hotmail.com>
Download (untitled) / with headers
text/plain 3.5k
This is a bug report for perl from bulk88@hotmail.com, generated with the help of perlbug 1.40 running under perl 5.19.10. ----------------------------------------------------------------- [Please describe your issue here] There is a mem leak in system and `` on Win32 on 5.19 and 5.18 (tested by me and others), see https://rt.cpan.org/Public/Bug/Display.html?id=94138 and http://www.nntp.perl.org/group/perl.perl5.porters/2014/04/msg214390.html . This ticket is so the issue doesnt get lost. [Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=core severity=low --- Site configuration information for perl 5.19.10: Configured by Owner at Sat Mar 15 22:30:42 2014. Summary of my perl5 (revision 5 version 19 subversion 10) configuration: Derived from: 2179658b5e799a6e3c4e736ec7c84b0f50bf3473 Ancestor: e9251c1a8f4944e6dceff5240d9e109ba075ff29 Platform: osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cl', ccflags ='-nologo -GF -W3 -O1 -MD -Zi -DNDEBUG -G7 -GL -DWIN32 -D_CONSOLE -DNO_STRICT -DPERL_TEXTMODE_SCRIPTS -DPERL_HASH_FUNC_ONE_AT_A_TIME -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D_USE_32BIT_TIME_T', optimize='-O1 -MD -Zi -DNDEBUG -G7 -GL', cppflags='-DWIN32' ccversion='13.10.6030', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -ltcg -libpath:"c:\perl519\lib\CORE" -machine:x86' libpth="C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\lib" libs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib perllibs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl519.lib gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf -ltcg -libpath:"c:\perl519\lib\CORE" -machine:x86' Locally applied patches: uncommitted-changes 2179658b5e799a6e3c4e736ec7c84b0f50bf3473 --- @INC for perl 5.19.10: C:/perl519/site/lib C:/perl519/lib . --- Environment for perl 5.19.10: HOME (unset) LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=C:\perl519\bin;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE;C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\BIN;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\bin\prerelease;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem; PERL_BADLANG (unset) SHELL (unset)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 925b
On Wed Apr 16 23:37:39 2014, bulk88 wrote: Show quoted text
> There is a mem leak in system and `` on Win32 on 5.19 and 5.18 (tested > by me and others), see > https://rt.cpan.org/Public/Bug/Display.html?id=94138 and > http://www.nntp.perl.org/group/perl.perl5.porters/2014/04/msg214390.html > . This ticket is so the issue doesnt get lost.
I tried to fudge the build (and added some extra code) to build perl with MSVCRT's debug version memory leak reporting[1], which reported only a single leak, which appears with perl -e0 or perl -e "`dir` for 1..100`". I don't see a leak if I build perl with PERL_MALLOC defined (which requires disabling USE_IMP_SYS). I don't see a leak with all of PERL_MALLOC, USE_MULTI, USE_ITHREADS, USE_IMP_SYS undefined. No leak with just USE_MULTI re-enabled out of those. Right now I suspect something in the USE_IMP_SYS layer. Tony [1] http://msdn.microsoft.com/en-us/library/e5ewb1h3%28v=vs.90%29.aspx
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.2k
On Mon Apr 21 23:33:16 2014, tonyc wrote: Show quoted text
> I tried to fudge the build (and added some extra code) to build perl > with MSVCRT's debug version memory leak reporting[1], which reported > only a single leak, which appears with perl -e0 or perl -e "`dir` for > 1..100`". >
I've never used debugging CRT with Perl. Its on my very long todo list. Since you got it to compile, may I suggest you implement the feature in the makefiles? I've always thought that PERL_DESTRUT_LEVEL and debugging CRT would conflict since perl doesn't free all memory on normal exists unless psuedo-fork has been called which sets PERL_DESTRUCT_LEVEL. Show quoted text
> I don't see a leak if I build perl with PERL_MALLOC defined (which > requires disabling USE_IMP_SYS). > > I don't see a leak with all of PERL_MALLOC, USE_MULTI, USE_ITHREADS, > USE_IMP_SYS undefined. > > No leak with just USE_MULTI re-enabled out of those. > > Right now I suspect something in the USE_IMP_SYS layer. >
Did you see the leak in any config? I saw some strange reproducibility which had no identifyable pattern, since it wasn't tied to CRT dll or compiler, in http://www.nntp.perl.org/group/perl.perl5.porters/2014/04/msg214405.html . The leak can be clearly seen in Task Manager. Its about 200-300 KB a second/a screen refresh in task manager. -- bulk88 ~ bulk88 at hotmail.com
From: Tony Cook <tony [...] develop-help.com>
Date: Wed, 23 Apr 2014 00:01:35 +1000
To: bulk88 via RT <perlbug-followup [...] perl.org>
Subject: Re: [perl #121676] Memory leak in backticks and system
CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.7k
On Tue, Apr 22, 2014 at 04:41:00AM -0700, bulk88 via RT wrote: Show quoted text
> On Mon Apr 21 23:33:16 2014, tonyc wrote:
> > I tried to fudge the build (and added some extra code) to build perl > > with MSVCRT's debug version memory leak reporting[1], which reported > > only a single leak, which appears with perl -e0 or perl -e "`dir` for > > 1..100`". > >
> > I've never used debugging CRT with Perl. Its on my very long todo list. Since you got it to compile, may I suggest you implement the feature in the makefiles?
I had to fiddle with the source a bit, the macro in perl.h: #define CALLREGFREE_PVT(prog) \ if(prog) RX_ENGINE(prog)->free(aTHX_ (prog)) fails pretty hard when the CRT defines a free() macro. Also, I could only get the results to show in the debugger, not on the console. Show quoted text
> I've always thought that PERL_DESTRUT_LEVEL and debugging CRT would conflict since perl doesn't free all memory on normal exists unless psuedo-fork has been called which sets PERL_DESTRUCT_LEVEL.
You can build a -DDEBUGGING perl and set PERL_DESTRUCT_LEVEL=2 in the environment. Show quoted text
> > I don't see a leak if I build perl with PERL_MALLOC defined (which > > requires disabling USE_IMP_SYS). > > > > I don't see a leak with all of PERL_MALLOC, USE_MULTI, USE_ITHREADS, > > USE_IMP_SYS undefined. > > > > No leak with just USE_MULTI re-enabled out of those. > > > > Right now I suspect something in the USE_IMP_SYS layer. > >
> > Did you see the leak in any config? I saw some strange reproducibility which had no identifyable pattern, since it wasn't tied to CRT dll or compiler, in http://www.nntp.perl.org/group/perl.perl5.porters/2014/04/msg214405.html . The leak can be clearly seen in Task Manager. Its about 200-300 KB a second/a screen refresh in task manager.
A USE_IMP_SYS build did leak. Tony
CC: bulk88 via RT <perlbug-followup [...] perl.org>, "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
Subject: Re: [perl #121676] Memory leak in backticks and system
To: Tony Cook <tony [...] develop-help.com>
Date: Tue, 22 Apr 2014 20:33:33 +0100
From: Steve Hay <steve.m.hay [...] googlemail.com>
Download (untitled) / with headers
text/plain 1.4k
On 22 April 2014 15:01, Tony Cook <tony@develop-help.com> wrote: Show quoted text
> On Tue, Apr 22, 2014 at 04:41:00AM -0700, bulk88 via RT wrote:
>> On Mon Apr 21 23:33:16 2014, tonyc wrote:
>> > I tried to fudge the build (and added some extra code) to build perl >> > with MSVCRT's debug version memory leak reporting[1], which reported >> > only a single leak, which appears with perl -e0 or perl -e "`dir` for >> > 1..100`". >> >
>> >> I've never used debugging CRT with Perl. Its on my very long todo list. Since you got it to compile, may I suggest you implement the feature in the makefiles?
> > I had to fiddle with the source a bit, the macro in perl.h: > > #define CALLREGFREE_PVT(prog) \ > if(prog) RX_ENGINE(prog)->free(aTHX_ (prog)) > > fails pretty hard when the CRT defines a free() macro. > > Also, I could only get the results to show in the debugger, not on the > console. >
I had a crack at using the debug CRT a year or more ago and ran into the free() problem too, and also trouble with the invalid parameter handler choking on filehandles getting closed when they are already closed. I have it on my TODO list to revisit this and get it working too; maybe the three of us can finally get somewhere with it after 5.20 is out?! FWIW, here's the patch that I was playing with last. It's well over a year out of date, but I'm sure it could still be manually applied if all else fails. (Sorry, it's also git diff style again. I've not forgotten to avoid this in the future...)
Download debug.patch
text/plain 3.8k

Message body is not shown because sender requested not to inline it.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 724b
On Wed Apr 16 23:37:39 2014, bulk88 wrote: Show quoted text
> There is a mem leak in system and `` on Win32 on 5.19 and 5.18 (tested > by me and others), see > https://rt.cpan.org/Public/Bug/Display.html?id=94138 and > http://www.nntp.perl.org/group/perl.perl5.porters/2014/04/msg214390.html > . This ticket is so the issue doesnt get lost. >
Isolated to --------------------------------- C:\Documents and Settings\Administrator\Desktop\lxs\Local-XS>perl -MLocal::XS - e"while(1){Local::XS::runleak2()}" --------------------------------- void runleak2() CODE: void* env; env = PerlEnv_get_childenv(); PerlEnv_free_childenv(env); --------------------------------- eats 100 MB of mem a sec. -- bulk88 ~ bulk88 at hotmail.com
From: Steve Hay <Steve.Hay [...] verosoftware.com>
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
Date: Tue, 13 May 2014 11:15:21 +0000
CC: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
Subject: RE: [perl #121676] Memory leak in backticks and system
Download (untitled) / with headers
text/plain 1.1k
Show quoted text
> -----Original Message----- > From: bulk88 via RT [mailto:perlbug-followup@perl.org] > Sent: 13 May 2014 12:03 > Cc: perl5-porters@perl.org > Subject: [perl #121676] Memory leak in backticks and system > > On Wed Apr 16 23:37:39 2014, bulk88 wrote:
> > There is a mem leak in system and `` on Win32 on 5.19 and 5.18
> (tested
> > by me and others), see > > https://rt.cpan.org/Public/Bug/Display.html?id=94138 and > >
> http://www.nntp.perl.org/group/perl.perl5.porters/2014/04/msg214390.ht
> > ml . This ticket is so the issue doesnt get lost. > >
> > Isolated to > > --------------------------------- > C:\Documents and Settings\Administrator\Desktop\lxs\Local-XS>perl - > MLocal::XS - e"while(1){Local::XS::runleak2()}" > --------------------------------- > void > runleak2() > CODE: > void* env; > env = PerlEnv_get_childenv(); > PerlEnv_free_childenv(env); > --------------------------------- > > eats 100 MB of mem a sec. >
At a quick look win32_freeenvironmentstrings appears to be missing a FreeEnvironmentStrings() for the GetEnvironmentStringsW() in win32_getenvironmentstrings()? (win32_freeenvironmentstrings() only win32_free()s what was win32_calloc()ed...)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.1k
On Tue May 13 04:02:44 2014, bulk88 wrote: Show quoted text
> On Wed Apr 16 23:37:39 2014, bulk88 wrote:
> > There is a mem leak in system and `` on Win32 on 5.19 and 5.18 > > (tested > > by me and others), see > > https://rt.cpan.org/Public/Bug/Display.html?id=94138 and > > http://www.nntp.perl.org/group/perl.perl5.porters/2014/04/msg214390.html > > . This ticket is so the issue doesnt get lost. > >
> > Isolated to > > --------------------------------- > C:\Documents and Settings\Administrator\Desktop\lxs\Local-XS>perl > -MLocal::XS - > e"while(1){Local::XS::runleak2()}" > --------------------------------- > void > runleak2() > CODE: > void* env; > env = PerlEnv_get_childenv(); > PerlEnv_free_childenv(env); > --------------------------------- > > eats 100 MB of mem a sec.
win32_getenvironmentstrings in win32.c is probably missing a call to FreeEnvironmentStrings. The leak probably started in http://perl5.git.perl.org/perl.git/commit/4f46e52b008bf955ea3049ad2dc4bfe468842f06 from 5.17.0-1, so that means a 5.18 backport is needed, see also the ticket for that commit at https://rt.perl.org/Ticket/Display.html?id=113536 . -- bulk88 ~ bulk88 at hotmail.com
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 3.3k
The reason it didn't leak on my winxp 32 bit machine is, for that machine, GetEnvironmentStringsW doesn't really allocate anything ------------------------------------- _GetEnvironmentStringsW@0: 7C812FA8 64 A1 18 00 00 00 mov eax,dword ptr fs:[00000018h] 7C812FAE 8B 40 30 mov eax,dword ptr [eax+30h] 7C812FB1 8B 40 10 mov eax,dword ptr [eax+10h] 7C812FB4 8B 40 48 mov eax,dword ptr [eax+48h] 7C812FB7 C3 ret ------------------------------------- on Server 2003 x64, with a 32 bit Perl, notice the call to RtlAllocateHeap ------------------------------------- 7D4DF986 64 A1 18 00 00 00 mov eax,dword ptr fs:[00000018h] 7D4DF98C 8B 40 30 mov eax,dword ptr [eax+30h] 7D4DF98F 53 push ebx 7D4DF990 56 push esi 7D4DF991 8B 70 10 mov esi,dword ptr [eax+10h] 7D4DF994 57 push edi 7D4DF995 FF 15 C0 00 4D 7D call dword ptr [__imp__RtlAcquirePebLock@0 (7D4D00C0h)] 7D4DF99B 8B 7E 48 mov edi,dword ptr [esi+48h] 7D4DF99E 8B F7 mov esi,edi 7D4DF9A0 57 push edi 7D4DF9A1 E8 C4 95 FF FF call _wcslen (7D4D8F6Ah) 7D4DF9A6 8D 7C 47 02 lea edi,[edi+eax*2+2] 7D4DF9AA 66 83 3F 00 cmp word ptr [edi],0 7D4DF9AE 59 pop ecx 7D4DF9AF 75 EF jne _GetEnvironmentStringsW@0+1Ah (7D4DF9A0h) 7D4DF9B1 8B 0D 5C 06 56 7D mov ecx,dword ptr [_BaseDllTag (7D56065Ch)] 7D4DF9B7 64 A1 18 00 00 00 mov eax,dword ptr fs:[00000018h] 7D4DF9BD 8B 40 30 mov eax,dword ptr [eax+30h] 7D4DF9C0 2B FE sub edi,esi 7D4DF9C2 47 inc edi 7D4DF9C3 47 inc edi 7D4DF9C4 57 push edi 7D4DF9C5 81 C1 00 00 18 00 add ecx,180000h 7D4DF9CB 51 push ecx 7D4DF9CC FF 70 18 push dword ptr [eax+18h] 7D4DF9CF FF 15 0C 00 4D 7D call dword ptr [__imp__RtlAllocateHeap@12 (7D4D000Ch)] 7D4DF9D5 8B D8 mov ebx,eax 7D4DF9D7 85 DB test ebx,ebx 7D4DF9D9 0F 84 68 02 03 00 je _GetEnvironmentStringsW@0+55h (7D50FC47h) 7D4DF9DF 8B CF mov ecx,edi 7D4DF9E1 8B C1 mov eax,ecx 7D4DF9E3 C1 E9 02 shr ecx,2 7D4DF9E6 8B FB mov edi,ebx 7D4DF9E8 F3 A5 rep movs dword ptr es:[edi],dword ptr [esi] 7D4DF9EA 8B C8 mov ecx,eax 7D4DF9EC 83 E1 03 and ecx,3 7D4DF9EF F3 A4 rep movs byte ptr es:[edi],byte ptr [esi] 7D4DF9F1 FF 15 B8 00 4D 7D call dword ptr [__imp__RtlReleasePebLock@0 (7D4D00B8h)] 7D4DF9F7 8B C3 mov eax,ebx 7D4DF9F9 5F pop edi 7D4DF9FA 5E pop esi 7D4DF9FB 5B pop ebx 7D4DF9FC C3 ret ---------------------------------------- Notice in both, a deref at offset 48h happens, but on the Server 2003 its memcpy-ed to a new memory block. IDK if this is a 32 bit process on x64 thing, or a Server 2003 thing. On my WinXP FreeEnvironmentStringsW asm wise, just returns 1 always. It doesn't free anything. Which matches WinXP's GetEnvironmentStringsW's behavior. -- bulk88 ~ bulk88 at hotmail.com
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 482b
On Tue May 13 04:33:39 2014, bulk88 wrote: Show quoted text
> IDK if this is a 32 bit process > on x64 thing, or a Server 2003 thing. On my WinXP > FreeEnvironmentStringsW asm wise, just returns 1 always. It doesn't > free anything. Which matches WinXP's GetEnvironmentStringsW's > behavior.
64 bit kernel32.dll from x64 Server 2003 also allocates memory identically to the 32 bit kernel32.dll code. IDK what a pure 32 bit Server 2003 would do, or a NT6 machine. -- bulk88 ~ bulk88 at hotmail.com
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 976b
On Tue May 13 04:36:45 2014, bulk88 wrote: Show quoted text
> On Tue May 13 04:33:39 2014, bulk88 wrote:
> > IDK if this is a 32 bit process > > on x64 thing, or a Server 2003 thing. On my WinXP > > FreeEnvironmentStringsW asm wise, just returns 1 always. It doesn't > > free anything. Which matches WinXP's GetEnvironmentStringsW's > > behavior.
> > 64 bit kernel32.dll from x64 Server 2003 also allocates memory > identically to the 32 bit kernel32.dll code. IDK what a pure 32 bit > Server 2003 would do, or a NT6 machine.
I think I know what happened, MS decided to enforce the ----------------------- Treat this memory as read-only; do not modify it directly. To add or change an environment variable, use the GetEnvironmentVariable and SetEnvironmentVariable functions. ----------------------- sentence from MSDN's GetEnvironmentStrings docs. This article supports that guess http://blogs.msdn.com/b/oldnewthing/archive/2013/01/18/10385718.aspx . -- bulk88 ~ bulk88 at hotmail.com
From: Steve Hay <Steve.Hay [...] verosoftware.com>
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
Date: Tue, 13 May 2014 11:56:42 +0000
Subject: RE: [perl #121676] Memory leak in backticks and system
CC: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 1.3k
Show quoted text
> -----Original Message----- > From: bulk88 via RT [mailto:perlbug-followup@perl.org] > Sent: 13 May 2014 12:42 > Cc: perl5-porters@perl.org > Subject: [perl #121676] Memory leak in backticks and system > > On Tue May 13 04:36:45 2014, bulk88 wrote:
> > On Tue May 13 04:33:39 2014, bulk88 wrote:
> > > IDK if this is a 32 bit process > > > on x64 thing, or a Server 2003 thing. On my WinXP > > > FreeEnvironmentStringsW asm wise, just returns 1 always. It doesn't > > > free anything. Which matches WinXP's GetEnvironmentStringsW's > > > behavior.
> > > > 64 bit kernel32.dll from x64 Server 2003 also allocates memory > > identically to the 32 bit kernel32.dll code. IDK what a pure 32 bit > > Server 2003 would do, or a NT6 machine.
> > I think I know what happened, MS decided to enforce the > > ----------------------- > Treat this memory as read-only; do not modify it directly. To add or > change an environment variable, use the GetEnvironmentVariable and > SetEnvironmentVariable functions. > ----------------------- > > sentence from MSDN's GetEnvironmentStrings docs. This article supports > that guess > http://blogs.msdn.com/b/oldnewthing/archive/2013/01/18/10385718.aspx . >
Thanks for the details. The attached patch fixes the leak for me. If this looks good to you then I think it should go in for 5.20 (and get backported to 5.18 too).

Message body is not shown because sender requested not to inline it.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 378b
On Tue May 13 04:57:08 2014, Steve.Hay@verosoftware.com wrote: Show quoted text
> Thanks for the details. > > The attached patch fixes the leak for me. If this looks good to you > then I think it should go in for 5.20 (and get backported to 5.18 > too).
Works for me, no more leaking on the Server 2003. I also wrote a perldelta for this that is attached. -- bulk88 ~ bulk88 at hotmail.com
Subject: 0002-perldelta-for-121676.patch
From c2e7a6e3f72d8c6fb036c05c91b3b6b974503749 Mon Sep 17 00:00:00 2001 From: Daniel Dragan <bulk88@hotmail.com> Date: Wed, 14 May 2014 04:09:39 -0400 Subject: [PATCH 2/2] perldelta for #121676 --- pod/perldelta.pod | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/pod/perldelta.pod b/pod/perldelta.pod index 3b4db7f..07e963f 100644 --- a/pod/perldelta.pod +++ b/pod/perldelta.pod @@ -1598,6 +1598,14 @@ would crash accessing parameter information for context stack entries that included no parameters, as with C<&foo;>. [L<perl #121721|https://rt.perl.org/Public/Bug/Display.html?id=121721>] +=item * + +Introduced by [perl #113536], a memory leak on every call to C<system> +and backticks (C< `` >), on most Win32 Perls starting from 5.18.0 +has been fixed. The memory leak only occurred if you enabled psuedo-fork in +your build of Win32 Perl, and were running that build on Server 2003 R2 +or newer OS. The leak does not appear on WinXP SP3. [perl #121676] + =back =item WinCE -- 1.7.9.msysgit.0
To: Ricardo SIGNES <perl.p5p [...] rjbs.manxome.org>
Date: Wed, 14 May 2014 13:09:28 +0100
From: Steve Hay <steve.m.hay [...] googlemail.com>
CC: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>, Tony Cook via RT <perlbug-followup [...] perl.org>
Subject: Re: [perl #121676] Memory leak in backticks and system
Download (untitled) / with headers
text/plain 521b
On 14 May 2014 09:26, bulk88 via RT <perlbug-followup@perl.org> wrote: Show quoted text
> On Tue May 13 04:57:08 2014, Steve.Hay@verosoftware.com wrote:
>> Thanks for the details. >> >> The attached patch fixes the leak for me. If this looks good to you >> then I think it should go in for 5.20 (and get backported to 5.18 >> too).
> > > Works for me, no more leaking on the Server 2003. I also wrote a perldelta for this that is attached. >
Thanks. Ricardo: Are you happy for this patch (and the perldelta) to go into blead for 5.20?
Subject: Re: [perl #121676] Memory leak in backticks and system
CC: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>, Tony Cook via RT <perlbug-followup [...] perl.org>
To: Steve Hay <steve.m.hay [...] googlemail.com>
Date: Wed, 14 May 2014 10:16:04 -0400
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Download (untitled) / with headers
text/plain 166b
* Steve Hay <steve.m.hay@googlemail.com> [2014-05-14T08:09:28] Show quoted text
> Ricardo: Are you happy for this patch (and the perldelta) to go into > blead for 5.20?
+1 -- rjbs
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

From: Steve Hay <steve.m.hay [...] googlemail.com>
Subject: Re: [perl #121676] Memory leak in backticks and system
CC: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>, Tony Cook via RT <perlbug-followup [...] perl.org>
To: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Date: Wed, 14 May 2014 18:17:04 +0100
Download (untitled) / with headers
text/plain 282b
On 14 May 2014 15:16, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote: Show quoted text
> * Steve Hay <steve.m.hay@googlemail.com> [2014-05-14T08:09:28]
>> Ricardo: Are you happy for this patch (and the perldelta) to go into >> blead for 5.20?
> > +1 >
Now in: commits 90674eaa88 and 58627cdf06.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 807b
On Wed May 14 10:17:27 2014, shay wrote: Show quoted text
> On 14 May 2014 15:16, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
> > * Steve Hay <steve.m.hay@googlemail.com> [2014-05-14T08:09:28]
> >> Ricardo: Are you happy for this patch (and the perldelta) to go into > >> blead for 5.20?
> > > > +1 > >
> > Now in: commits 90674eaa88 and 58627cdf06. >
I noticed a problem, the patch uses FreeEnvironmentStrings, but above we used GetEnvironmentStringsW, with the "W". Therefore we have to use FreeEnvironmentStringsW, not FreeEnvironmentStrings which I bet is mapping to FreeEnvironmentStringsA. FreeEnvironmentStringsA and FreeEnvironmentStringsW have different implementations on my WinXP SP3 machine FreeEnvironmentStringsA calls RtlFreeHeap, FreeEnvironmentStringsW doesn't. -- bulk88 ~ bulk88 at hotmail.com
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 768b
On Wed May 14 10:55:10 2014, bulk88 wrote: Show quoted text
> > I noticed a problem, the patch uses FreeEnvironmentStrings, but above > we used GetEnvironmentStringsW, with the "W". Therefore we have to use > FreeEnvironmentStringsW, not FreeEnvironmentStrings which I bet is > mapping to FreeEnvironmentStringsA. FreeEnvironmentStringsA and > FreeEnvironmentStringsW have different implementations on my WinXP SP3 > machine FreeEnvironmentStringsA calls RtlFreeHeap, > FreeEnvironmentStringsW doesn't.
On Server 2003 kernel32.dll, asm-wise FreeEnvironmentStringsA and FreeEnvironmentStringsW are the same function pointer (de-duping identical functions optimization by compiler), that is probably why nothing wrong happened when I tested the fix. -- bulk88 ~ bulk88 at hotmail.com
Subject: Re: [perl #121676] Memory leak in backticks and system
CC: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
From: Steve Hay <steve.m.hay [...] googlemail.com>
Date: Wed, 14 May 2014 21:06:37 +0100
To: Tony Cook via RT <perlbug-followup [...] perl.org>
Download (untitled) / with headers
text/plain 1.1k
On 14 May 2014 18:58, bulk88 via RT <perlbug-followup@perl.org> wrote: Show quoted text
> On Wed May 14 10:55:10 2014, bulk88 wrote:
>> >> I noticed a problem, the patch uses FreeEnvironmentStrings, but above >> we used GetEnvironmentStringsW, with the "W". Therefore we have to use >> FreeEnvironmentStringsW, not FreeEnvironmentStrings which I bet is >> mapping to FreeEnvironmentStringsA. FreeEnvironmentStringsA and >> FreeEnvironmentStringsW have different implementations on my WinXP SP3 >> machine FreeEnvironmentStringsA calls RtlFreeHeap, >> FreeEnvironmentStringsW doesn't.
> > On Server 2003 kernel32.dll, asm-wise FreeEnvironmentStringsA and FreeEnvironmentStringsW are the same function pointer (de-duping identical functions optimization by compiler), that is probably why nothing wrong happened when I tested the fix. >
Argh! My apologies and thanks for the spot. Now fixed in commit a6abe943fc. (Yes, FreeEnvironmentStringsA maps to FreeEnvironmentStrings unless UNICODE is #defined. Normally I would just write FreeEnvironmentStrings and #define UNICODE (or not) as required, hence I wasn't on the ball there with the need to explicitly call the *W() version in this case.)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 260b
Now all fixed in blead as noted above, and also backported to maint-5.18 in these four commits: 2358a1918b2f128e65221e2955c29a14b073e17d 72a2b4814f2af582db6077a7799472fa0dd3405e d4ade35d4bc5501ed48d711e25fc1d01e2fc1c68 b54db2a037dcea55aeb502be750fd3e3b7507e72


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org