From mattgill@nortelnetworks.com

  Dear bug fixers,

  I am using a Perl interpreter embedded in C/C++. The following
simple C test program causes the
  computer to eventually run out of memory. This is the case whether I
run it on my Windows NT machine
  or my HP-UX one. I am using the latest stable version of Perl
(5.00503). (The Perl code used to run this
  was compiled WITHOUT multiple interpreters enabled).
 
  /* mytest5.c */

  #include <stdio.h>
  #include <stdlib.h>
  #include <EXTERN.h>
  #include <perl.h>

  static PerlInterpreter *my_perl;

  int main (int argc, char** argv, char** env) {
  int j;
  char* my_argv[] = { "", "first.pl" };

  /* Continuously create an interpreter, then parse file,
  then call sub, then destroy interpreter - shouldn't memory leak */

  for (j = 0; j < 10000; j++) {
  my_perl = perl_alloc();
  perl_construct(my_perl);
  perl_parse(my_perl, NULL, 3, my_argv, (char**)NULL);
  perl_call_argv("func1", G_DISCARD | G_NOARGS, my_argv);
  printf("\n* %d **\n", j);
  perl_destruct(my_perl);
  perl_free(my_perl);
  }

  return 0;
  }

  The Perl code is as follows​:

  #! /usr/bin/perl -w
  #
  # first.pl
  #
  sub func1 {
  print "\n hello from first​::func1! ";
  }

  sub func2 {
  print "\n hello from first​::func2 ";
  }
 

  The output of perlbug -d, on my Windows machine, is as follows​:

  Site configuration information for perl 5.00503​:

  Summary of my perl5 (5.0 patchlevel 5 subversion 03) configuration​:
  Platform​:
  osname=MSWin32, osvers=4.0, archname=MSWin32-x86
  uname=''
  hint=recommended, useposix=true, d_sigaction=undef
  usethreads=undef useperlio=undef d_sfio=undef
  Compiler​:
  cc='cl.exe', optimize='-Od -MD -DNDEBUG', gccversion=
  cppflags='-DWIN32'
  ccflags ='-Od -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT '
  stdchar='char', d_stdstdio=define, usevfork=false
  intsize=4, longsize=4, ptrsize=4, doublesize=8
  d_longlong=undef, longlongsize=8, d_longdbl=define,
longdblsize=10
  alignbytes=8, usemymalloc=n, prototype=define
  Linker and Libraries​:
  ld='link', ldflags ='-nologo -nodefaultlib -release
-machine​:x86'
  libpth=\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 PerlCRT.lib
  libc=PerlCRT.lib, so=dll, useshrplib=yes, libperl=perl.lib
  Dynamic Linking​:
  dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
  cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release
