0.4.1: Attempted "__bool__" operation on ASN.1 schema object

[jgehrcke]

Just observed an error with pyasn 0.4.1:

...
File "/opt/mesosphere/lib/python3.6/site-packages/ldap3/core/connection.py", line 1205, in start_tls
if self.server.tls.start_tls(self) and self.strategy.sync:  # for async connections _start_tls is run by the strategy
File "/opt/mesosphere/lib/python3.6/site-packages/ldap3/core/tls.py", line 244, in start_tls
result = connection.extended('1.3.6.1.4.1.1466.20037')
File "/opt/mesosphere/lib/python3.6/site-packages/ldap3/core/connection.py", line 1169, in extended
response = self.post_send_single_response(self.send('extendedReq', request, controls))
File "/opt/mesosphere/lib/python3.6/site-packages/ldap3/strategy/base.py", line 298, in send
self.connection.request = BaseStrategy.decode_request(message_type, request, controls)
File "/opt/mesosphere/lib/python3.6/site-packages/ldap3/strategy/base.py", line 623, in decode_request
result = extended_request_to_dict(component)
File "/opt/mesosphere/lib/python3.6/site-packages/ldap3/operation/extended.py", line 58, in extended_request_to_dict
return {'name': str(request['requestName']), 'value': bytes(request['requestValue']) if request['requestValue'] else None}
File "/opt/mesosphere/lib/python3.6/site-packages/pyasn1/type/base.py", line 290, in __bool__
return self._value and True or False
File "/opt/mesosphere/lib/python3.6/site-packages/pyasn1/type/base.py", line 199, in plug
raise error.PyAsn1Error('Attempted "%s" operation on ASN.1 schema object' % name)
pyasn1.error.PyAsn1Error: Attempted "__bool__" operation on ASN.1 schema object

Right now I unfortunately can't provide more context / more parts of the traceback.

[etingof]

This happens when you have a ASN.1 schema object (e.g. the one not carrying any payload) and attempt to operate on it:

i = Integer()
bool(i)

But that should work for a schema instance object:

i = Integer(1)
bool(i)

So the question is how to pinpoint that non-initialized ASN.1 data structure? We really need some more info. May be pyasn1 debugging?

[jgehrcke]

The caller was ldap3, and I have switched back to using pyasn1 0.3.7 with ldap3 2.4.

[etingof]

Can you advise how could I reproduce this with ldap3?

Or a little more of a stack trace revealing from where in ldap3 pyasn1 was called...?

[jgehrcke]

Or a little more of a stack trace

I have added more (edited the post above). There was no reason to not show that earlier, my mistake.

[etingof]

Now my guess is that you are using some older ldap3 version which was designed to work with older pyasn1. The newer ldap3 versions accommodate both old and contemporary pyasn1 releases.

In other words, it seems that you somehow ended up with an incompatible ldap3 <-> pyasn1 version combination.

This conclusion is based on this observation.

Having said that, could you upgrade ldap3 and give it another try? ;-)