Re: ldapmodule 1.9alpha

[David L. <dav...@cs...>]

On Fri, 11 Aug 2000, Dr. Ross Lazarus typed thusly:

> Just lately, I've been trying to track down a very aggravating memory
> leak in a big zope application I've built here. It's now a serious
> production system and the leak is steady and annoying.
> 
> I'm pretty sure that there's at least part of this leak in the above
> version of ldapmodule which I've been using for all sorts of things.
> Sadly, I just don't have the skills to track it down! 
> 
> I'm using openldap 1.2.11 (openldap-stable-20000704.tgz) and
> ldapmodule-1.9-alpha.tar.gz
> 
> To confirm the leak, I wrote an extremely dumb python script which just
> calls a useful ldap function repeatedly and keeps track of the number of
> iterations - try the attached code (please change the gory details to a
> local ldap server !!). 

wow! someone who has actually bothered to track down a leak! :)

> It leaks something like 5 bytes per cn_is call
> (open,simplebind_s,search_s,unbind_s) - this is a bit of a guess from
> noting that the process grows something of the order of 26000 bytes in
> size after about 5000 calls. I don't think it's 4 or 6 bytes per
> sequence although the margin for error is large because I'm watching top
> - might be easy to make it more accurate if needed..
> 
> You may already know about this?

i have had it mentioned, but since i'm not as into ldap as i once was, i have
to set up a server to test it out.. i kind of rely on other people to check
these things, or i use a public ldap server to test simple stuff out on
(but my favourite ones seem to have disappeared these days)

> Ah, refcounts...
> 
> I know that 4 bytes per call isn't much...but I'm doing a lot of ldap
> calls.. 

thats great! i will have to check it out a lot more carefully...

btw if you want to do some more checking, the sys.getrefcount() method
returns the number of reference counts on an object (plus 2)

	>>> sys.getrefcount(176271627861827618726817L)
	2
	>>> sys.getrefcount(None)
	141

it can be handy if you can see the reference count going up and up on
one particular object...

alternatively, it could be a memory leak in the ldap library itself... :(

> Is python-ldap ready for production use? I had a quick look but stopped
> short of doing a cvs checkout and build....
> Any suggestions welcomed...

well.... it has a few fixes. its got some expermental template code in there
(that coredumps) but if you dont touch it, it wont bite you :)

mmm, production. there are no guarantees or warranties...

i'm also trying to get time to add ssl support and track other changes to
openldap-2.0a. but then i have to start getting into gear to submit a thesis 
soon so that will probably be a big time of silence.

i'd like to get a next release out really soon, so if i build a tarball, would
you please test it out??

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401