Re: (ITS#5522) Quarantine causes segmentation fault
by quanah＠zimbra.com
--On Thursday, May 22, 2008 3:11 PM +0000 andrew.graham(a)agustawestland.com
wrote:
> Full_Name: Drew Graham
> Version: 2.4.9
> OS: SUSE 10
> URL:
> Submission from: (NULL) (194.169.32.250)
> *******************
>
> Slapd then exits with Segmentation Fault. Gdb shows...
This bug has been patched by Pierangelo in HEAD, and it will be in the
2.3.42 and 2.4.10 releases.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years
Re: (ITS#5518) Assertion error in io.c:234: ber_flush2
by paul＠mad-scientist.us
Hi all; I just posted a new bug 5525 that describes exactly how this
happens and where the bug is. I came to this conclusion while trying to
find a crasher in Evolution Exchange: I ran it under valgrind to find
the use of freed memory.
Hopefully this will provide us with a quick fix!
15 years
(ITS#5525) libldap causes a core dump due to accessing freed memory
by paul＠mad-scientist.us
Full_Name: Paul Smith
Version: 2.4.7
OS: Ubuntu 8.04
URL:
Submission from: (NULL) (65.78.30.67)
I've been trying to track down a crasher in Evolution's Exchange server backend,
and I believe it's a bug in OpenLDAP's libldap. The core manifests as an
assert() in io.c:ber_flush2(), but by using valgrind I can see that the real
problem is using already-freed memory.
You can see various backtraces and valgrind outputs in the Gnome bug tracking
system here: http://bugzilla.gnome.org/show_bug.cgi?id=512605 Note that the
later stack traces are better as I've installed debugging versions of OpenLDAP
so there are better symbols shown.
In Evolution we have a loop we use to look up global contacts, which looks like
this:
for (try = 0; try < 2; try++) {
ldap_error = get_gc_connection (gc, op);
if (ldap_error != LDAP_SUCCESS)
return ldap_error;
ldap_error = ldap_search_ext (gc->priv->ldap, base, scope,
filter, (char **)attrs,
FALSE, NULL, NULL, NULL, 0,
&msgid);
if (ldap_error == LDAP_SERVER_DOWN)
continue;
else if (ldap_error != LDAP_SUCCESS)
return ldap_error;
ldap_error = gc_ldap_result (gc->priv->ldap, op, msgid, msg);
if (ldap_error == LDAP_SERVER_DOWN)
continue;
else if (ldap_error != LDAP_SUCCESS)
return ldap_error;
return LDAP_SUCCESS;
}
where get_gc_connection() eventually calls ldap_ntlm_bind() and where
gc_ldap_result() calls ldap_result(). When the core happens, the first trip
through the for loop here gives an error LDAP_SERVER_DOWN as the return code
from ldap_result(). We go back to the top of the loop, and ldap_ntlm_bind() is
called. That eventually ends up in ldap_send_initial_request() which invokes
ldap_send_server_request() like this:
rc = ldap_send_server_request( ld, ber, msgid, NULL,
NULL, NULL, NULL );
Inside ldap_send_server_request() we need to find an LDAPConn* structure, but
the one passed in is NULL as is the srvlist, so, we use the default connection:
if ( lc == NULL ) {
if ( srvlist == NULL ) {
lc = ld->ld_defconn;
Valgrind reports that the very next line, attempting to access lc->lconn_status,
is referencing freed memory:
if ( lc != NULL && lc->lconn_status == LDAP_CONNST_CONNECTING ) {
So, basically, we know that ld->ld_defconn is a non-NULL pointer pointing to
already freed memory. This seems like it is a buggy state.
How did we get here? In ldap_result() we get into this loop invoking
try_read1msg() (I'm removing the mutex locking for readability, even though it
IS enabled in my version of libldap):
for ( lc = ld->ld_conns;
rc == LDAP_MSG_X_KEEP_LOOKING && lc != NULL; )
{
if ( lc->lconn_status == LDAP_CONNST_CONNECTED &&
ldap_is_read_ready( ld, lc->lconn_sb ) )
{
rc = try_read1msg( ld, msgid, all, &lc, result );
if ( lc == NULL ) {
/* if lc gets free()'d,
* there's no guarantee
* lc->lconn_next is still
* sane; better restart
* (ITS#4405) */
lc = ld->ld_conns;
/* don't get to next conn! */
break;
}
}
/* next conn */
lc = lc->lconn_next;
}
Inside try_read1msg() we call "tag = ber_get_next( lc->lconn_sb, &len, ber );"
and if the tag we get back is LBER_DEFAULT, then we declare an error and we free
the connection and set the pointer to NULL:
case LBER_DEFAULT:
ld->ld_errno = LDAP_SERVER_DOWN;
ldap_free_connection( ld, lc, 1, 0 );
lc = *lcp = NULL;
return -1;
If you check ldap_free_connection() you'll see that it removes the LDAPConn
pointer "lc" from the list of connections before it is freed.
BUT! The ldap_free_connection() function never does anything with the
ld->ld_defconn pointer, so if the connection we just freed is the one pointed to
by ld->ld_defconn, it is now pointing to freed memory. And that causes the
problem detected above by valgrind, or causing an assert later on: accessing
freed memory.
I'm not really sure what the right thing to do here is, or I'd provide a patch.
Should we set ld_defconn to NULL? Is that ever a valid state? Or should we
just pick another connection from the list (and what if there isn't one?)
15 years
Re: (ITS#5523) BDB 4.7 support
by hyc＠symas.com
hyc(a)symas.com wrote:
> Hooray, they've finally got a partitioned lock manager. The lock subsystem has
> always been a huge bottleneck in previous releases...
(Relatively speaking. Back in OpenLDAP 2.0 we had plenty of other problems,
but today most of those are gone, and BerkeleyDB's lock manager is quite
conspicuous in current profile results...)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years
(ITS#5522) Quarantine causes segmentation fault
by andrew.graham＠agustawestland.com
Full_Name: Drew Graham
Version: 2.4.9
OS: SUSE 10
URL:
Submission from: (NULL) (194.169.32.250)
I've set up a meta directory with openldap, which has worked flawlessly
until now. If I set the 'quarantine' directive slapd fails to start,
giving a segmentation fault. This occurs every time I use quarantine, on
two different distros, on any version of openldap that I've tested
(2.3.39, 2.3.41, 2.4.9), with both my usual config file and a very
simple config file.
As an example, I built openldap 2.4.9 on suse 10 with the following
configure line...
# ./configure --prefix=/usr/local/ldap3 --enable-meta --enable-ldap
Slapd.conf looks like...
*******************
include /usr/local/ldap/etc/openldap/schema/core.schema
include /usr/local/ldap/etc/openldap/schema/cosine.schema
include /usr/local/ldap/etc/openldap/schema/inetorgperson.schema
pidfile /usr/local/ldap/var/run/slapd.pid
argsfile /usr/local/ldap/var/run/slapd.args
database meta
suffix "dc=example,dc=com"
rootdn "cn=manager,dc=example,dc=com"
rootpw "secret"
quarantine 1800,3
uri "ldap://ldap.example.com/dc=example,dc=com"
*******************
Obviously my normal config looks nothing like this, but running this
config gets the same result.
the last few lines that slapd will output with full debug gives...
******************
line 9 (pidfile /usr/local/ldap/var/run/slapd.pid)
line 9 (pidfile /usr/local/ldap/var/run/slapd.pid)
line 9 (pidfile /usr/local/ldap/var/run/slapd.pid)
line 10 (argsfile /usr/local/ldap/var/run/slapd.args)
line 13 (database meta)
line 14 (suffix "dc=example,dc=com")
>>> dnPrettyNormal: <dc=example,dc=com>
=> ldap_bv2dn(dc=example,dc=com,0)
<= ldap_bv2dn(dc=example,dc=com)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(dc=example,dc=com)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(dc=example,dc=com)=0
<<< dnPrettyNormal: <dc=example,dc=com>, <dc=example,dc=com>
line 16 (rootdn "cn=manager,dc=example,dc=com")
>>> dnPrettyNormal: <cn=manager,dc=example,dc=com>
=> ldap_bv2dn(cn=manager,dc=example,dc=com,0)
<= ldap_bv2dn(cn=manager,dc=example,dc=com)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=manager,dc=example,dc=com)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=manager,dc=example,dc=com)=0
<<< dnPrettyNormal: <cn=manager,dc=example,dc=com>,
<cn=manager,dc=example,dc=co
m>
line 17 (rootpw ***)
line 19 (quarantine 1800,3)
*******************
Slapd then exits with Segmentation Fault. Gdb shows...
******************
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211279696 (LWP 19080)]
0x081296d0 in ?? ()
******************
Thanks is advance!
Drew Graham
15 years
Segmentation fault with quarantine
by Andrew Graham
*** Before acting on this email or opening any attachment you are advised to read the disclaimer at the end of this email ***
I've set up a meta directory with openldap, which has worked flawlessly
until now. If I set the 'quarantine' directive slapd fails to start,
giving a segmentation fault. This occurs every time I use quarantine, on
two different distros, on any version of openldap that I've tested
(2.3.39, 2.3.41, 2.4.9), with both my usual config file and a very
simple config file.
As an example, I built openldap 2.4.9 on suse 10 with the following
configure line...
# ./configure --prefix=/usr/local/ldap3 --enable-meta --enable-ldap
Slapd.conf looks like...
*******************
include /usr/local/ldap/etc/openldap/schema/core.schema
include /usr/local/ldap/etc/openldap/schema/cosine.schema
include
/usr/local/ldap/etc/openldap/schema/inetorgperson.schema
pidfile /usr/local/ldap/var/run/slapd.pid
argsfile /usr/local/ldap/var/run/slapd.args
database meta
suffix "dc=example,dc=com"
rootdn "cn=manager,dc=example,dc=com"
rootpw "secret"
quarantine 1800,3
uri "ldap://ldap.example.com/dc=example,dc=com"
*******************
Obviously my normal config looks nothing like this, but running this
config gets the same result.
the last few lines that slapd will output with full debug gives...
******************
line 9 (pidfile /usr/local/ldap/var/run/slapd.pid)
line 9 (pidfile /usr/local/ldap/var/run/slapd.pid)
line 9 (pidfile /usr/local/ldap/var/run/slapd.pid)
line 10 (argsfile /usr/local/ldap/var/run/slapd.args)
line 13 (database meta)
line 14 (suffix "dc=example,dc=com")
>>> dnPrettyNormal: <dc=example,dc=com>
=> ldap_bv2dn(dc=example,dc=com,0)
<= ldap_bv2dn(dc=example,dc=com)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(dc=example,dc=com)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(dc=example,dc=com)=0
<<< dnPrettyNormal: <dc=example,dc=com>, <dc=example,dc=com>
line 16 (rootdn "cn=manager,dc=example,dc=com")
>>> dnPrettyNormal: <cn=manager,dc=example,dc=com>
=> ldap_bv2dn(cn=manager,dc=example,dc=com,0)
<= ldap_bv2dn(cn=manager,dc=example,dc=com)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=manager,dc=example,dc=com)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=manager,dc=example,dc=com)=0
<<< dnPrettyNormal: <cn=manager,dc=example,dc=com>,
<cn=manager,dc=example,dc=co
m>
line 17 (rootpw ***)
line 19 (quarantine 1800,3)
*******************
Before exiting with Segmentation Fault. Gdb shows...
******************
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211279696 (LWP 19080)]
0x081296d0 in ?? ()
******************
Is this a bug or some mistake I'm making?
Thanks is advance!
Drew Graham
*** Disclaimer ***
The information contained in this E-Mail and any subsequent correspondence may be subject to the Export Control Act (ECA) 2002. The content is private and is intended solely for the recipient(s).
For those other than the recipient any disclosure, copying, distribution, or action taken, or omitted to be taken, in reliance on such information is prohibited and may be unlawful.
If received in error please return to sender immediately.
Under the laws of England misuse of information that is subject to the ECA 2002, is a criminal offence.
Westland Helicopters Ltd
Lysander Road
Yeovil BA20 2YB
England
Registered in England under No 604352
15 years
