Hi Team,
We are working on migration of nsldap C sdk to OpenLDAP C sdk for our application client code.
We are using OpenLDAP 2.6.7.
As part of this migration, we are facing one issue related to Decoding Error while making ldap_search_ext_s API under load.
OpenLDAP C SDK API ldap_search_ext_s is giving -4 : Decoding error when we are making a search call to LDAP server (with SSL and without SSL) under load with multi threading.
Here are few log messages related to -4: decoding error
[10052/17636][ERROR]Error# '-4' during search: 'error: Decoding error' Search Query = '(cn=user1)' for server 'ldapserver1:10001'
[10052/15624][ERROR]Error# '-4' during search: 'error: Decoding error' Search Query = '(cn=user2)' for server 'ldapserver1:10001'
When we run the same load with NSLDAP, we are not getting any Decoding errors. Whenever we switch to OpenLDAP APIs and run the load, we are getting Decoding errors for few transactions under the load.
Could you please look into this and provide any solution available for this issue?
Thank you.
On Thu, Jan 08, 2026 at 10:28:11AM +0530, venugopal chinnakotla wrote:
OpenLDAP C SDK API ldap_search_ext_s is giving -4 : Decoding error when we are making a search call to LDAP server (with SSL and without SSL) under load with multi threading.
Here are few log messages related to -4: decoding error
[...]
Could you please look into this and provide any solution available for this issue?
Hi, check the data that's being sent back to you is valid search entries/responses etc.
As you are writing your application, check that you are aligned with the API documentation (manpages) as well. If you can produce a set up that reliably recreates the condition and everything in the documentation and protocol specs leads you to believe it's an OpenLDAP library or server bug, open a ticket at bugs.openldap.org and help the project with investigation and fixing.
Thanks,
Hi,
In our application, for LDAP Directory search operations, we are using single LDAP Handle. All threads shares this single/same LDAP Handle for all search operations. With OpenLDAP, if we use same LDAP handle for multiple threads, under the load some part of LDAP handle structure (especially ld_errno) is being shared across the threads. Due to this behavior from OpenLDAP library, we are getting -4: Decoding error.
Thread A is calling ldap_get_values API call. During ldap_get_values API call, we are trying to fetch attribute values from directory. If attribute value is empty or attribute is nor present in the directory server, OpenLDAP internal logic is updating ld_lderrno value to -4 (during ber_printf in getvalues.c at line:74).
Thread B is calling ldap_search_ext_s for user lookup using same LDAP Handle. During this call, while returning "return( ldap_result2error( ld, *res, 0 ) );" from search call, it checks for ld_errno value. As this value is set to 4 by Thread A, ldap_search_ext_s API is retuning with -4 error.
This is the synchronization or atomic operation issue. Under heavy load, at a particular point, sharing of ld_errno by two threads is causing the problem.
Could you please check this and provide any solution that is available? As, this became critical in our application, we are blocked here. After some research, we identified that ldap_dup API can be used to solve this issue in multi threading environment. But, we are looking for production level solution for this problem. Can we use ldap_dup() to fix this issue or any other fix/solution available? Please share your inputs.
c.venugopal521@gmail.com wrote:
Hi,
In our application, for LDAP Directory search operations, we are using single LDAP Handle. All threads shares this single/same LDAP Handle for all search operations. With OpenLDAP, if we use same LDAP handle for multiple threads, under the load some part of LDAP handle structure (especially ld_errno) is being shared across the threads. Due to this behavior from OpenLDAP library, we are getting -4: Decoding error.
Thread A is calling ldap_get_values API call. During ldap_get_values API call, we are trying to fetch attribute values from directory. If attribute value is empty or attribute is nor present in the directory server, OpenLDAP internal logic is updating ld_lderrno value to -4 (during ber_printf in getvalues.c at line:74).
Thread B is calling ldap_search_ext_s for user lookup using same LDAP Handle. During this call, while returning "return( ldap_result2error( ld, *res, 0 ) );" from search call, it checks for ld_errno value. As this value is set to 4 by Thread A, ldap_search_ext_s API is retuning with -4 error.
This is the synchronization or atomic operation issue. Under heavy load, at a particular point, sharing of ld_errno by two threads is causing the problem.
Could you please check this and provide any solution that is available? As, this became critical in our application, we are blocked here. After some research, we identified that ldap_dup API can be used to solve this issue in multi threading environment. But, we are looking for production level solution for this problem. Can we use ldap_dup() to fix this issue or any other fix/solution available? Please share your inputs.
The ldap_dup(3) manpage clearly states that it is to be used in a multithreaded environment. Particularly to enable consistent error handling.
openldap-technical@openldap.org
-
c.venugopal521＠gmail.com -
Howard Chu -
Ondřej Kuzník -
venugopal chinnakotla