Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

memory leaking in perl_destruct and perl_free ? #6487

Open
p5pRT opened this issue May 6, 2003 · 6 comments
Open

memory leaking in perl_destruct and perl_free ? #6487

p5pRT opened this issue May 6, 2003 · 6 comments

Comments

@p5pRT
Copy link

p5pRT commented May 6, 2003

Migrated from rt.perl.org#22121 (status was 'open')

Searchable as RT22121$

@p5pRT
Copy link
Author

p5pRT commented May 6, 2003

From Haili.Ma@netiq.com

Hi, Dear Experts​:
The attached is the cooked down program, which keeps leaking memory on my
Solaris machine. I am using perl 5.6.1.
Any suggestion or bug reporting on this issue ?
Thanks !
Haili

# include <stdio.h>
# include <EXTERN.h>
# include <perl.h>
# include <unistd.h>
void call_perl();
int main(int argc, char **argv, char **env)
{ /* The Leaking Loop */
  while (1){
  call_perl(); sleep(1);
  }
}
void call_perl(void) {
static PerlInterpreter *my_perl;
char *embedding[] = { "", "-e", "0" };
my_perl = perl_alloc();
perl_construct(my_perl);
perl_parse(my_perl, NULL, 3, embedding, NULL);
perl_run(my_perl);
eval_pv("print \"Perl Version​: $]\\n\"",TRUE);
perl_destruct(my_perl);
perl_free(my_perl);
}

@p5pRT
Copy link
Author

p5pRT commented Jul 28, 2003

From Tom.Widgery@swi.galileo.com

Dear Experts.
I apologize if this is the incorrect email address to respond to this issue
at I have never delved so deeply into perl before.....

I am having a problem very similar to the one described in ticket #22121 I
am attaching an example of the code I am using. It is inside a rather big
loop and do not wish for you to be bothered with the multiple servers and
clients in this product. The basic code is thus....

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

static PerlInterpreter *my_perl;
int count;
int counter;
char *queue;
char *tempPop;
char *temp;
int i = 0;

EXTERN_C void xs_init _((void));

EXTERN_C void boot_DynaLoader _((CV* cv));

EXTERN_C void
xs_init(void)
{
char *file = __FILE__;
dXSUB_SYS;

/* DynaLoader is a special case */
newXS("DynaLoader​::boot_DynaLoader", boot_DynaLoader, file);
}

/***************************************************************************
*/
/* PERL Database interface subroutine, should return an array of queue names
*/
/***************************************************************************
*/
Perldatabase(char pseudo [6], char *queue)
{

dSP;
ENTER;
SAVETMPS;
PUSHMARK (SP);
XPUSHs (sv_2mortal (newSVpv (pseudo,6)));
PUTBACK;
perl_call_pv("database", G_ARRAY);
SPAGAIN;
count = POPi;
temp=queue;
while (count !=0)
{
tempPop = POPp;

memcpy (temp, tempPop, 10);
count--;
temp = temp+10;
}

PUTBACK;
FREETMPS;
LEAVE;
}

char* interface(char pseudo[6], char *queue)
{

char *my_argv[] = { "", "dataquery.pl"};
my_perl = perl_alloc();
perl_construct(my_perl);
perl_parse(my_perl, xs_init, 2, my_argv, (char **)NULL);

perl_run(my_perl);

Perldatabase(pseudo, queue);

perl_destruct (my_perl);
perl_free(my_perl);

return (queue);

}

And the perl script running looks like this

#!/perl5/bin/perl
use SDBM_File;
use POSIX;
use strict;

sub database
{
my ($pseudo) = @​_;

my %dbm;
my $db_file = "CTIC.dbm";
tie my %dbm, 'SDBM_File', $db_file, O_RDWR, 0; #open read only

my @​list=split ("__",$dbm{"$pseudo"});

untie my %dbm;

push( @​list, scalar( @​list ) );

return @​list;

}

This seems to cause a rather large memory leak - I have traced through this
line by line and can see that the perl_parse obtains a large amount of
memory but the perl_free doesn't seem to release any of it.
A little bit of background - we are retrieving a message from an MQ queue
and then sending it through the perl database to route it to another MQ
queue - it is a constantly running client i.e. it is always polling the MQ
queue to get new messages - so effectively this is a looping process.
We are running Perl 5.00503 on an AIX box under a Tuxedo environment.
My question is​: Is there anyway to fix this issue? Unfortunately if we
can't find a way to release this memory I am going to have to re-write
everything using another language!!!

My thanks for your time

I hope this can be resolved.

Tom

Tom Widgery
Ticketing Services
303 397 5949

