Closed p5pRT closed 18 years ago
p5pRT
commented
18 years ago This email\, and any files previous email messages included with it\, may contain confidential and/or privileged material. If you are not the intended recipient please contact the sender and delete all copies.
p5pRT
commented
18 years ago Please refer to this link for a complete description and conversation regarding this bug. http://www.perlmonks.org/?node_id=526288
It seems that calling system 1 foo will result in a memory leak.
Sample program..
P:\test>perl -wle"system(1\,'notepad')==-1 && print qq[failed $_ process with: $!] for 1..65" failed 65 process with: Resource temporarily unavailable
p5pRT
commented
18 years ago This email\, and any files previous email messages included with it\, may contain confidential and/or privileged material. If you are not the intended recipient please contact the sender and delete all copies.
p5pRT
commented
18 years ago Please refer to this link for a complete description and conversation regarding this bug. http://www.perlmonks.org/?node_id=526288
It seems that calling system 1 foo will result in a memory leak.
Sample program..
P:\test>perl -wle"system(1\,'notepad')==-1 && print qq[failed $_ process with: $!] for 1..65" failed 65 process with: Resource temporarily unavailable
p5pRT
commented
18 years ago This email\, and any files previous email messages included with it\, may contain confidential and/or privileged material. If you are not the intended recipient please contact the sender and delete all copies.
p5pRT
commented
18 years ago Please refer to this link for a complete description and conversation regarding this bug. http://www.perlmonks.org/?node_id=526288
It seems that calling system 1 foo will result in a memory leak.
Sample program..
P:\test>perl -wle"system(1\,'notepad')==-1 && print qq[failed $_ process with: $!] for 1..65" failed 65 process with: Resource temporarily unavailable
p5pRT
commented
18 years ago On Tue\, 18 Apr 2006\, Lloyd\, Steve (via RT) wrote:
# New Ticket Created by "Lloyd\, Steve" Please include the string: # [perl #38946] in the subject line of all future correspondence about # this issue. \<URL: # https://rt-archive.perl.org/perl5/Ticket/Display.html?id=38946 >
This is a bug report for perl from slloyd@timequest.org\, generated with the help of perlbug 1.35 running under perl v5.8.4.
----------------------------------------------------------------- [Please enter your report here] Please refer to this link for a complete description and conversation regarding this bug. http://www.perlmonks.org/?node_id=526288
It seems that calling system 1 foo will result in a memory leak.
Sample program..
P:\test>perl -wle"system(1\,'notepad')==-1 && print qq[failed $_ process with: $!] for 1..65" failed 65 process with: Resource temporarily unavailable
This behavior is by design. system(1\, ...) returns a process id that must be reclaimed with wait() or waitpid(). There is an implementation limit of 64 entries in the internal pid table. This table is also being used by the fork() emulation\, so there cannot be more than about 64 forked or spawned child processes combined at any time.
So\, this is a limit\, not a leak. :)
Cheers\, -Jan
p5pRT
commented
18 years ago The RT System itself - Status changed from 'new' to 'open'
p5pRT
commented
18 years ago @rgs - Status changed from 'open' to 'rejected'
p5pRT
commented
18 years ago On Wed\, Apr 19\, 2006 at 12:46:25AM -0700\, Jan Dubois wrote:
On Tue\, 18 Apr 2006\, Lloyd\, Steve (via RT) wrote:
# New Ticket Created by "Lloyd\, Steve" Please include the string: # [perl #38946] in the subject line of all future correspondence about # this issue. \<URL: # https://rt-archive.perl.org/perl5/Ticket/Display.html?id=38946 >
This is a bug report for perl from slloyd@timequest.org\, generated with the help of perlbug 1.35 running under perl v5.8.4.
----------------------------------------------------------------- [Please enter your report here] Please refer to this link for a complete description and conversation regarding this bug. http://www.perlmonks.org/?node_id=526288
It seems that calling system 1 foo will result in a memory leak.
Sample program..
P:\test>perl -wle"system(1\,'notepad')==-1 && print qq[failed $_ process with: $!] for 1..65" failed 65 process with: Resource temporarily unavailable
This behavior is by design. system(1\, ...) returns a process id that must be reclaimed with wait() or waitpid(). There is an implementation limit of 64 entries in the internal pid table. This table is also being used by the fork() emulation\, so there cannot be more than about 64 forked or spawned child processes combined at any time.
So\, this is a limit\, not a leak. :)
Just as a side question\, is this at all related to RT #7112: "Bug: Win32 fails after 6 forks"
Steve Peters steve@fisharerojo.org
p5pRT
commented
18 years ago Jan Dubois wrote:
This behavior is by design. system(1\, ...) returns a process id that must be reclaimed with wait() or waitpid().
Where is 'system(1\, ...)' behavior documented? I don't find it in perlfunc.
p5pRT
commented
18 years ago On 4/19/06\, Jerry D. Hedden \jerry@​hedden\.us wrote:
Jan Dubois wrote:
This behavior is by design. system(1\, ...) returns a process id that must be reclaimed with wait() or waitpid().
Where is 'system(1\, ...)' behavior documented? I don't find it in perlfunc.
Its an OS2/Win32ism for spawning a process and not waiting for it to terminate. Its how fork/exec is implemented internally on Win32 as fork is a thread spawn\, and thus exec isnt very helpful. iirc anyway.
I think youll find it documented in one of the Win32 specific docs somewhere.
Yves
-- perl -Mre=debug -e "/just|another|perl|hacker/"
p5pRT
commented
18 years ago On Wed\, Apr 19\, 2006 at 08:27:36PM +0200\, demerphq wrote:
On 4/19/06\, Jerry D. Hedden \jerry@​hedden\.us wrote:
Jan Dubois wrote:
This behavior is by design. system(1\, ...) returns a process id that must be reclaimed with wait() or waitpid().
Where is 'system(1\, ...)' behavior documented? I don't find it in perlfunc.
Its an OS2/Win32ism for spawning a process and not waiting for it to terminate. Its how fork/exec is implemented internally on Win32 as fork is a thread spawn\, and thus exec isnt very helpful. iirc anyway.
I think youll find it documented in one of the Win32 specific docs somewhere.
It's in perlport\, under system.
I don't think anyone wanted to document it properly because it feels like such a hack and the hope was that it would be replaced with something nicer. Well\, it's been semi-documented for a good few years now\, so it's probably too late to get rid of it\, and nothing nicer has appeared anyway\, so maybe it is time to document it properly\, by which I mean under system in perlfunc.
Or maybe we want to try to keep it under the carpet and hope that not too many people notice it. It is still Win32 specific after all.
Yes\, I can definitely argue that one both ways.
-- Paul Johnson - paul@pjcj.net http://www.pjcj.net
p5pRT
commented
18 years ago On Wed\, 19 Apr 2006\, Steve Peters wrote:
Just as a side question\, is this at all related to RT #7112: "Bug: Win32 fails after 6 forks"
Nope #7112 is a memory pool error. It seems fixed in blead but still happens with 5.8.8.
Cheers\, -Jan
p5pRT
commented
18 years ago Steve Lloyd \perl5\-porters@​perl\.org writes:
# New Ticket Created by "Lloyd\, Steve" # Please include the string: [perl #38946] # in the subject line of all future correspondence about this issue. # \<URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=38946 >
This is a bug report for perl from slloyd@timequest.org\,
generated with the help of perlbug 1.35 running under perl v5.8.4.
system 1 foo
returns the process id of the process which is running in background. It is the Win32 way to do what you would fork/exec on Unix.
I think you are supposed to wait() for the process at somepoint and when you do that you get the return code from foo and the memory and such like are freed.
-----------------------------------------------------------------
[Please enter your report here]
Please refer to this link for a complete description and conversation regarding this bug.
http://www.perlmonks.org/?node_id=526288
It seems that calling system 1 foo will result in a memory leak.
Sample program..
P:\test>perl -wle"system(1\,'notepad')==-1 && print qq[failed $_ process with: $!] for 1..65"
failed 65 process with: Resource temporarily unavailable
[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
category=core
severity=high
---
Site configuration information for perl v5.8.4:
Configured by ActiveState at Tue Jun 1 11:52:09 2004.
Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
Platform:
osname=MSWin32\, osvers=4.0\, archname=MSWin32-x86-multi-thread
uname=''
config_args='undef'
hint=recommended\, useposix=true\, d_sigaction=undef
usethreads=undef 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='cl'\, ccflags ='-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX'\,
optimize='-MD -Zi -DNDEBUG -O1'\,
cppflags='-DWIN32'
ccversion=''\, gccversion=''\, gccosandvers=''
intsize=4\, longsize=4\, ptrsize=4\, doublesize=8\, byteorder=1234
d_longlong=undef\, longlongsize=8\, d_longdbl=define\, longdblsize=10
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 -libpath:"C:\Perl\lib\CORE" -machine:x86'
libpth=C:\PROGRA~1\MICROS~3\VC98\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 wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.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 wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib
libc=msvcrt.lib\, so=dll\, useshrplib=yes\, libperl=perl58.lib
gnulibc_version='undef'
Dynamic Linking:
dlsrc=dl_win32.xs\, dlext=dll\, d_dlsymun=undef\, ccdlflags=' '
cccdlflags=' '\, lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref\,icf -libpath:"C:\Perl\lib\CORE" -machine:x86'
Locally applied patches:
ACTIVEPERL_LOCAL_PATCHES_ENTRY
22751 Update to Test.pm 1.25
21540 Fix backward-compatibility issues in if.pm
---
@INC for perl v5.8.4:
C:/Perl/lib
C:/Perl/site/lib
.
---
Environment for perl v5.8.4:
HOME (unset)
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=c:\program files\imagemagick-6.2.5-q16;c:\perl2exe;C:\Perl\bin\;C:\oracle\ora92\bin;C:\Program Files\Oracle\jre\1.3.1\bin;C:\Program Files\Oracle\jre\1.1.8\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Microsoft SQL Server\80\Tools\BINN;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE;C:\Tools\nant\bin;C:\Program Files\TortoiseCVS;C:\Program Files\Rational\common;C:\Program Files\Rational\ClearQuest;C:\Program Files\QuickTime\QTSystem\;E:\perl2exe;c:\program files\context;e:\bin;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;e:\developer\build;e:\devtools\wasql;c:\ld-dev\build;c:\ld-dev\build\utils
PERL_BADLANG (unset)
SHELL (unset)
This email\, and any files previous email messages included with it\, may contain confidential and/or privileged material. If you are not the intended recipient please contact the sender and delete all copies.
p5pRT
commented
18 years ago Paul Johnson \paul@​pjcj\.net writes:
On Wed\, Apr 19\, 2006 at 08:27:36PM +0200\, demerphq wrote:
On 4/19/06\, Jerry D. Hedden \jerry@​hedden\.us wrote:
Jan Dubois wrote:
This behavior is by design. system(1\, ...) returns a process id that must be reclaimed with wait() or waitpid().
Where is 'system(1\, ...)' behavior documented? I don't find it in perlfunc.
Its an OS2/Win32ism for spawning a process and not waiting for it to terminate. Its how fork/exec is implemented internally on Win32 as fork is a thread spawn\, and thus exec isnt very helpful. iirc anyway.
I think youll find it documented in one of the Win32 specific docs somewhere.
It's in perlport\, under system.
I don't think anyone wanted to document it properly because it feels like such a hack and the hope was that it would be replaced with something nicer. Well\, it's been semi-documented for a good few years now\, so it's probably too late to get rid of it\, and nothing nicer has appeared anyway\,
Well pseudo-fork is a bit nicer ;-)
p5pRT
commented
18 years ago On Thu\, 2006-04-20 at 21:48 +0100\, Nick Ing-Simmons wrote:
Paul Johnson \paul@​pjcj\.net writes:
On Wed\, Apr 19\, 2006 at 08:27:36PM +0200\, demerphq wrote:
On 4/19/06\, Jerry D. Hedden \jerry@​hedden\.us wrote:
Jan Dubois wrote:
This behavior is by design. system(1\, ...) returns a process id that must be reclaimed with wait() or waitpid().
Where is 'system(1\, ...)' behavior documented? I don't find it in perlfunc.
Its an OS2/Win32ism for spawning a process and not waiting for it to terminate. Its how fork/exec is implemented internally on Win32 as fork is a thread spawn\, and thus exec isnt very helpful. iirc anyway.
I think youll find it documented in one of the Win32 specific docs somewhere.
It's in perlport\, under system.
I don't think anyone wanted to document it properly because it feels like such a hack and the hope was that it would be replaced with something nicer. Well\, it's been semi-documented for a good few years now\, so it's probably too late to get rid of it\, and nothing nicer has appeared anyway\,
Well pseudo-fork is a bit nicer ;-)
Wouldn't that be a "spork"? ]:>
Migrated from rt.perl.org#38946 (status was 'rejected')
Searchable as RT38946$