Closed
Bug 1983
Opened 26 years ago
Closed 25 years ago
Memory/socket allocation problems
Categories
(Directory :: PerLDAP, defect, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: leif, Assigned: kmccarth)
Details
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•26 years ago
|
Status: NEW → ASSIGNED
|
|
Reporter | |
Comment 1•26 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•26 years ago
|
Severity: normal → major
Priority: P1 → P2
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•25 years ago
|
Assignee: leif → kmccarth
Status: ASSIGNED → NEW
Priority: P2 → P1
|
Assignee | |
Updated•25 years ago
|
Status: NEW → ASSIGNED
|
|
Assignee | |
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
|
|
Assignee | |
Comment 4•25 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.
Description
•