Memory/socket allocation problems

RESOLVED FIXED

Status

Directory
PerLDAP
P1
major
RESOLVED FIXED
19 years ago
18 years ago

People

(Reporter: Leif Hedstrom, Assigned: Kevin McCarthy)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
From: Kevin Stussman <stussman@ms.com>


There seems to be a memory de-allocation problem with the search method
in
the Mozilla::LDAP::Conn package. My guess is that when search is called
and
a valid entry is found in LDAP, the returned blessed ref
'Mozilla::LDAP::Entry' object
does not get de-allocated (either via DESTROY or by one of your memfree
C API routines).

Here is a simple module that demostrates the problem:

------------------------------------------------------------------------

package TESTER;

use lib '/ms/user/s/stussman/2.0/Libraries/';
use Carp;
use Common qw(LDAP_HOST LDAP_PORT) ;
use Mozilla::LDAP::Conn;
use strict;


sub new
{
 my $class = shift;
 my $self = {};

 return bless $self, $class;
}

sub doit
{
 my $conn;

 $conn = new Mozilla::LDAP::Conn(LDAP_HOST,LDAP_PORT,"","","");
 croak "No Conn" unless ($conn);

 $conn->search
      (
       'o=morgan stanley',
       "subtree",
       "(uid=stussman)",
       0,
       qw(pagerphone mail objectclass)
      );

 carp "ERROR: LDAP Search Error: ".$conn->printError if
$conn->getErrorCode;
}


1;

------------------------------------------------------------------------

Notice that I do not even assign the result of the search to a variable.
This should cause the blessed ref returned by the search method to
destroy the returned Entry reference. I believe it does not.. Also, if
the filter does not
match (i.e. (uid=nosuchentry)) then the memory leak does not appear.

Here is the caller routine:

------------------------------------------------------------------------

use lib '/ms/user/s/stussman/2.0/Libraries/TEST';
use TESTER;

while(1)
{
 my $a = new TESTER;
 $a->doit();
}

------------------------------------------------------------------------

Please feel free to email me back with any questions or comments.


Regards,

Kevin Stussman

BTW, I have tried this with perl versions 5.004 through 5.005_02 and I
believe the Mozilla::LDAP::API version is 1.1
(Reporter)

Updated

19 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 1

19 years ago
More from Kevin:

A side effect (or perhaps the same problem?) of this memory leak is that
the socket
does not get released. The socket does not seem to close properly (it
takes about
2 minutes) and I run out of sockets for Conn. I thought this may be OS
related
(Solaris 2.5.1..like SO_LINGER or something) but if you are creating a
client socket,
I don't think this applies. This does not happen if the search does not
return an Entry.

If you can re-create the leak, check the netstat -a command for stale
sockets.

Kevin Stussman

(here is a sample netstat...)

[...snip...]
condor.3773          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3774          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3775          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3776          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3777          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3778          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3779          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3780          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3781          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3782          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3783          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3784          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3785          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3839          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.4794          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.1172          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.1969          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.1970          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.1977          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.1986          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.2273          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3788          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3789          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3790          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3791          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3792          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3793          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3794          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3795          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3796          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3797          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3798          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3799          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3800          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3801          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3802          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3803          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3804          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3805          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3806          samail3.ldap          8760      0  8760      0
TIME_WAIT
condor.3807          samail3.ldap          8760      0  8760      0
TIME_WAIT
(Reporter)

Updated

19 years ago
Severity: normal → major
Priority: P1 → P2

Comment 2

19 years ago
Setting all current Open Critical and Major to M3

Comment 3

19 years ago
Clearing "M" field since Directory product is not used for 5.0 specific project
bug metrics and will mess up our queries on milestones.
(Reporter)

Updated

19 years ago
Assignee: leif → kmccarth
Status: ASSIGNED → NEW
Priority: P2 → P1
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 4

18 years ago
The memory leak was caused by the self-reference in Entry.pm combined with no
DESTROY()to remove the self-reference.

This has been fixed in 1.3

I can't duplicate the client socket not being closed.  I get proper socket reuse
with PerLDAP 1.0 as well as the most recent 1.3.  [The socket has nothing to due
with the Entry.pm]  I'll close this for now and if it crops up again, we can
open another bug.
You need to log in before you can comment on or make changes to this bug.