Re: (ITS#6880) SECURITY: ldap_free_urllist segfault
by Howard Chu
> Full_Name: Marcus Rottensteiner
> Version: 2.4.24
> OS: gentoo
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (188.20.205.34)
>
>
> running a php program, openldap 2.4.24 has a problem in libldap_r-2.4.so.2
>
> in conjunction with php 5.3 (tested 5.3.5 , 5.3.6) ?
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff39bcb4b in ldap_free_urllist () from /usr//lib/libldap-2.4.so.2
> (gdb) backtrace
> #0 0x00007ffff39bcb4b in ldap_free_urllist () from /usr//lib/libldap-2.4.so.2
> #1 0x00007ffff1a60c1b in ?? () from /usr/lib64/libldap_r-2.4.so.2
> #2 0x00007ffff1a4680e in ?? () from /usr/lib64/libldap_r-2.4.so.2
> #3 0x0000000000000030 in ?? ()
> #4 0x0000000000000000 in ?? ()
>
> Reverting to openldap 2.4.23 does not cause a problem !
Your trace shows that both libldap and libldap_r are present. Your PHP is built
incorrectly. You cannot link both libraries into the same program; they are not
compatible. Closing this ITS.
11 years, 9 months
Re: (ITS#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by hyc＠symas.com
hyc(a)symas.com wrote:
> ipuleston(a)SonicWALL.com wrote:
>> The patch that I submitted above has a memory leak due not freeing "ber"
> when returning error LDAP_X_CONNECTING from function
> ldap_send_initial_request(). I have uploaded a new version of the patch with
> this fixed to ftp.openldap.org/incoming as ian-puleston-110412.patch.2 (note
> the .2 on the end - it was a 2nd attempt after I forgot to specify ASCII mode).
>
> Unfortunately the patch was made against 2.4.23 and not against HEAD. It does
> not apply cleanly to current git. Patches must always be submitted against the
> development code, not against released code.
I've committed an alternate patch to git master.
>
> I'm pretty sure that this chunk can never do anything useful.
>
> diff -u libldap.orig/request.c libldap/request.c
> --- libldap.orig/request.c 2010-06-10 10:39:48.000000000 -0700
> +++ libldap/request.c 2011-04-12 12:11:20.769166100 -0700
> @@ -446,7 +462,21 @@
> lc->lconn_server = ldap_url_dup( srv );
> }
>
> - lc->lconn_status = async ? LDAP_CONNST_CONNECTING : LDAP_CONNST_CONNECTED;
> + if ( async ) {
> +#ifdef HAVE_TLS
> + void *ssl = NULL;
> + ber_sockbuf_ctrl( lc->lconn_sb, LBER_SB_OPT_GET_SSL, (void *)&ssl );
> + if ( ssl ) {
> + /* the connect finished and tls was started */
> + lc->lconn_status = LDAP_CONNST_CONNECTED;
> + } else
> +#endif
> + {
> + lc->lconn_status = LDAP_CONNST_CONNECTING;
> + }
> + } else {
> + lc->lconn_status = LDAP_CONNST_CONNECTED;
> + }
> #ifdef LDAP_R_COMPILE
> ldap_pvt_thread_mutex_lock(&ld->ld_conn_mutex );
> #endif
>
> The connection has just been created, asynchronously, so there's no way that
> the TLS layer was already started when it got here. Also, even if this was
> valid, it obviously would only apply for OPT_X_TLS_HARD || ldaps, but you
> haven't checked that condition here. Ultimately it appears that this test is a
> no-op.
>
> Also, I suggest that you only check for CONNST_CONNECTING in the callers, and
> do the TLS check in the check function, like this:
>
> +int
> +ldap_int_check_async_open( LDAP *ld, LDAPConn *lc, LDAPURLDesc *srv,
> ber_socket_t sd )
> +{
> + struct timeval tv = { 0 };
> + int rc;
> +
> + rc = ldap_int_poll( ld, sd,&tv );
> + switch ( rc ) {
> + case 0:
> + /* now ready to start tls */
> + lc->lconn_status = LDAP_CONNST_CONNECTED;
> + break;
> +
> + default:
> + rc = -1;
> + return rc;
> + case -2:
> + /* connect not completed yet */
> + ld->ld_errno = LDAP_X_CONNECTING;
> + return rc;
> + }
> +
> +#ifdef HAVE_TLS
> + if ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD ||
> + !strcmp( srv->lud_scheme, "ldaps" )) {
> +
> + ++lc->lconn_refcnt; /* avoid premature free */
> +
> + rc = ldap_int_tls_start( ld, lc, srv );
> +
> + --lc->lconn_refcnt;
> + }
> +#endif
> + return rc;
> +}
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 9 months
Re: (ITS#6671) multi-master replication fails to delete objects from consumer
by hyc＠symas.com
bcolston(a)xtec.com wrote:
> Full_Name: Barry Colston
> Version: 2.4.23
> OS: Fedora 10
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (209.255.208.200)
I'm looking at your test case now. One thing to note, serverIDs must all be
non-zero in a multi-master configuration. serverID == 0 is only valid in
single-master replication.
> When a "Refresh Present" phase is performed at a multi-master consumer, objects
> that were deleted at the provider
> while the consumer was down are not deleted from the multi-master consumer (if
> the provider is brought down and back up after the consumer is down). This
> problem can be duplicated as follows:
> 1. Start provider
> 2. Start consumer, which is configured as a multi-master server
> 3. Add 10 records to the provider and wait until the records are replicated to
> the multi-master consumer
> 4. Stop the consumer
> 5. Delete 3 of the records that were added to the provider
> 6. Stop the provider
> 7. Start the provider
> 8. Start the consumer
> 9. After giving the consumer time to perform the refresh present phase, the 3
> records that were deleted at the provider while the consumer was down
> are still present on the consumer and were not deleted during the refresh
> present phase
>
> Note: the consumer database must have a contextCSN attribute value present for
> itself (e.g., there should be 2 contextCSN attribute values
> present in the consumer database, one for the provider (in my configuration,
> this is serverID 000), and one value for the consumer
> (in my configuration, this is serverID 001). An example of the contextCSN
> values follows:
>
> dn: dc=authentx
> objectClass: top
> entryUUID: 8eb6b259-ab66-49bd-b012-674c4f0fba8f
> contextCSN: 20101012154030.379053Z#000000#000#000000
> contextCSN: 20101012141508.956053Z#000000#001#000000
>
> OpenLDAP 2.4.23 is being used, along with Berkeley 4.6.21 (plus patches).
>
> Consumer log file from -d sync logging option:
> @(#) $OpenLDAP: slapd 2.4.23 (Oct 11 2010 18:00:59) $
> Barry@XTecVisaAdmin:/usr/src/openldap-2.4.23/servers/slapd
> slapd starting
> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT
> do_syncrep2: rid=001
> cookie=rid=001,csn=20101012180219.072053Z#000000#000#000000
> slap_queue_csn: queing 0x1841a30 20101012180219.072053Z#000000#000#000000
> slap_graduate_commit_csn: removing 0x1841b18
> 20101012180219.072053Z#000000#000#000000
> daemon: shutdown requested and initiated.
> slapd shutdown: waiting for 1 operations/tasks to finish
> slapd stopped.
>
> Provider slapd.conf file:
> #
> include /usr/local/etc/openldap/schema/core.schema
> include /usr/local/etc/openldap/schema/cosine.schema
> include /usr/local/etc/openldap/schema/inetorgperson.schema
> include /usr/local/etc/openldap/schema/nis.schema
>
> include /usr/local/etc/openldap/schema/authentx.schema
>
> pidfile /usr/local/var/slapd.sync1.pid
> argsfile /usr/local/var/slapd.sync1.args
>
> allow bind_v2
>
> threads 32
>
> #loglevel 416
> password-hash {SSHA}
>
> serverID 000
>
> database bdb
> suffix "dc=authentx"
> rootdn "cn=xroot,dc=authentx"
> rootpw SECRET
> directory /authentx/db/ldap/authentx-sync1
>
> overlay syncprov
> syncprov-checkpoint 100 15
> syncprov-sessionlog 150000
>
> # checkpoint<kbytes> <min>
> checkpoint 128 20
>
> #index for the objectclass
> index objectClass eq,pres
> index cid,eid,pid eq,pres
> index gcoid eq,pres
> index sysid,certid eq,pres
> index imageid,bioid eq,pres
> index addrid,emplid eq,pres
> index acid,apid,aeid eq,pres
> index acpid,agpid eq,pres
> index deviceid eq,pres
> index qid eq,pres
> index scid eq,pres
> index docid eq,pres
> index procid eq,pres
> index prochandlerid eq,pres
> index ounit eq,pres
> index credentials eq,pres
> index entities eq,pres
> index permissions eq,pres
> index region eq,pres
> index aliasedObjectName eq,pres
> index proctype eq,pres
> index procname eq,pres
> index status eq,pres
> index upi,ediident eq,pres
> index xsync eq,pres
> index role,xrole eq,pres
> index eroid eq,pres
> index esfunction eq,pres
> index nippsector eq,pres
> index ercog,ercoop eq,pres
> index eropron eq,pres
> index xsyncid eq,pres
> index stockid eq,pres
> index stocktypecode eq,pres
> index lotserialin eq,pres
> index lotserialout eq,pres
> index entryCSN,entryUUID eq
> index incl eq,pres
>
> cachesize 10000
> dncachesize 20000
> idlcachesize 1000
>
> sizelimit 500000
> timelimit 36000
> include /usr/local/etc/openldap/acl.authentx
>
> database monitor
>
> Consumer slapd.conf file:
> #
> include /usr/local/etc/openldap/schema/core.schema
> include /usr/local/etc/openldap/schema/cosine.schema
> include /usr/local/etc/openldap/schema/inetorgperson.schema
> include /usr/local/etc/openldap/schema/nis.schema
>
> include /usr/local/etc/openldap/schema/authentx.schema
>
> pidfile /usr/local/var/slapd.sync2.pid
> argsfile /usr/local/var/slapd.sync2.args
>
> allow bind_v2
>
> threads 32
>
> #loglevel 416
> password-hash {SSHA}
>
> serverID 001
>
> database bdb
> suffix "dc=authentx"
> rootdn "cn=xroot,dc=authentx"
> rootpw SECRET
> directory /authentx/db/ldap/authentx-sync2
>
> overlay syncprov
> syncprov-checkpoint 100 15
> syncprov-sessionlog 5000
>
> # SLAVE server replication section
> syncrepl rid=001
> provider=ldap://localhost:3891
> type=refreshAndPersist
> retry="30 60 60 +"
> searchbase="dc=authentx"
> scope=sub
> schemachecking=off
> bindmethod=simple
> binddn="cn=xroot,dc=authentx"
> credentials="SECRET"
>
> mirrormode on
>
> # checkpoint<kbytes> <min>
> checkpoint 128 20
>
> #index for the objectclass
> index objectClass eq,pres
> index cid,eid,pid eq,pres
> index gcoid eq,pres
> index sysid,certid eq,pres
> index imageid,bioid eq,pres
> index addrid,emplid eq,pres
> index acid,apid,aeid eq,pres
> index acpid,agpid eq,pres
> index deviceid eq,pres
> index qid eq,pres
> index scid eq,pres
> index docid eq,pres
> index procid eq,pres
> index prochandlerid eq,pres
> index ounit eq,pres
> index credentials eq,pres
> index entities eq,pres
> index permissions eq,pres
> index region eq,pres
> index aliasedObjectName eq,pres
> index proctype eq,pres
> index procname eq,pres
> index status eq,pres
> index upi,ediident eq,pres
> index xsync eq,pres
> index role,xrole eq,pres
> index eroid eq,pres
> index esfunction eq,pres
> index nippsector eq,pres
> index ercog,ercoop eq,pres
> index eropron eq,pres
> index xsyncid eq,pres
> index stockid eq,pres
> index stocktypecode eq,pres
> index lotserialin eq,pres
> index lotserialout eq,pres
> index entryCSN,entryUUID eq
> index incl eq,pres
>
> cachesize 10000
> dncachesize 20000
> idlcachesize 1000
>
> sizelimit 100000
> timelimit 36000
> # the authentx database access control directives
> include /usr/local/etc/openldap/acl.authentx
>
> database monitor
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 9 months
Re: (ITS#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by hyc＠symas.com
ipuleston(a)SonicWALL.com wrote:
> The patch that I submitted above has a memory leak due not freeing "ber"
when returning error LDAP_X_CONNECTING from function
ldap_send_initial_request(). I have uploaded a new version of the patch with
this fixed to ftp.openldap.org/incoming as ian-puleston-110412.patch.2 (note
the .2 on the end - it was a 2nd attempt after I forgot to specify ASCII mode).
Unfortunately the patch was made against 2.4.23 and not against HEAD. It does
not apply cleanly to current git. Patches must always be submitted against the
development code, not against released code.
I'm pretty sure that this chunk can never do anything useful.
diff -u libldap.orig/request.c libldap/request.c
--- libldap.orig/request.c 2010-06-10 10:39:48.000000000 -0700
+++ libldap/request.c 2011-04-12 12:11:20.769166100 -0700
@@ -446,7 +462,21 @@
lc->lconn_server = ldap_url_dup( srv );
}
- lc->lconn_status = async ? LDAP_CONNST_CONNECTING : LDAP_CONNST_CONNECTED;
+ if ( async ) {
+#ifdef HAVE_TLS
+ void *ssl = NULL;
+ ber_sockbuf_ctrl( lc->lconn_sb, LBER_SB_OPT_GET_SSL, (void *)&ssl );
+ if ( ssl ) {
+ /* the connect finished and tls was started */
+ lc->lconn_status = LDAP_CONNST_CONNECTED;
+ } else
+#endif
+ {
+ lc->lconn_status = LDAP_CONNST_CONNECTING;
+ }
+ } else {
+ lc->lconn_status = LDAP_CONNST_CONNECTED;
+ }
#ifdef LDAP_R_COMPILE
ldap_pvt_thread_mutex_lock( &ld->ld_conn_mutex );
#endif
The connection has just been created, asynchronously, so there's no way that
the TLS layer was already started when it got here. Also, even if this was
valid, it obviously would only apply for OPT_X_TLS_HARD || ldaps, but you
haven't checked that condition here. Ultimately it appears that this test is a
no-op.
Also, I suggest that you only check for CONNST_CONNECTING in the callers, and
do the TLS check in the check function, like this:
+int
+ldap_int_check_async_open( LDAP *ld, LDAPConn *lc, LDAPURLDesc *srv,
ber_socket_t sd )
+{
+ struct timeval tv = { 0 };
+ int rc;
+
+ rc = ldap_int_poll( ld, sd, &tv );
+ switch ( rc ) {
+ case 0:
+ /* now ready to start tls */
+ lc->lconn_status = LDAP_CONNST_CONNECTED;
+ break;
+
+ default:
+ rc = -1;
+ return rc;
+ case -2:
+ /* connect not completed yet */
+ ld->ld_errno = LDAP_X_CONNECTING;
+ return rc;
+ }
+
+#ifdef HAVE_TLS
+ if ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD ||
+ !strcmp( srv->lud_scheme, "ldaps" )) {
+
+ ++lc->lconn_refcnt; /* avoid premature free */
+
+ rc = ldap_int_tls_start( ld, lc, srv );
+
+ --lc->lconn_refcnt;
+ }
+#endif
+ return rc;
+}
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 9 months
RE: (ITS#6964) ./configure bug when specifying openssl as the TLS library to use
by the_uhu＠hotmail.com
--_845f4083-7211-40a8-bc3d-f1e94a6babb0_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I've just downloaded openldap stable fresh=2C opened up configure and this =
is at line 19408 without an if check:
LIBS=3D"-lssl -lcrypto -lRSAglue -lrsaref $LIBS"
Also checked the source repository on the website and it's there also.
Can you please double check?
Paul.
> Date: Wed=2C 8 Jun 2011 22:13:55 +0000
> From: openldap-its(a)OpenLDAP.org
> To: the_uhu(a)hotmail.com
> Subject: Re: (ITS#6964) ./configure bug when specifying openssl as the TL=
S library to use
>=20
> I don't know where your configure script came from=2C but there's nothing=
related
> to OpenSSL at line 19408 of the current released configure script=2C and =
our
> script has had logic to detect -lrsaref since 1999.
>=20
> Closing this ITS. Use the actual configure script supplied by the OpenLDA=
P
> Project.
=
--_845f4083-7211-40a8-bc3d-f1e94a6babb0_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
</head>
<body class=3D'hmmessage'>
I've just downloaded openldap stable fresh=2C opened up configure and this =
is at line 19408 without an if check:<br><br>LIBS=3D"-lssl -lcrypto -lRSAgl=
ue -lrsaref $LIBS"<br><br>Also checked the source repository on the website=
and it's there also.<br><br>Can you please double check?<br><br>Paul.<br><=
br><br>>=3B Date: Wed=2C 8 Jun 2011 22:13:55 +0000<br>>=3B From: openld=
ap-its(a)OpenLDAP.org<br>>=3B To: the_uhu(a)hotmail.com<br>>=3B Subject: Re=
: (ITS#6964) ./configure bug when specifying openssl as the TLS library to =
use<br>>=3B <br>>=3B I don't know where your configure script came from=
=2C but there's nothing related<br>>=3B to OpenSSL at line 19408 of the c=
urrent released configure script=2C and our<br>>=3B script has had logic =
to detect -lrsaref since 1999.<br>>=3B <br>>=3B Closing this ITS. Use t=
he actual configure script supplied by the OpenLDAP<br>>=3B Project.<br> =
</body>
</html>=
--_845f4083-7211-40a8-bc3d-f1e94a6babb0_--
11 years, 9 months
Re: (ITS#6878) ppcache segfault with tavl_delete
by tjgates＠castlebranch.com
----- "Howard Chu" <hyc(a)symas.com> wrote:
> Howard Chu wrote:
> > Tyler Gates wrote:
> >> After applying the patches for ITS #6848 and ITS #6898 I still get
> crashes.
> >> Here's the latest:
>
> ??? neither #6848 nor #6898 are relevant to pcache.
I figured probably not but thought it may be important to know in terms as this is not just a straight 2.4.25 build...
>
> I think you should try the RE24 branch at this point, as a number of
> other
> pcache-related fixes have been merged there.
Are you referring to OPENLDAP_REL_ENG_2_4 in the git tree?
I'm not sure if I'll have the time (work) to tackle that but I'll see what I can do.
> >
> > Looks like a double-free. Can you reproduce this consistently? If
> so, what are
> > the steps? can you run slapd under valgrind and reproduce this?
I can reproduce it consistently in terms that it crashes reliably after 2 to 4 days with 1 to 2 Linux hosts connected via pam-ldap account sessions. Other than that I've not been able to find a way to make it crash on demand. I do know it won't crash if it is run in the foreground with -d -1.
I'm running it now under valgrind, any options you are looking for in particular? I'll report back the next time it crashes and/or I can try RE24.
> >>
> >> Program received signal SIGABRT, Aborted.
> >> [Switching to Thread 0xae1edb70 (LWP 6121)]
> >> 0xb76e2430 in __kernel_vsyscall ()
> >> (gdb)
> >> (gdb)
> >> (gdb) bt
> >> #0 0xb76e2430 in __kernel_vsyscall ()
> >> #1 0xb71b4651 in *__GI_raise (sig=6) at
> >> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> >> #2 0xb71b7a82 in *__GI_abort () at abort.c:92
> >> #3 0xb71eb49d in __libc_message (do_abort=2, fmt=0xb72bff98 "***
> glibc
> >> detected *** %s: %s: 0x%s ***\n") at
> >> ../sysdeps/unix/sysv/linux/libc_fatal.c:189
> >> #4 0xb71f5591 in malloc_printerr (action=<value optimized out>,
> str=0x6
> >> <Address 0x6 out of bounds>, ptr=0xb9584e80) at malloc.c:6266
> >> #5 0xb71f6de8 in _int_free (av=<value optimized out>, p=<value
> >> optimized out>) at malloc.c:4794
> >> #6 0xb71f9ecd in *__GI___libc_free (mem=0xb9584e80) at
> malloc.c:3738
> >> #7 0xb768ac20 in ber_memfree_x () from /usr/lib/liblber-2.4.so.2
> >> #8 0xb768acaf in ber_bvarray_free_x () from
> /usr/lib/liblber-2.4.so.2
> >> #9 0xb768acf5 in ber_bvarray_free () from
> /usr/lib/liblber-2.4.so.2
> >> #10 0xb7743e5d in attr_clean (a=0xb6dcc06c) at
> >> /tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:148
> >> #11 0xb7743efb in attrs_free (a=0xb6dcc06c) at
> >> /tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:198
> >> #12 0xb6d84b7f in hdb_cache_modify (bdb=0xb9536e10, e=0xb94f1dac,
> >> newAttrs=0xb6dd6884, txn=0xb2176970, lock=0xae1ec930) at
> cache.c:1238
> >> #13 0xb6d7008c in hdb_modify (op=0xae1eccfc, rs=0xae1ecad0) at
> modify.c:662
> >> #14 0xb6d52e81 in remove_query_data (op=<value optimized out>,
> >> query_uuid=<value optimized out>)
> >> at
> /tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:1829
> >> #15 0xb6d53d0b in consistency_check (ctx=0xae1ed1dc,
> arg=0xb955e018) at
> >> /tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:3520
> >> #16 0xb769d8b4 in ?? () from /usr/lib/libldap_r-2.4.so.2
> >> #17 0xb72e996e in start_thread (arg=0xae1edb70) at
> pthread_create.c:300
> >> #18 0xb7257a4e in clone () at
> ../sysdeps/unix/sysv/linux/i386/clone.S:130
> >> (gdb) continue
> >> Continuing.
> >> [Thread 0xaddecb70 (LWP 6122) exited]
> >> [Thread 0xae1edb70 (LWP 6121) exited]
> >> [Thread 0xae7f0b70 (LWP 6120) exited]
> >> [Thread 0xaedf3b70 (LWP 6119) exited]
> >> [Thread 0xaf2f5b70 (LWP 6118) exited]
> >> [Thread 0xaf7f7b70 (LWP 6117) exited]
> >> [Thread 0xafbf8b70 (LWP 6116) exited]
> >> [Thread 0xafff9b70 (LWP 6115) exited]
> >> [Thread 0xb04fbb70 (LWP 6114) exited]
> >> [Thread 0xb08fcb70 (LWP 6113) exited]
> >> [Thread 0xb582ab70 (LWP 5868) exited]
> >> [Thread 0xb5320b70 (LWP 5869) exited]
> >> [Thread 0xb4e1eb70 (LWP 5870) exited]
> >> [Thread 0xb4a1db70 (LWP 5871) exited]
> >> [Thread 0xb461cb70 (LWP 5872) exited]
> >> [Thread 0xb421bb70 (LWP 5873) exited]
> >> [Thread 0xb5c2bb70 (LWP 5867) exited]
> >>
> >> Program terminated with signal SIGABRT, Aborted.
> >> The program no longer exists.
> >> (gdb)
> >>
> >>
> >
> >
>
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 9 months
Re: (ITS#6878) ppcache segfault with tavl_delete
by hyc＠symas.com
Howard Chu wrote:
> Tyler Gates wrote:
>> After applying the patches for ITS #6848 and ITS #6898 I still get crashes.
>> Here's the latest:
??? neither #6848 nor #6898 are relevant to pcache.
I think you should try the RE24 branch at this point, as a number of other
pcache-related fixes have been merged there.
>
> Looks like a double-free. Can you reproduce this consistently? If so, what are
> the steps? can you run slapd under valgrind and reproduce this?
>>
>> Program received signal SIGABRT, Aborted.
>> [Switching to Thread 0xae1edb70 (LWP 6121)]
>> 0xb76e2430 in __kernel_vsyscall ()
>> (gdb)
>> (gdb)
>> (gdb) bt
>> #0 0xb76e2430 in __kernel_vsyscall ()
>> #1 0xb71b4651 in *__GI_raise (sig=6) at
>> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>> #2 0xb71b7a82 in *__GI_abort () at abort.c:92
>> #3 0xb71eb49d in __libc_message (do_abort=2, fmt=0xb72bff98 "*** glibc
>> detected *** %s: %s: 0x%s ***\n") at
>> ../sysdeps/unix/sysv/linux/libc_fatal.c:189
>> #4 0xb71f5591 in malloc_printerr (action=<value optimized out>, str=0x6
>> <Address 0x6 out of bounds>, ptr=0xb9584e80) at malloc.c:6266
>> #5 0xb71f6de8 in _int_free (av=<value optimized out>, p=<value
>> optimized out>) at malloc.c:4794
>> #6 0xb71f9ecd in *__GI___libc_free (mem=0xb9584e80) at malloc.c:3738
>> #7 0xb768ac20 in ber_memfree_x () from /usr/lib/liblber-2.4.so.2
>> #8 0xb768acaf in ber_bvarray_free_x () from /usr/lib/liblber-2.4.so.2
>> #9 0xb768acf5 in ber_bvarray_free () from /usr/lib/liblber-2.4.so.2
>> #10 0xb7743e5d in attr_clean (a=0xb6dcc06c) at
>> /tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:148
>> #11 0xb7743efb in attrs_free (a=0xb6dcc06c) at
>> /tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:198
>> #12 0xb6d84b7f in hdb_cache_modify (bdb=0xb9536e10, e=0xb94f1dac,
>> newAttrs=0xb6dd6884, txn=0xb2176970, lock=0xae1ec930) at cache.c:1238
>> #13 0xb6d7008c in hdb_modify (op=0xae1eccfc, rs=0xae1ecad0) at modify.c:662
>> #14 0xb6d52e81 in remove_query_data (op=<value optimized out>,
>> query_uuid=<value optimized out>)
>> at /tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:1829
>> #15 0xb6d53d0b in consistency_check (ctx=0xae1ed1dc, arg=0xb955e018) at
>> /tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:3520
>> #16 0xb769d8b4 in ?? () from /usr/lib/libldap_r-2.4.so.2
>> #17 0xb72e996e in start_thread (arg=0xae1edb70) at pthread_create.c:300
>> #18 0xb7257a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
>> (gdb) continue
>> Continuing.
>> [Thread 0xaddecb70 (LWP 6122) exited]
>> [Thread 0xae1edb70 (LWP 6121) exited]
>> [Thread 0xae7f0b70 (LWP 6120) exited]
>> [Thread 0xaedf3b70 (LWP 6119) exited]
>> [Thread 0xaf2f5b70 (LWP 6118) exited]
>> [Thread 0xaf7f7b70 (LWP 6117) exited]
>> [Thread 0xafbf8b70 (LWP 6116) exited]
>> [Thread 0xafff9b70 (LWP 6115) exited]
>> [Thread 0xb04fbb70 (LWP 6114) exited]
>> [Thread 0xb08fcb70 (LWP 6113) exited]
>> [Thread 0xb582ab70 (LWP 5868) exited]
>> [Thread 0xb5320b70 (LWP 5869) exited]
>> [Thread 0xb4e1eb70 (LWP 5870) exited]
>> [Thread 0xb4a1db70 (LWP 5871) exited]
>> [Thread 0xb461cb70 (LWP 5872) exited]
>> [Thread 0xb421bb70 (LWP 5873) exited]
>> [Thread 0xb5c2bb70 (LWP 5867) exited]
>>
>> Program terminated with signal SIGABRT, Aborted.
>> The program no longer exists.
>> (gdb)
>>
>>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 9 months
Re: (ITS#6899) Read Entry Control response value is not compliant to definition of SearchResultEntry
by masarati＠aero.polimi.it
> masarati(a)aero.polimi.it wrote:
>>> With your patch the response control is now decoded correctly and it
>>> behaves
>>> as expected for all operations except Modify DN Operation:
>>> It returns empty value lists for all attributes no matter how
>>> deleteoldrdn
>>> is
>>> set. The DN returned is correct.
>>
>> I suspect ors_attrsonly is set by mistake. Please try this:
>>
>> + myop.ors_attrsonly = 0;
>
> With your last patch everything works as expected now. Thanks a lot.
Great. I've committed it. Thanks, p.
11 years, 9 months
