[python-ldap] AttributeError: ReconnectLDAPObject has no attribute '_l'

[Michael Ströder]

Florian Best wrote:
> As there doesn't seem to be a bug reporting system, I will post to this
> mailing list.

Right!

> I got the following traceback:
> [..]
>   File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 136, in 
> __getattr__
>     self.__class__.__name__,repr(name)
> AttributeError: ReconnectLDAPObject has no attribute '_l'
> 
> I have two assumtions about this, but I am not completely sure as this is
> only a traceback reported by one of our customers and I couldn't properly
> reproduce it. Maybe you have another explanation.

Which python-ldap version is this?

In recent python-ldap release the unbind_ext() method looks like this (long
lines wrapped):

  def unbind_ext(self,serverctrls=None,clientctrls=None):
    """
    [..]
    """
    res =
self._ldap_call(self._l.unbind_ext,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls))
    try:
      del self._l
    except AttributeError:
      pass
    return res

Not sure when this try-except-block was added (probably by me) though.

> The first, more probable reason is because unbind_s() is called twice: During
> the reconnection SimpleLDAPObject.unbind_s() is called first in 
> _apply_method_s() and second in reconnect() while the server is still down.
> The second call would cause that SimpleLDAPObject.unbind_s() calls a method
> which uses self._l while reconnect() already removed self._l.

There have been numerous fixes to ReconnectLDAPObject for various subtle issues.
I vaguely remember that the one above was one of them.

In short: Use recent release 2.4.28.
Probably relevant for you: The Debian folks added 2.4.28 to Debian testing.

> (The second thing I could imagine would be If two threads use the same object,
> this can happen during the reconnection?)

Should not happen because locks are used. But I'd recommend to use separate
ReconnectLDAPObject instance per thread anyway.

> I attached a patch which maybe prevent this, as _l is not removed anymore from
> the namespace of that object.

Which is definitely the wrong approach because LDAPObject._l is not usable at
that time anymore.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20170105/ec2997aa/attachment-0001.bin>