-machine​:x86'

  Locally applied patches​:
 

  ---
  @​INC for perl 5.00503​:
  c​:\perl\5.00503\lib/MSWin32-x86
  c​:\perl\5.00503\lib
  c​:\perl\site\5.00503\lib
  c​:\perl\site\lib
  .

  ---
  Environment for perl 5.00503​:
  HOME (unset)
  LANG (unset)
  LANGUAGE (unset)
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
 
  PERL_BADLANG (unset)
  SHELL (unset)

  (I've left out the PATH)

  Yours Sincerely

  Matthew Gillman

Matthew Gillman DIRECT -
Advanced IP Services & Management Tel​: +44 (0)1279 403297
Nortel Networks plc
ESN​: 742 3297
London Road Email​:
mattgill@​nortelnetworks.com
HARLOW,
DEPARTMENT -
Essex, CM17 9NA, Fax​: +44
(0)1279 403930
UK
WWW​: <http​://www.nortel.com/RCP-ORB>

This message may contain information proprietary to Nortel Networks so any
unauthorised disclosure, copying, or distribution of its contents is
strictly prohibited.

From [Unknown Contact. See original ticket]

This looks similar to 19991217.006.

-spp

------- Forwarded Message

From​: "Matthew Gillman" <mattgill@​nortelnetworks.com>
Subject​: RE​: Perlbug ID 19991215.009​: Possible memory leak in embedded Per l
Date​: Mon, 11 Dec 2000 16​:17​:55 -0000

I don't know for 100% definite, but I'm fairly sure that this is still an
open bug. At the time I posted this bug, as well as testing it with the
latest stable version I also tried using what was then the current
development version (?? 5.0062 or similar ??) and this also had the same
problem.

Moreover, in recent months I made a posting on the Perl 6 RFC site, saying
similar stuff, and people agreed with me that embedded Perl memory leaks
etc. is an area needing clean-up.

So - looks like it's still open at the moment, I'm afraid - although as I
personally haven't tried it with perl 5.6.0 I can't say that with total 100%
certainty.

Hope this helps.

Matthew

-----Original Message-----
From​: Stephen P. Potter [SMTP​:spp@​spotter.yi.org]
Sent​: 11 December 2000 16​:05
To​: Gillman, Matthew [HAL02​:HG20​:EXCH]
Subject​: Perlbug ID 19991215.009​: Possible memory leak in embedded
Perl

Matthew-
In an attempt to clean up the perl bug database, I came across this report
you filed last year. Can you tell me whether this bug is still current,
or
whether you believe it has been fixed in a newer version of perl and can
be
closed?

Dear bug fixers,

I am using a Perl interpreter embedded in C/C++. The following simple C
test program causes the computer to eventually run out of memory. This is
the case whether I run it on my Windows NT machine or my HP-UX one. I am
using the latest stable version of Perl (5.00503). (The Perl code used to
run this was compiled WITHOUT multiple interpreters enabled).

     /\* mytest5\.c \*/ 

     \#include \<stdio\.h> 
     \#include \<stdlib\.h> 
     \#include \<EXTERN\.h> 
     \#include \<perl\.h> 

     static PerlInterpreter \*my\_perl; 

     int main \(int argc\, char\*\* argv\, char\*\* env\) \{ 
       int j; 
       char\* my\_argv\[\] = \{ ""\, "first\.pl" \}; 

       /\* Continuously create an interpreter\, then parse file\, 
       then call sub\, then destroy interpreter \- shouldn't memory leak

*/

       for \(j = 0; j \< 10000; j\+\+\) \{ 
         my\_perl = perl\_alloc\(\); 
         perl\_construct\(my\_perl\); 
         perl\_parse\(my\_perl\, NULL\, 3\, my\_argv\, \(char\*\*\)NULL\); 
         perl\_call\_argv\("func1"\, G\_DISCARD | G\_NOARGS\, my\_argv\); 
         printf\("\\n\* %d \*\*\\n"\, j\); 
         perl\_destruct\(my\_perl\); 
         perl\_free\(my\_perl\); 
       \} 

       return 0; 
     \} 

------- End of Forwarded Message

From @steve-m-hay

This ancient bug report is still valid, and actually seems to be worse
than the original description suggests.

The memory leak seems to be caused by perl_construct() and/or
perl_destruct(); it's not (or at least not *just*) caused by
perl_parse() and/or call_argv(). The following program leaks very quickly​:

#include <EXTERN.h>
#include <perl.h>

static PerlInterpreter *my_perl;

int main (int argc, char** argv, char** env) {
  int i;

  for (i = 0; i < 10000; i++) {
  my_perl = perl_alloc();
  perl_construct(my_perl);
  printf("\n** %d **\n", i);
  perl_destruct(my_perl);
  perl_free(my_perl);
  }

  return 0;
}

Simply removing the perl_construct()/perl_destruct() calls plugs the leak.

Can this be reproduced on other OS's besides Win32?

Here's my "perl -V"​:

Summary of my perl5 (revision 5 version 8 subversion 5) configuration​:
  Platform​:
  osname=MSWin32, osvers=4.0, archname=MSWin32-x86-perlio
  uname=''
  config_args='undef'
  hint=recommended, useposix=true, d_sigaction=undef
  usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
  useperlio=define d_sfio=undef uselargefiles=undef usesocks=undef
  use64bitint=undef use64bitall=undef uselongdouble=undef
  usemymalloc=y, bincompat5005=undef
  Compiler​:
  cc='cl', ccflags ='-nologo -Gf -W3 -MD -Zi -Zm200 -DNDEBUG -O1
-DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT
-DPERL_DEBUGGING_MSTATS -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='off_t',
lseeksize=4
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='link', ldflags ='-nologo -nodefaultlib -debug -opt​:ref,icf
-libpath​:"C​:\perl5\lib\CORE" -machine​:x86'
  libpth=C​:\PROGRA1\MICROS2\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​:\perl5\lib\CORE" -machine​:x86'

Characteristics of this binary (from libperl)​:
  Compile-time options​:
  Locally applied patches​:
  23128 Use VirtualAlloc() more flexibly to mimic UNIX's sbrk()
  Built under MSWin32
  Compiled at Jul 26 2004 10​:56​:24
  @​INC​:
  C​:/perl5/lib
  C​:/perl5/site/lib
  .

From nick@ing-simmons.net

Steve Hay via RT <bugs-perl5@​bugs6.perl.org> writes​:

This ancient bug report is still valid, and actually seems to be worse
than the original description suggests.

The memory leak seems to be caused by perl_construct() and/or
perl_destruct(); it's not (or at least not *just*) caused by
perl_parse() and/or call_argv(). The following program leaks very quickly​:

#include <EXTERN.h>
#include <perl.h>

static PerlInterpreter *my_perl;

int main (int argc, char** argv, char** env) {
int i;

for (i = 0; i < 10000; i++) {
my_perl = perl_alloc();
perl_construct(my_perl);
printf("\n** %d **\n", i);
perl_destruct(my_perl);
perl_free(my_perl);
}

return 0;
}

Simply removing the perl_construct()/perl_destruct() calls plugs the leak.

Can this be reproduced on other OS's besides Win32?

Any that don't have MULTIPLICITY defined.

If you want perl_destruct to clean up you need to set

PL_perl_destruct_level = 1;

(But MULTIPLICITY does that.)

The boiler plate should probably include

PL_exit_flags |= PERL_EXIT_DESTRUCT_END;

as well.

Here's my "perl -V"​:

Summary of my perl5 (revision 5 version 8 subversion 5) configuration​:
Platform​:
osname=MSWin32, osvers=4.0, archname=MSWin32-x86-perlio
uname=''
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=undef usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=y, bincompat5005=undef
Compiler​:
cc='cl', ccflags ='-nologo -Gf -W3 -MD -Zi -Zm200 -DNDEBUG -O1
-DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT
-DPERL_DEBUGGING_MSTATS -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='off_t',
lseeksize=4
alignbytes=8, prototype=define
Linker and Libraries​:
ld='link', ldflags ='-nologo -nodefaultlib -debug -opt​:ref,icf
-libpath​:"C​:\perl5\lib\CORE" -machine​:x86'
libpth=C​:\PROGRA1\MICROS2\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​:\perl5\lib\CORE" -machine​:x86'

Characteristics of this binary (from libperl)​:
Compile-time options​:
Locally applied patches​:
23128 Use VirtualAlloc() more flexibly to mimic UNIX's sbrk()
Built under MSWin32
Compiled at Jul 26 2004 10​:56​:24
@​INC​:
C​:/perl5/lib
C​:/perl5/site/lib
.

p5p@spam.wizbit.be - Status changed from 'open' to 'resolved'