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
|
