RE: Crash in ldap_unbind()

> -----Original Message-----
> From: 
> [email protected]
>  
> [mailto:[email protected]
> illa.org] On Behalf Of [email protected]
> Sent: Thursday, April 30, 2009 8:34 AM
> To: [email protected]
> Subject: Crash in ldap_unbind()
> 
> We are using Mozilla 6.0.5 C SDK. When the LDAP server has a 
> short timeout (10 seconds) for the connections, we are 
> experiencing consistent crash after calling ldap_unbind(). 
> Our investigation shows that the crash is caused by the use 
> of freed memory. There are multiple references to the same 
> memory. After one is used to free the memory, others are 
> still used to access that memory.
> 
> Here is how the multiple references to the same memory are created.
> When the connection is dropped by LDAP server, we call
> ldap_simple_bind_s() to reconnect. This ultimately calls into 
> nsldapi_new_connection(), which has the following code:
> 
> 	lc->lconn_next = ld->ld_conns;
> 	ld->ld_conns = lc;
> 
> This adds a new connection to the LDAP handle which already 
> has a connection. The problem is that both of these two 
> connections reference the same memory through their 
> respective lbextiofn_socket_arg field.

When the connection is dropped by LDAP server, have you called ldap_unbind() to destroy the handler? And, since you call ldap_simple_bind_s() to do the binding, you'd better call ldap_unbind_s() to release the handle, instead of ldap_unbind().
 
> Later on,we call ldap_unbind() on the LDAP handle. Down the stack,
> ldap_ld_free() has the following code:
> 
> 		while ( ld->ld_conns != NULL ) {
> 			nsldapi_free_connection( ld, 
> ld->ld_conns, serverctrls,
> 			    clientctrls, 1, close );
> 		}
> 
> Ldap_ld_free() is trying to free each connection on the LDAP handle.
> The first iteration frees the memory pointed by 
> lbextiofn_socket_arg, the second iteration tries to use it in 
> nsldapi_close_connection() and causes crash.
> 
> Hopefully I explained clearly the cause of the problem. 
> Please advise how this problem can be fixed.
> 
> Thanks,
> Yang