The information in this electronic mail message is sender's business
Confidential and may be legally privileged. It is intended solely for the
addressee(s). Access to this Internet electronic mail message by anyone
else is unauthorized. If you are not the intended recipient, any
disclosure, copying, distribution or any action taken or omitted to be taken
in reliance on it is prohibited and may be unlawful.
The sender believes that this E-mail and any attachments were free of any
virus, worm, Trojan horse, and/or malicious code when sent. This message and
its attachments could have been infected during transmission. By reading
the message and opening any attachments, the recipient accepts full
responsibility for taking protective and remedial action about viruses and
other defects. Galileo International is not liable for any loss or damage
arising in any way from this message or its attachments.

@p5pRT
Copy link
Author

p5pRT commented Jul 28, 2003

From Haili.Ma@netiq.com

I have memory leaking problem when my application keeps creating perl
Interpreter and freeing it.
So far, the bug has not been fixed yet in Perl 5.6.1. and perl 5.8.0.

-----Original Message-----
From​: Widgery, Tom [mailto​:perlbug-followup@​perl.org]
Sent​: Monday, July 28, 2003 2​:23 PM
To​: Haili.Ma@​netiq.com
Subject​: Embedded memory problem [perl #22121]

Dear Experts.
I apologize if this is the incorrect email address to respond to this issue
at I have never delved so deeply into perl before.....

I am having a problem very similar to the one described in ticket #22121 I
am attaching an example of the code I am using. It is inside a rather big
loop and do not wish for you to be bothered with the multiple servers and
clients in this product. The basic code is thus....

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

static PerlInterpreter *my_perl;
int count;
int counter;
char *queue;
char *tempPop;
char *temp;
int i = 0;

EXTERN_C void xs_init _((void));

EXTERN_C void boot_DynaLoader _((CV* cv));

EXTERN_C void
xs_init(void)
{
char *file = __FILE__;
dXSUB_SYS;

/* DynaLoader is a special case */
newXS("DynaLoader​::boot_DynaLoader", boot_DynaLoader, file);
}

/***************************************************************************
*/
/* PERL Database interface subroutine, should return an array of queue names
*/
/***************************************************************************
*/
Perldatabase(char pseudo [6], char *queue)
{

dSP;
ENTER;
SAVETMPS;
PUSHMARK (SP);
XPUSHs (sv_2mortal (newSVpv (pseudo,6)));
PUTBACK;
perl_call_pv("database", G_ARRAY);
SPAGAIN;
count = POPi;
temp=queue;
while (count !=0)
{
tempPop = POPp;

memcpy (temp, tempPop, 10);
count--;
temp = temp+10;
}

PUTBACK;
FREETMPS;
LEAVE;
}

char* interface(char pseudo[6], char *queue)
{

char *my_argv[] = { "", "dataquery.pl"};
my_perl = perl_alloc();
perl_construct(my_perl);
perl_parse(my_perl, xs_init, 2, my_argv, (char **)NULL);

perl_run(my_perl);

Perldatabase(pseudo, queue);

perl_destruct (my_perl);
perl_free(my_perl);

return (queue);

}

And the perl script running looks like this

#!/perl5/bin/perl
use SDBM_File;
use POSIX;
use strict;

sub database
{
my ($pseudo) = @​_;

my %dbm;
my $db_file = "CTIC.dbm";
tie my %dbm, 'SDBM_File', $db_file, O_RDWR, 0; #open read only

my @​list=split ("__",$dbm{"$pseudo"});

untie my %dbm;

push( @​list, scalar( @​list ) );

return @​list;

}

This seems to cause a rather large memory leak - I have traced through this
line by line and can see that the perl_parse obtains a large amount of
memory but the perl_free doesn't seem to release any of it.
A little bit of background - we are retrieving a message from an MQ queue
and then sending it through the perl database to route it to another MQ
queue - it is a constantly running client i.e. it is always polling the MQ
queue to get new messages - so effectively this is a looping process.
We are running Perl 5.00503 on an AIX box under a Tuxedo environment.
My question is​: Is there anyway to fix this issue? Unfortunately if we
can't find a way to release this memory I am going to have to re-write
everything using another language!!!

My thanks for your time

I hope this can be resolved.

Tom

Tom Widgery
Ticketing Services
303 397 5949

The information in this electronic mail message is sender's business
Confidential and may be legally privileged. It is intended solely for the
addressee(s). Access to this Internet electronic mail message by anyone
else is unauthorized. If you are not the intended recipient, any
disclosure, copying, distribution or any action taken or omitted to be taken
in reliance on it is prohibited and may be unlawful.
The sender believes that this E-mail and any attachments were free of any
virus, worm, Trojan horse, and/or malicious code when sent. This message and
its attachments could have been infected during transmission. By reading
the message and opening any attachments, the recipient accepts full
responsibility for taking protective and remedial action about viruses and
other defects. Galileo International is not liable for any loss or damage
arising in any way from this message or its attachments.

@p5pRT
Copy link
Author

p5pRT commented Aug 5, 2003

From rgreab@fx.ro

"Widgery, Tom" wrote​:

This seems to cause a rather large memory leak - I have traced through this
line by line and can see that the perl_parse obtains a large amount of
memory but the perl_free doesn't seem to release any of it.

My question is​: Is there anyway to fix this issue? Unfortunately if we
can't find a way to release this memory I am going to have to re-write
everything using another language!!!

Please try your code with a perl configured with -Dusemultiplicity.
Teoretically you should have few or no leaks.

If you can't configure and use perl with -Dusemultiplicity, then check
perlembed(1) and perlhack(1) for the meaning of PL_perl_destruct_level
interpreter variable and PERL_DESTRUCT_LEVEL environment variable. The
example from perlembed.pod should be​:

while(1) {
  ...
  /* reset global variables here with PL_perl_destruct_level = 1 */
  PL_perl_destruct_level = 1;
  perl_construct(my_perl);
  ...
  /* clean and reset _everything_ during perl_destruct */
  PL_perl_destruct_level = 1;
  perl_destruct(my_perl);
  perl_free(my_perl);
  ...
  /* let's go do it again! */
}

--
Radu Greab

@p5pRT
Copy link
Author

p5pRT commented Aug 6, 2003

From Haili.Ma@netiq.com

Keep creating new perl interpreter and freeing it always causes me leaking.
The way I used is that creating perl interpreter once, save it and use it
next time.

-----Original Message-----
From​: Radu Greab [mailto​:perlbug-followup@​perl.org]
Sent​: Tuesday, August 05, 2003 3​:26 PM
To​: Haili.Ma@​netiq.com
Subject​: Re​: Embedded memory problem [perl #22121]

"Widgery, Tom" wrote​:

This seems to cause a rather large memory leak - I have traced through
this
line by line and can see that the perl_parse obtains a large amount of
memory but the perl_free doesn't seem to release any of it.

My question is​: Is there anyway to fix this issue? Unfortunately if we
can't find a way to release this memory I am going to have to re-write
everything using another language!!!

Please try your code with a perl configured with -Dusemultiplicity.
Teoretically you should have few or no leaks.

If you can't configure and use perl with -Dusemultiplicity, then check
perlembed(1) and perlhack(1) for the meaning of PL_perl_destruct_level
interpreter variable and PERL_DESTRUCT_LEVEL environment variable. The
example from perlembed.pod should be​:

while(1) {
  ...
  /* reset global variables here with PL_perl_destruct_level = 1 */
  PL_perl_destruct_level = 1;
  perl_construct(my_perl);
  ...
  /* clean and reset _everything_ during perl_destruct */
  PL_perl_destruct_level = 1;
  perl_destruct(my_perl);
  perl_free(my_perl);
  ...
  /* let's go do it again! */
}

--
Radu Greab

@p5pRT
Copy link
Author

p5pRT commented Sep 28, 2012

From @jkeenan

On Tue Aug 05 18​:16​:54 2003, Haili.Ma@​netiq.com wrote​:

Keep creating new perl interpreter and freeing it always causes me
leaking.
The way I used is that creating perl interpreter once, save it and use it
next time.

-----Original Message-----
From​: Radu Greab [mailto​:perlbug-followup@​perl.org]
Sent​: Tuesday, August 05, 2003 3​:26 PM
To​: Haili.Ma@​netiq.com
Subject​: Re​: Embedded memory problem [perl #22121]

"Widgery, Tom" wrote​:

This seems to cause a rather large memory leak - I have traced through
this
line by line and can see that the perl_parse obtains a large amount of
memory but the perl_free doesn't seem to release any of it.

My question is​: Is there anyway to fix this issue? Unfortunately if we
can't find a way to release this memory I am going to have to re-write
everything using another language!!!

Please try your code with a perl configured with -Dusemultiplicity.
Teoretically you should have few or no leaks.

If you can't configure and use perl with -Dusemultiplicity, then check
perlembed(1) and perlhack(1) for the meaning of PL_perl_destruct_level
interpreter variable and PERL_DESTRUCT_LEVEL environment variable. The
example from perlembed.pod should be​:

while(1) {
...
/* reset global variables here with PL_perl_destruct_level = 1 */
PL_perl_destruct_level = 1;
perl_construct(my_perl);
...
/* clean and reset _everything_ during perl_destruct */
PL_perl_destruct_level = 1;
perl_destruct(my_perl);
perl_free(my_perl);
...
/* let's go do it again! */
}

This ticket has been languishing for many years. It would benefit from
the attention of anyone good at dealing with memory leak issues or at
embedding Perl in C.

Thank you very much.
Jim Keenan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants