Open fd:s in garbage is very bad. Do you think you could make an attempt at locating the cyclic structure? In cases like this I usually do
call_out (_locate_references, 30, suspect_object);
where suspect_object in your case is a Protocol.LDAP.client object and 30 is a time large enough so that the object ought to be gone by then. If everything is as it should be, the only ref to it is from the call out itself, so your suspect refs are those other than that which _locate_references reports. Note that rtldebug is necessary to get _locate_references.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-06-04 16:37: Subject: Re: Stdio.File sockets not getting closed in 7.6
I wish I could say that was it, but I'm not using ldaps. I'm not completely sure where the problem crept in; a periodic gc() makes it livable, if not great.
Bill
On Wed, 26 May 2004, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
That could be my doing in revision 1.54, provided you get it with ldaps. It gave SSL.sslfile an Fd object, which it doesn't take (never has, not even in the old implementation).
Since Stdio.File is inherited, the correct argument therefore is this, which makes a nice cycle since it's stored back in ldapfd in protocol.pike. That inherit looks bogus to me, but since I don't know the territory I only fixed the type error.
/ Martin Stjernholm, Roxen IS
/ Brevbäraren