- openldap-bugs - openldap.org

Re: (ITS#5378) hot slapcat for slapadd issues with delta-sync
by ando＠sys-net.it 14 Feb '08

14 Feb '08

hyc(a)OpenLDAP.org wrote: > Another possibility would be to filter out any entries whose entryCSNs are > newer than the contextCSN in the LDIF before trying to slapadd it. Should slapadd take care of it (perhaps if instructed to do so)? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: ITS#5375
by ando＠sys-net.it 14 Feb '08

14 Feb '08

ecizaguirre(a)gmv.com wrote: > Hi Quanah, I have followed your instructions. As you can check the slapd binary is not stripped: > > -bash-3.00# file slapd > > slapd: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped > > The backtrace of the slapd process is the following: > > <<< dnPretty: <cn=Eduardo Izaguirre Pazos,ou=SISTEMAS,ou=people,dc=gmv,dc=es> > > Assertion failed: ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals ) || ( nvals != NULL && ( ( (*a)->a_vals == NULL && (*a)->a_nvals == NULL ) || ( (*a)->a_nvals != (*a)->a_vals ) ) ), file attr.c, line 480 ^^^ this is very interesting, as it's supposed to never happen. In order to try to figure out what is actually happening, I need your configuration and the exact operation that triggered this issue. In the meanwhile, you could probably post the contents of the variables used in that assert. For this purpose, from within gdb, you should: (gdb) frame 4 (gdb) p nvals (gdb) p (*a)->a_vals (gdb) p (*a)->a_nvals unless any of the above is NULL, you should also print its contents up to the first value of the array, namely (gdb) p vals[0] (gdb) p nvals[0] (gdb) p (*a)->a_vals[0] (gdb) p (*a)->a_nvals[0] If any of the above contains info that you consider sensible, do not post it; only tell whether the value is present or NULL (note: by NULL I mean the corresponding struct berval has a NULL bv_val member) Also, please do (gdb) p (*a)->a_desc[0] (gdb) p (*a)->a_numvals (gdb) p (*a)->a_flags > Program received signal SIGABRT, Aborted. > [Switching to LWP 4] > 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 > (gdb) bt > #0 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 > #1 0xfe25fe20 in raise () from /usr/lib/libc.so.1 > #2 0xfe240040 in abort () from /usr/lib/libc.so.1 > #3 0xfe24027c in _assert () from /usr/lib/libc.so.1 > #4 0x0005e104 in attr_merge (e=0xfcbfeaf0, desc=0x33a9b0, vals=0x3da650, nvals=0x3d8b08) at attr.c:477 > #5 0x000d3854 in modify_add_values (e=0xfcbfeaf0, mod=0xfcbfead0, permissive=1, text=0xfcbfeb24, textbuf=0xfcbfe9d0 "", > textlen=256) at mods.c:155 > #6 0x001be108 in rwm_attrs (op=0x3c1490, rs=0xfcbffc90, a_first=0x49bc00, stripEntryDN=1) at rwm.c:1232 > #7 0x001be3b0 in rwm_send_entry (op=0x3c1490, rs=0xfcbffc90) at rwm.c:1323 > #8 0x001be930 in rwm_response (op=0x3c1490, rs=0xfcbffc90) at rwm.c:1518 > #9 0x000f17dc in over_back_response (op=0x3c1490, rs=0xfcbffc90) at backover.c:241 #10 0x0006918c in slap_response_play (op=0x3c1490, rs=0xfcbffc90) at result.c:307 > #11 0x0006b3c4 in slap_send_search_entry (op=0x3c1490, rs=0xfcbffc90) at result.c:771 > #12 0x00135aa0 in meta_send_entry (op=0x3c1490, rs=0xfcbffc90, mc=0x3c18f8, target=0, e=0x4d9320) at search.c:2071 > #13 0x00132a40 in meta_back_search (op=0x3c1490, rs=0xfcbffc90) at search.c:1128 > #14 0x000f2668 in overlay_op_walk (op=0x3c1490, rs=0xfcbffc90, which=op_search, oi=0x35ef80, on=0x0) at backover.c:652 > #15 0x000f2874 in over_op_func (op=0x3c1490, rs=0xfcbffc90, which=op_search) at backover.c:704 > #16 0x000f2924 in over_op_search (op=0x3c1490, rs=0xfcbffc90) at backover.c:726 > #17 0x00053adc in fe_op_search (op=0x3c1490, rs=0xfcbffc90) at search.c:368 > #18 0x00053294 in do_search (op=0x3c1490, rs=0xfcbffc90) at search.c:217 > #19 0x0004f4f8 in connection_operation (ctx=0xfcbffe00, arg_v=0x3c1490) at connection.c:1083 #20 0x0004fc30 in connection_read_thread (ctx=0xfcbffe00, argv=0xb) at connection.c:1210 > #21 0x001f58d8 in ldap_int_thread_pool_wrapper (xpool=0x33cdb0) at tpool.c:625 > #22 0xfe2c00b8 in _lwp_start () from /usr/lib/libc.so.1 > #23 0xfe2c00b8 in _lwp_start () from /usr/lib/libc.so.1 Backtrace stopped: previous frame identical to this frame (corrupt stack?) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5378) hot slapcat for slapadd issues with delta-sync
by hyc＠OpenLDAP.org 14 Feb '08

14 Feb '08

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.40 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.23.156.219) > > > If someone is using delta-syncrepl for replication, and does a hot slapcat of a > server, and a change occurs during the slapcat, the resulting LDIF file cannot > be used on a replica. This is because the replica will try to resume from the > CSN in the LDIF file, which is from before the change occurred. Since the > change is in the LDIF file, when the replica contacts the master, it tries to > re-replicate the change (which obviously fails). At that point, the replica is > stuck and unable to progress. The only guaranteed way to get a viable slapcat > when using delta-syncrepl is to put the server being dumped into RO mode or to > stop it. Another possibility would be to filter out any entries whose entryCSNs are newer than the contextCSN in the LDIF before trying to slapadd it. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5378) hot slapcat for slapadd issues with delta-sync
by quanah＠OpenLDAP.org 13 Feb '08

13 Feb '08

Full_Name: Quanah Gibson-Mount Version: 2.3.40 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) If someone is using delta-syncrepl for replication, and does a hot slapcat of a server, and a change occurs during the slapcat, the resulting LDIF file cannot be used on a replica. This is because the replica will try to resume from the CSN in the LDIF file, which is from before the change occurred. Since the change is in the LDIF file, when the replica contacts the master, it tries to re-replicate the change (which obviously fails). At that point, the replica is stuck and unable to progress. The only guaranteed way to get a viable slapcat when using delta-syncrepl is to put the server being dumped into RO mode or to stop it. --Quanah

1 0

RE: (ITS#5375) Slapd core dumps (fwd)
by quanah＠zimbra.com 13 Feb '08

13 Feb '08

Eduardo, Can you confirm this was with a fresh CVS checkout of RE24, and not with 2.4.7? Thanks, Quanah --On February 13, 2008 6:08:45 PM +0000 quanah(a)zimbra.com wrote: > Forwarding... > > ------------ Forwarded Message ------------ > Date: February 13, 2008 5:49:29 PM +0100 > From: Eduardo Izaguirre Pazos <ecizaguirre(a)gmv.com> > To: Quanah Gibson-Mount <quanah(a)zimbra.com> > Subject: RE: (ITS#5375) Slapd core dumps > > Hi Quanah, I have followed your instructions. As you can check the slapd > binary is not stripped: > > -bash-3.00# file slapd > slapd: ELF 32-bit MSB executable SPARC Version 1, dynamically > linked, not stripped > > The backtrace of the slapd process is the following: > > <<< dnPretty: <cn=Eduardo Izaguirre > Pazos,ou=SISTEMAS,ou=people,dc=gmv,dc=es> > Assertion failed: ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals ) || > ( nvals != NULL && ( ( (*a)->a_vals == NULL && (*a)->a_nvals == NULL ) >|| ( (*a)->a_nvals != (*a)->a_vals ) ) ), file attr.c, line 480 > > Program received signal SIGABRT, Aborted. > [Switching to LWP 4] > 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 > (gdb) bt ># 0 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 ># 1 0xfe25fe20 in raise () from /usr/lib/libc.so.1 ># 2 0xfe240040 in abort () from /usr/lib/libc.so.1 ># 3 0xfe24027c in _assert () from /usr/lib/libc.so.1 ># 4 0x0005e104 in attr_merge (e=0xfcbfeaf0, desc=0x33a9b0, > vals=0x3da650, nvals=0x3d8b08) at attr.c:477 ># 5 0x000d3854 in modify_add_values (e=0xfcbfeaf0, mod=0xfcbfead0, > permissive=1, text=0xfcbfeb24, textbuf=0xfcbfe9d0 "", > textlen=256) at mods.c:155 ># 6 0x001be108 in rwm_attrs (op=0x3c1490, rs=0xfcbffc90, > a_first=0x49bc00, stripEntryDN=1) at rwm.c:1232 ># 7 0x001be3b0 in rwm_send_entry (op=0x3c1490, rs=0xfcbffc90) at > rwm.c:1323 ># 8 0x001be930 in rwm_response (op=0x3c1490, rs=0xfcbffc90) at > rwm.c:1518 ># 9 0x000f17dc in over_back_response (op=0x3c1490, rs=0xfcbffc90) at > backover.c:241 ># 10 0x0006918c in slap_response_play (op=0x3c1490, rs=0xfcbffc90) at > result.c:307 ># 11 0x0006b3c4 in slap_send_search_entry (op=0x3c1490, rs=0xfcbffc90) at > result.c:771 ># 12 0x00135aa0 in meta_send_entry (op=0x3c1490, rs=0xfcbffc90, > mc=0x3c18f8, target=0, e=0x4d9320) at search.c:2071 ># 13 0x00132a40 in meta_back_search (op=0x3c1490, rs=0xfcbffc90) at > search.c:1128 ># 14 0x000f2668 in overlay_op_walk (op=0x3c1490, rs=0xfcbffc90, > which=op_search, oi=0x35ef80, on=0x0) at backover.c:652 ># 15 0x000f2874 in over_op_func (op=0x3c1490, rs=0xfcbffc90, > which=op_search) at backover.c:704 ># 16 0x000f2924 in over_op_search (op=0x3c1490, rs=0xfcbffc90) at > backover.c:726 ># 17 0x00053adc in fe_op_search (op=0x3c1490, rs=0xfcbffc90) at > search.c:368 ># 18 0x00053294 in do_search (op=0x3c1490, rs=0xfcbffc90) at search.c:217 ># 19 0x0004f4f8 in connection_operation (ctx=0xfcbffe00, arg_v=0x3c1490) > at connection.c:1083 ># 20 0x0004fc30 in connection_read_thread (ctx=0xfcbffe00, argv=0xb) at > connection.c:1210 ># 21 0x001f58d8 in ldap_int_thread_pool_wrapper (xpool=0x33cdb0) at > tpool.c:625 ># 22 0xfe2c00b8 in _lwp_start () from /usr/lib/libc.so.1 ># 23 0xfe2c00b8 in _lwp_start () from /usr/lib/libc.so.1 > Backtrace stopped: previous frame identical to this frame (corrupt > stack?) > > I hope this help. > > Thanks. > > Eduardo > > -----Mensaje original----- > De: Quanah Gibson-Mount [mailto:quanah@zimbra.com] > Enviado el: martes, 12 de febrero de 2008 18:44 > Para: Eduardo Izaguirre Pazos; openldap-its(a)openldap.org > Asunto: Re: (ITS#5375) Slapd core dumps > > > > --On February 12, 2008 2:58:12 PM +0000 ecip(a)gmv.es wrote: > >> Full_Name: Eduardo Izaguirre Pazos >> Version: 2.4.7 >> OS: Solaris 10 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.0.110.2) >> >> >> Hi all, we are using Openldap as a metadirectory against a couple of >> AD servers. The slapd server core dumps when a request of all >> attributes of one entry is issued. This is the output of the slapd >> server using the debug level -1: > > Hi Eduardo, > > Please test with the current CVS of REL_ENG_2_4. Please build without > optimization, and with debugging symbols. Make sure you don't strip > slapd on install. If you can repeat this with current CVS, please > provide a gdb backtrace of the non-optimized, non-stripped slapd. > > Thanks, > Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > ______________________ > Este mensaje, y en su caso, cualquier fichero anexo al mismo, > puede contener informacion clasificada por su emisor como confidencial > en el marco de su Sistema de Gestion de Seguridad de la > Informacion siendo para uso exclusivo del destinatario, quedando > prohibida su divulgacion copia o distribucion a terceros sin la > autorizacion expresa del remitente. Si Vd. ha recibido este mensaje > erroneamente, se ruega lo notifique al remitente y proceda a su borrado. > Gracias por su colaboracion. > ______________________ > This message including any attachments may contain confidential > information, according to our Information Security Management System, > and intended solely for a specific individual to whom they are addressed. > Any unauthorised copy, disclosure or distribution of this message > is strictly forbidden. If you have received this transmission in error, > please notify the sender immediately and delete it. > ______________________ > > ---------- End Forwarded Message ---------- > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#5375) Slapd core dumps (fwd)
by quanah＠zimbra.com 13 Feb '08

13 Feb '08

------------ Forwarded Message ------------ Date: February 13, 2008 5:54:44 PM +0100 From: Eduardo Izaguirre Pazos <ecizaguirre(a)gmv.com> To: Quanah Gibson-Mount <quanah(a)zimbra.com> Subject: RE: (ITS#5375) Slapd core dumps Hi again Quanah, I have analyzed the core file dumped by the slapd process with gdb and I have obtanied the following backtrace: (gdb) bt # 0 0xff3bf430 in rtld_db_dlactivity () from /lib/ld.so.1 # 1 0xff3bf5f0 in rd_event () from /lib/ld.so.1 # 2 0xff3c06e4 in lm_delete () from /lib/ld.so.1 # 3 0xff3c8dbc in remove_so () from /lib/ld.so.1 # 4 0xff3caa24 in remove_hdl () from /lib/ld.so.1 # 5 0xff3c4d5c in dlclose_intn () from /lib/ld.so.1 # 6 0xff3c4e70 in dlclose () from /lib/ld.so.1 # 7 0xfdf62b44 in pkcs11_slottable_delete () from /usr/lib/libpkcs11.so.1 # 8 0xfdf5d66c in pkcs11_fini () from /usr/lib/libpkcs11.so.1 # 9 0xfe240dc8 in _postfork_child_handler () from /usr/lib/libc.so.1 # 10 0xfe2b2970 in fork1 () from /usr/lib/libc.so.1 # 11 0x001f0d48 in lutil_detach (debug=0, do_close=0) at detach.c:76 # 12 0x00027c68 in main (argc=3, argv=0xffbffb04) at main.c:864 I think this would be more useful than the previous one I've sent before. Cheers. Eduardo -----Mensaje original----- De: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Enviado el: martes, 12 de febrero de 2008 18:44 Para: Eduardo Izaguirre Pazos; openldap-its(a)openldap.org Asunto: Re: (ITS#5375) Slapd core dumps --On February 12, 2008 2:58:12 PM +0000 ecip(a)gmv.es wrote: > Full_Name: Eduardo Izaguirre Pazos > Version: 2.4.7 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.0.110.2) > > > Hi all, we are using Openldap as a metadirectory against a couple of > AD servers. The slapd server core dumps when a request of all > attributes of one entry is issued. This is the output of the slapd > server using the debug level -1: Hi Eduardo, Please test with the current CVS of REL_ENG_2_4. Please build without optimization, and with debugging symbols. Make sure you don't strip slapd on install. If you can repeat this with current CVS, please provide a gdb backtrace of the non-optimized, non-stripped slapd. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________ ---------- End Forwarded Message ---------- -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#5375) Slapd core dumps (fwd)
by quanah＠zimbra.com 13 Feb '08

13 Feb '08

Forwarding... ------------ Forwarded Message ------------ Date: February 13, 2008 5:49:29 PM +0100 From: Eduardo Izaguirre Pazos <ecizaguirre(a)gmv.com> To: Quanah Gibson-Mount <quanah(a)zimbra.com> Subject: RE: (ITS#5375) Slapd core dumps Hi Quanah, I have followed your instructions. As you can check the slapd binary is not stripped: -bash-3.00# file slapd slapd: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped The backtrace of the slapd process is the following: <<< dnPretty: <cn=Eduardo Izaguirre Pazos,ou=SISTEMAS,ou=people,dc=gmv,dc=es> Assertion failed: ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals ) || ( nvals != NULL && ( ( (*a)->a_vals == NULL && (*a)->a_nvals == NULL ) || ( (*a)->a_nvals != (*a)->a_vals ) ) ), file attr.c, line 480 Program received signal SIGABRT, Aborted. [Switching to LWP 4] 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 (gdb) bt # 0 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 # 1 0xfe25fe20 in raise () from /usr/lib/libc.so.1 # 2 0xfe240040 in abort () from /usr/lib/libc.so.1 # 3 0xfe24027c in _assert () from /usr/lib/libc.so.1 # 4 0x0005e104 in attr_merge (e=0xfcbfeaf0, desc=0x33a9b0, vals=0x3da650, nvals=0x3d8b08) at attr.c:477 # 5 0x000d3854 in modify_add_values (e=0xfcbfeaf0, mod=0xfcbfead0, permissive=1, text=0xfcbfeb24, textbuf=0xfcbfe9d0 "", textlen=256) at mods.c:155 # 6 0x001be108 in rwm_attrs (op=0x3c1490, rs=0xfcbffc90, a_first=0x49bc00, stripEntryDN=1) at rwm.c:1232 # 7 0x001be3b0 in rwm_send_entry (op=0x3c1490, rs=0xfcbffc90) at rwm.c:1323 # 8 0x001be930 in rwm_response (op=0x3c1490, rs=0xfcbffc90) at rwm.c:1518 # 9 0x000f17dc in over_back_response (op=0x3c1490, rs=0xfcbffc90) at backover.c:241 # 10 0x0006918c in slap_response_play (op=0x3c1490, rs=0xfcbffc90) at result.c:307 # 11 0x0006b3c4 in slap_send_search_entry (op=0x3c1490, rs=0xfcbffc90) at result.c:771 # 12 0x00135aa0 in meta_send_entry (op=0x3c1490, rs=0xfcbffc90, mc=0x3c18f8, target=0, e=0x4d9320) at search.c:2071 # 13 0x00132a40 in meta_back_search (op=0x3c1490, rs=0xfcbffc90) at search.c:1128 # 14 0x000f2668 in overlay_op_walk (op=0x3c1490, rs=0xfcbffc90, which=op_search, oi=0x35ef80, on=0x0) at backover.c:652 # 15 0x000f2874 in over_op_func (op=0x3c1490, rs=0xfcbffc90, which=op_search) at backover.c:704 # 16 0x000f2924 in over_op_search (op=0x3c1490, rs=0xfcbffc90) at backover.c:726 # 17 0x00053adc in fe_op_search (op=0x3c1490, rs=0xfcbffc90) at search.c:368 # 18 0x00053294 in do_search (op=0x3c1490, rs=0xfcbffc90) at search.c:217 # 19 0x0004f4f8 in connection_operation (ctx=0xfcbffe00, arg_v=0x3c1490) at connection.c:1083 # 20 0x0004fc30 in connection_read_thread (ctx=0xfcbffe00, argv=0xb) at connection.c:1210 # 21 0x001f58d8 in ldap_int_thread_pool_wrapper (xpool=0x33cdb0) at tpool.c:625 # 22 0xfe2c00b8 in _lwp_start () from /usr/lib/libc.so.1 # 23 0xfe2c00b8 in _lwp_start () from /usr/lib/libc.so.1 Backtrace stopped: previous frame identical to this frame (corrupt stack?) I hope this help. Thanks. Eduardo -----Mensaje original----- De: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Enviado el: martes, 12 de febrero de 2008 18:44 Para: Eduardo Izaguirre Pazos; openldap-its(a)openldap.org Asunto: Re: (ITS#5375) Slapd core dumps --On February 12, 2008 2:58:12 PM +0000 ecip(a)gmv.es wrote: > Full_Name: Eduardo Izaguirre Pazos > Version: 2.4.7 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.0.110.2) > > > Hi all, we are using Openldap as a metadirectory against a couple of > AD servers. The slapd server core dumps when a request of all > attributes of one entry is issued. This is the output of the slapd > server using the debug level -1: Hi Eduardo, Please test with the current CVS of REL_ENG_2_4. Please build without optimization, and with debugging symbols. Make sure you don't strip slapd on install. If you can repeat this with current CVS, please provide a gdb backtrace of the non-optimized, non-stripped slapd. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________ ---------- End Forwarded Message ---------- -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5376) Full sync fails with delta-syncrepl, refreshAndPersist, and high modifications
by quanah＠zimbra.com 13 Feb '08

13 Feb '08

--On February 13, 2008 11:40:17 AM +0000 hyc(a)symas.com wrote: > quanah(a)zimbra.com wrote: >> With a build of 2.3 with the (adjusted) patches from HEAD, it looks like >> this issue is resolved. I fully sync'd a replica from the master, and >> after it was done, I did a slapcat of them. >> >> A direct diff shows a lot of entries out of order (because the replica >> gets them in multiple refresh phases), however, if I sort the two ldif >> files, and do a diff, I get: >> >> [zimbra@smtp-2 tmp]$ sort slave.ldif>slave.ldif.s >> [zimbra@smtp-2 tmp]$ sort master.ldif>master.ldif.s >> [zimbra@smtp-2 tmp]$ diff -u master.ldif.s slave.ldif.s >> [zimbra@smtp-2 tmp]$ >> >> No diff. So I believe this is fixed. Sound correct? > > Sounds good to me. I guess this should go into both RE23 and RE24. As discussed with Howard, I'm going to drop the permissive modify bit. I verified things work correctly without it, and having it could potentially lead to issues. I also tracked down an ldif sorting script Matt Backes sent to me a while ago, and verified the LDIF matched after sorting with it. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

ITS#5375
by ecizaguirre＠gmv.com 13 Feb '08

13 Feb '08

Hi Quanah, I have followed your instructions. As you can check the slapd binary is not stripped: -bash-3.00# file slapd slapd: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped The backtrace of the slapd process is the following: <<< dnPretty: <cn=Eduardo Izaguirre Pazos,ou=SISTEMAS,ou=people,dc=gmv,dc=es> Assertion failed: ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals ) || ( nvals != NULL && ( ( (*a)->a_vals == NULL && (*a)->a_nvals == NULL ) || ( (*a)->a_nvals != (*a)->a_vals ) ) ), file attr.c, line 480 Program received signal SIGABRT, Aborted. [Switching to LWP 4] 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 (gdb) bt #0 0xfe2c12a4 in _lwp_kill () from /usr/lib/libc.so.1 #1 0xfe25fe20 in raise () from /usr/lib/libc.so.1 #2 0xfe240040 in abort () from /usr/lib/libc.so.1 #3 0xfe24027c in _assert () from /usr/lib/libc.so.1 #4 0x0005e104 in attr_merge (e=0xfcbfeaf0, desc=0x33a9b0, vals=0x3da650, nvals=0x3d8b08) at attr.c:477 #5 0x000d3854 in modify_add_values (e=0xfcbfeaf0, mod=0xfcbfead0, permissive=1, text=0xfcbfeb24, textbuf=0xfcbfe9d0 "", textlen=256) at mods.c:155 #6 0x001be108 in rwm_attrs (op=0x3c1490, rs=0xfcbffc90, a_first=0x49bc00, stripEntryDN=1) at rwm.c:1232 #7 0x001be3b0 in rwm_send_entry (op=0x3c1490, rs=0xfcbffc90) at rwm.c:1323 #8 0x001be930 in rwm_response (op=0x3c1490, rs=0xfcbffc90) at rwm.c:1518 #9 0x000f17dc in over_back_response (op=0x3c1490, rs=0xfcbffc90) at backover.c:241 #10 0x0006918c in slap_response_play (op=0x3c1490, rs=0xfcbffc90) at result.c:307 #11 0x0006b3c4 in slap_send_search_entry (op=0x3c1490, rs=0xfcbffc90) at result.c:771 #12 0x00135aa0 in meta_send_entry (op=0x3c1490, rs=0xfcbffc90, mc=0x3c18f8, target=0, e=0x4d9320) at search.c:2071 #13 0x00132a40 in meta_back_search (op=0x3c1490, rs=0xfcbffc90) at search.c:1128 #14 0x000f2668 in overlay_op_walk (op=0x3c1490, rs=0xfcbffc90, which=op_search, oi=0x35ef80, on=0x0) at backover.c:652 #15 0x000f2874 in over_op_func (op=0x3c1490, rs=0xfcbffc90, which=op_search) at backover.c:704 #16 0x000f2924 in over_op_search (op=0x3c1490, rs=0xfcbffc90) at backover.c:726 #17 0x00053adc in fe_op_search (op=0x3c1490, rs=0xfcbffc90) at search.c:368 #18 0x00053294 in do_search (op=0x3c1490, rs=0xfcbffc90) at search.c:217 #19 0x0004f4f8 in connection_operation (ctx=0xfcbffe00, arg_v=0x3c1490) at connection.c:1083 #20 0x0004fc30 in connection_read_thread (ctx=0xfcbffe00, argv=0xb) at connection.c:1210 #21 0x001f58d8 in ldap_int_thread_pool_wrapper (xpool=0x33cdb0) at tpool.c:625 #22 0xfe2c00b8 in _lwp_start () from /usr/lib/libc.so.1 #23 0xfe2c00b8 in _lwp_start () from /usr/lib/libc.so.1 Backtrace stopped: previous frame identical to this frame (corrupt stack?) And I have obtained the following stack trace analyzing the core file dumped by the slapd process: (gdb) bt #0 0xff3bf430 in rtld_db_dlactivity () from /lib/ld.so.1 #1 0xff3bf5f0 in rd_event () from /lib/ld.so.1 #2 0xff3c06e4 in lm_delete () from /lib/ld.so.1 #3 0xff3c8dbc in remove_so () from /lib/ld.so.1 #4 0xff3caa24 in remove_hdl () from /lib/ld.so.1 #5 0xff3c4d5c in dlclose_intn () from /lib/ld.so.1 #6 0xff3c4e70 in dlclose () from /lib/ld.so.1 #7 0xfdf62b44 in pkcs11_slottable_delete () from /usr/lib/libpkcs11.so.1 #8 0xfdf5d66c in pkcs11_fini () from /usr/lib/libpkcs11.so.1 #9 0xfe240dc8 in _postfork_child_handler () from /usr/lib/libc.so.1 #10 0xfe2b2970 in fork1 () from /usr/lib/libc.so.1 #11 0x001f0d48 in lutil_detach (debug=0, do_close=0) at detach.c:76 #12 0x00027c68 in main (argc=3, argv=0xffbffb04) at main.c:864 I hope this helps. Thanks. Eduardo ________________________________ Eduardo Izaguirre Pazos Administrador de Sistemas / Systems Administrator GRUPO TECNOLÓGICO E INDUSTRIAL GMV,S.A. Isaac Newton, 11 P.T.M. Tres Cantos E-28760 Madrid Tel. +34 91 807 21 00 Fax +34 91 807 21 99 www.gmv.com ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________

1 0

(ITS#5377) Why can I delete attributeType and objectClass together
by bsdrab＠gmail.com 13 Feb '08

13 Feb '08

Full_Name: Niki Petrov Version: 2.4.6 OS: FreeBSD 7.0 RC1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.125.204.194) Why can I delete attributeType and objectClass together, and how can I do this? ----------------------------------------------------------------------------------------- # ldapmodify -x -W -D "cn=rtoo,o=hoji,l=gu,c=fr" -f /usr/home/testu/scripts/user_delete ... ..(file user_delete) dn: uid=user,o=hoji,l=gu,c=fr changetype: modify delete: virtualdomain virtualdomain: hoji.gu.fr delete: objectClass objectClass: CourierDomainAlias ..... (error in command-line) ldapmodify: wrong attributeType at line 5, entry "uid=user,o=hoji,l=gu,c=fr"

1 0

Re: (ITS#5376) Full sync fails with delta-syncrepl, refreshAndPersist, and high modifications
by hyc＠symas.com 13 Feb '08

13 Feb '08

quanah(a)zimbra.com wrote: > With a build of 2.3 with the (adjusted) patches from HEAD, it looks like > this issue is resolved. I fully sync'd a replica from the master, and > after it was done, I did a slapcat of them. > > A direct diff shows a lot of entries out of order (because the replica gets > them in multiple refresh phases), however, if I sort the two ldif files, > and do a diff, I get: > > [zimbra@smtp-2 tmp]$ sort slave.ldif>slave.ldif.s > [zimbra@smtp-2 tmp]$ sort master.ldif>master.ldif.s > [zimbra@smtp-2 tmp]$ diff -u master.ldif.s slave.ldif.s > [zimbra@smtp-2 tmp]$ > > No diff. So I believe this is fixed. Sound correct? Sounds good to me. I guess this should go into both RE23 and RE24. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5370) race condition in slap_op_time()
by h.b.furuseth＠usit.uio.no 13 Feb '08

13 Feb '08

hyc(a)symas.com writes: > Except that this will take a lot more restructuring in accesslog. Going with > the quick fix for now. Looks like I didn't notice the first use of o_tincr in accesslog:-( I guess accesslog can set an "I need o_tincr" flag somewhere, which slapd will then obey. -- Hallvard

1 0

Re: (ITS#5376) Full sync fails with delta-syncrepl, refreshAndPersist, and high modifications
by quanah＠zimbra.com 12 Feb '08

12 Feb '08

--On February 13, 2008 3:14:37 AM +0000 quanah(a)zimbra.com wrote: > > > --On February 13, 2008 3:03:46 AM +0000 quanah(a)zimbra.com wrote: > >> >> And, with the patch for ITS#5282, all replication stops (probably a good >> thing). > > More specifically, the replica stops accepting any new changes, since it > can't proceed on the MODs to a non-existent entry. The master of course > continues to accept and record changes, and any non-problematic replicas > continue to receive changes. With a build of 2.3 with the (adjusted) patches from HEAD, it looks like this issue is resolved. I fully sync'd a replica from the master, and after it was done, I did a slapcat of them. A direct diff shows a lot of entries out of order (because the replica gets them in multiple refresh phases), however, if I sort the two ldif files, and do a diff, I get: [zimbra@smtp-2 tmp]$ sort slave.ldif >slave.ldif.s [zimbra@smtp-2 tmp]$ sort master.ldif >master.ldif.s [zimbra@smtp-2 tmp]$ diff -u master.ldif.s slave.ldif.s [zimbra@smtp-2 tmp]$ No diff. So I believe this is fixed. Sound correct? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5376) Full sync fails with delta-syncrepl, refreshAndPersist, and high modifications
by quanah＠zimbra.com 12 Feb '08

12 Feb '08

--On February 13, 2008 3:03:46 AM +0000 quanah(a)zimbra.com wrote: > > And, with the patch for ITS#5282, all replication stops (probably a good > thing). More specifically, the replica stops accepting any new changes, since it can't proceed on the MODs to a non-existent entry. The master of course continues to accept and record changes, and any non-problematic replicas continue to receive changes. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5376) Full sync fails with delta-syncrepl, refreshAndPersist, and high modifications
by quanah＠zimbra.com 12 Feb '08

12 Feb '08

--On February 13, 2008 2:57:39 AM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.40 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.23.156.219) > > > If you start a replica with an empty DB, using delta-sync replication, > and the master is receiving a high rate of changes, the Refresh phase > will skip entries that have been modified. When it moves to the > "persist" phase, delta-syncrepl will send modification diffs to those > entries rather than the full entries, so entries end up missing, having > never been sent in a full form. And, with the patch for ITS#5282, all replication stops (probably a good thing). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5376) Full sync fails with delta-syncrepl, refreshAndPersist, and high modifications
by quanah＠zimbra.com 12 Feb '08

12 Feb '08

Full_Name: Quanah Gibson-Mount Version: 2.3.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) If you start a replica with an empty DB, using delta-sync replication, and the master is receiving a high rate of changes, the Refresh phase will skip entries that have been modified. When it moves to the "persist" phase, delta-syncrepl will send modification diffs to those entries rather than the full entries, so entries end up missing, having never been sent in a full form.

1 0

Re: (ITS#5339) wrong referral from back-bdb
by hyc＠symas.com 12 Feb '08

12 Feb '08

h.b.furuseth(a)usit.uio.no wrote: > Howard Chu writes: >>> Both RFCs disagree. >> They are wrong. Or at least, under-specified. In X.501 section 17.3 >> "Directory Distribution Model" it's quite clear that all of the >> components of a distributed directory must belong to a single DIT. > > Which is not true in the LDAP world, and I don't know about today's > X.500 world. Nameflow died and Dante was unable to resurrect it. Maybe > the X.500 world has also switched to 'dc' structure, I don't know. > > Anyway, LDAP is not X.500. RFC4510 Section 2 "Relationship to X.500" This technical specification defines LDAP in terms of [X.500] as an X.500 access mechanism. An LDAP server MUST act in accordance with the X.500 (1993) series of International Telecommunication Union - Telecommunication Standardization (ITU-T) Recommendations when providing the service. > Remember, LDAP referrals need not even be > LDAP URLs. My guess is that's one reason for the difference from X.500: > When you can even return a HTTP URL, why should you _not_ be allowed > to return a far smaller change from the original URL? As I've said many times before, LDAP referrals are a poorly designed piece of junk. The fact that the spec leaves it open to return other types of URLs but nobody in the world knows what that should actually mean to an LDAP client is just further proof of the abysmal lack of thought that went into the design. > Also LDAP started out a lot sloppier than X.500. That's self-evident. ;) > Getting some response > which hopefully resembled what you wanted was better than none:-) Getting a wrong answer is worse than getting no answer, because the client will just assume that everything is OK and keep going, rather than reporting an error to the user. >> And again, the service model requires the directory to store the >> client's data without any alteration. If the client wants to create >> the entry "cn=me,o=we" either that exact entry must be created, or the >> operation must fail. > > Well, the operation does fail in the original server. Then the client > may try another operation at another server... I don't know if that's a > valid interpretation of the service model or not. In any case, it's a > detail compared to the mess No, in this case the client is not being told to retry the *same* operation in another server, it's being told to try a *very different* operation in another server. Once again, the client made a specific request to create an entry with a specific DN. If the server can't honor the request as specified then it should fail and the operation should halt. Anyway, the very existence of LDAP referrals is a violation of the service model. X.501(1993) section 18.2: It is a requirement of the Directory that, for particular modes of user interaction, the distribution of the directory be rendered transparent, thereby giving the effect that the whole of the DIB appears to be within each and every DSA. LDAPv1 had no referrals. When they were introduced in LDAPv2 it's clear that nobody knew what they were doing, or nobody wanted to tackle the glaring absence of an analogue to X.500 DSP. They should never have been introduced. We're stuck with them for now, but we can at least try to make them make sense. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5370) race condition in slap_op_time()
by hyc＠symas.com 12 Feb '08

12 Feb '08

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> However as far as I can tell, only the accesslog overlay uses >> op->o_tincr, the value which needs the mutex. And accesslog >> calls slap_op_time() itself when it needs that value. >> So maybe we should remove the op->o_tincr field. Other calls >> to slap_op_time() can be replaced with slap_get_time(). > > Sounds like a good idea. It was somewhat redundant with the CSN counter > (except that this was for all operations, and CSN was only for write > operations) and it never became generally useful. (Shifted to microsecond > timestamps in 2.4, because tincr isn't useful across multiple servers.) I > guess it makes more sense to make it specific to accesslog. > Except that this will take a lot more restructuring in accesslog. Going with the quick fix for now. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5374) accesslog+hdb crash with test043-delta-syncrepl
by quanah＠zimbra.com 12 Feb '08

12 Feb '08

--On February 12, 2008 6:12:08 PM +0000 quanah(a)zimbra.com wrote: > (and it passed 10 times for me successfully). At Hallvard's request, I patched accesslog thusly: diff -u accesslog.c.orig accesslog.c --- accesslog.c.orig 2008-02-12 10:18:16.000000000 -0800 +++ accesslog.c 2008-02-12 10:21:46.000000000 -0800 @@ -914,6 +914,7 @@ ldap_pvt_thread_mutex_lock( &li->li_log_mutex ); old = li->li_old; li->li_old = NULL; + assert(li->li_unlock == (int) ldap_pvt_thread_self()); li->li_unlock = 0; ldap_pvt_thread_mutex_unlock( &li->li_op_mutex ); } @@ -1262,7 +1263,8 @@ * overlays like refint to keep working. */ ldap_pvt_thread_mutex_lock( &li->li_op_mutex ); - li->li_unlock = 1; + /* li->li_unlock = 1; */ + li->li_unlock = (int) ldap_pvt_thread_self(); if ( li->li_oldf && ( op->o_tag == LDAP_REQ_DELETE || op->o_tag == LDAP_REQ_MODIFY )) { int rc; Multiple runs of the test continued to be successful. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5374) accesslog+hdb crash with test043-delta-syncrepl
by quanah＠zimbra.com 12 Feb '08

12 Feb '08

(and it passed 10 times for me successfully). --On February 12, 2008 5:59:22 PM +0000 quanah(a)zimbra.com wrote: > > > --On February 12, 2008 12:11:50 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > >> Full_Name: Hallvard B Furuseth >> Version: RE23 >> OS: Linux >> URL: >> Submission from: (NULL) (129.240.6.233) >> Submitted by: hallvard >> >> >> /configure \ >> --disable-dynamic --disable-aci --enable-crypt --enable-lmpasswd \ >> --enable-spasswd --enable-rlookups --enable-slapi --enable-wrappers \ >> --enable-backends --disable-sql --enable-overlays \ >> CPPFLAGS='-DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' > > I built as: > > LD_LIBRARY_PATH="/usr/local/lib" CC=gcc CXX=g++ CFLAGS='-g -O0' > CXXFLAGS='-g -O0' CPPFLAGS='-DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' sh > configure --datadir='${prefix}/lib' --libexecdir='${prefix}/lib' > --sharedstatedir='${prefix}/lib' --prefix=/usr/local > --disable-ipv6 --with-cyrus-sasl --with-tls > --enable-dynamic --enable-slapd --enable-modules > --enable-spasswd --enable-rewrite > --enable-rlookups --enable-wrappers > --enable-backends=mod --disable-shell > --disable-sql --enable-overlays=mod --enable-slapi=yes > > > Thread package selected is: > > -pthread > > s,@LTHREAD_LIBS@, -pthread,;t t > > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5374) accesslog+hdb crash with test043-delta-syncrepl
by quanah＠zimbra.com 12 Feb '08

12 Feb '08

--On February 12, 2008 12:11:50 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE23 > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > /configure \ > --disable-dynamic --disable-aci --enable-crypt --enable-lmpasswd \ > --enable-spasswd --enable-rlookups --enable-slapi --enable-wrappers \ > --enable-backends --disable-sql --enable-overlays \ > CPPFLAGS='-DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' I built as: LD_LIBRARY_PATH="/usr/local/lib" CC=gcc CXX=g++ CFLAGS='-g -O0' CXXFLAGS='-g -O0' CPPFLAGS='-DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' sh configure --datadir='${prefix}/lib' --libexecdir='${prefix}/lib' --sharedstatedir='${prefix}/lib' --prefix=/usr/local --disable-ipv6 --with-cyrus-sasl --with-tls --enable-dynamic --enable-slapd --enable-modules --enable-spasswd --enable-rewrite --enable-rlookups --enable-wrappers --enable-backends=mod --disable-shell --disable-sql --enable-overlays=mod --enable-slapi=yes Thread package selected is: -pthread s,@LTHREAD_LIBS@, -pthread,;t t --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5375) Slapd core dumps
by quanah＠zimbra.com 12 Feb '08

12 Feb '08

--On February 12, 2008 2:58:12 PM +0000 ecip(a)gmv.es wrote: > Full_Name: Eduardo Izaguirre Pazos > Version: 2.4.7 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.0.110.2) > > > Hi all, we are using Openldap as a metadirectory against a couple of AD > servers. The slapd server core dumps when a request of all attributes of > one entry is issued. This is the output of the slapd server using the > debug level -1: Hi Eduardo, Please test with the current CVS of REL_ENG_2_4. Please build without optimization, and with debugging symbols. Make sure you don't strip slapd on install. If you can repeat this with current CVS, please provide a gdb backtrace of the non-optimized, non-stripped slapd. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5373) ppolicy issues when deleting the password attribute, even if no password checking is enforced
by quanah＠zimbra.com 12 Feb '08

12 Feb '08

This sounds like a duplicate of ITS#5285 to me. Which will be fixed in 2.4.8, but is not being fixed in 2.3. --Quanah --On February 12, 2008 9:57:46 AM +0000 Guillaume.Rousse(a)inria.fr wrote: > Full_Name: Guillaume Rousse > Version: 2.3.40 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.55.250.67) > > > Here are my ppolicy settings: > password policy > overlay ppolicy > ppolicy_use_lockout > ppolicy_default cn=default,ou=policies,dc=futurs,dc=inria,dc=fr > > Here is my default entry: > dn: cn=default,ou=policies,dc=futurs,dc=inria,dc=fr > cn: default > objectClass: pwdPolicy > objectClass: organizationalRole > pwdAttribute: userPassword > pwdMaxAge: 0 > pwdInHistory: 0 > pwdCheckQuality: 0 > > According to documentation, no user password quality checking should take > places, however, trying to delete userPassword attribute for an user > triggers at least a server error with this LDIF fragment: > dn: userdn > changetype: modify > delete: userPassword > > ldapmodify: Internal (implementation specific) error (80) > additional info: Internal Error > > Error message in logs: "cannot locate modification supplying new password" > > Or worst, a server crash with this one: > dn: userdn > changetype: modify > replace: userPassword > > No error message from ldapmodify, and no error message in the logs in > this case. > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5375) Slapd core dumps
by ecip＠gmv.es 12 Feb '08

12 Feb '08

Full_Name: Eduardo Izaguirre Pazos Version: 2.4.7 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.0.110.2) Hi all, we are using Openldap as a metadirectory against a couple of AD servers. The slapd server core dumps when a request of all attributes of one entry is issued. This is the output of the slapd server using the debug level -1: /opt/openldap-2.4.7/libexec/slapd -d -1 -f /opt/openldap-2.4.7/etc/openldap/slapd.conf -h "ldap://172.22.2.43/" and the output is: <<< dnPretty: <cn=Eduardo Izaguirre Pazos,ou=SISTEMAS,ou=people,dc=gmv,dc=es> Assertion failed: ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals ) || ( nvals != NULL && ( ( (*a)->a_vals == NULL && (*a)->a_nvals == NULL ) || ( (*a)->a_nvals != (*a)->a_vals ) ) ), file attr.c, line 480 The server wa compiled with the following configure: ./configure --prefix=/opt/openldap-2.4.7 --enable-cleartext --enable-crypt --enable-lmpasswd --enable-rewrite --enable-bdb --enable-ldap --enable-meta --with-tls --enable-proxycache --enable-rwm Cheers and thanks in advance. Eduardo

1 0

(ITS#5374) accesslog+hdb crash with test043-delta-syncrepl
by h.b.furuseth＠usit.uio.no 12 Feb '08

12 Feb '08

Full_Name: Hallvard B Furuseth Version: RE23 OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard /configure \ --disable-dynamic --disable-aci --enable-crypt --enable-lmpasswd \ --enable-spasswd --enable-rlookups --enable-slapi --enable-wrappers \ --enable-backends --disable-sql --enable-overlays \ CPPFLAGS='-DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' ./run -b hdb test043-delta-syncrepl server 1 crashes at accesslog.c line 918, which unlocks &li->li_op_mutex when it is owned by another thread. (Can also check it by setting li_unlock = (int) ldap_pvt_thread_self() instead of 1 after lock, and assert()ing the same before unlock.) accesslog_op_mod() has a comment /* FIXME: this needs to be a recursive mutex to allow * overlays like refint to keep working. */ ldap_pvt_thread_mutex_lock( &li->li_op_mutex ); but this problem is not recursive use of the mutex. (gdb) thread apply all backtrace Thread 4 (process 10963): #0 0x007e87a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00a64297 in pthread_join () from /lib/tls/libpthread.so.0 #2 0x081f0f62 in ldap_int_thread_join (thread=20061088, thread_return=0x0) at thr_posix.c:193 #3 0x081c3de4 in ldap_pvt_thread_join (thread=20061088, thread_return=0x0) at thr_debug.c:612 #4 0x0807bb54 in slapd_daemon () at daemon.c:2579 #5 0x08066554 in main (argc=8, argv=0xbfffefd4) at main.c:859 Thread 3 (process 10965): #0 0x007e87a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x008cb82e in epoll_wait () from /lib/tls/libc.so.6 #2 0x0807ae29 in slapd_daemon_task (ptr=0x0) at daemon.c:2174 #3 0x00a633cc in start_thread () from /lib/tls/libpthread.so.0 #4 0x008cb1ae in clone () from /lib/tls/libc.so.6 Thread 2 (process 10967): #0 0x007e87a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x008bc29b in __write_nocancel () from /lib/tls/libc.so.6 #2 0x0086064f in _IO_new_file_write () from /lib/tls/libc.so.6 #3 0x0086089c in _IO_new_file_xsputn () from /lib/tls/libc.so.6 #4 0x00855af1 in fputs () from /lib/tls/libc.so.6 #5 0x081f6160 in lutil_debug (debug=261, level=1, fmt=0x8237950 "<= key_change %d\n") at debug.c:89 #6 0x0814f485 in hdb_key_change (be=0x3061d24, db=0x838d518, txn=0x839bfe0, k=0xb7bba47c, id=16, op=1) at key.c:101 #7 0x0814e7ca in indexer (op=0x83799c0, txn=0x839bfe0, ad=0x830c6e8, atname=0x830d21c, vals=0x839aaa0, id=16, opid=1, mask=1814) at index.c:244 #8 0x0814e9a3 in index_at_values (op=0x83799c0, txn=0x839bfe0, ad=0x830c6e8, type=0x830d1e0, tags=0x830c6f8, vals=0x839aaa0, id=16, opid=1) at index.c:324 #9 0x0814eb05 in hdb_index_values (op=0x83799c0, txn=0x839bfe0, desc=0x830c6e8, vals=0x839aaa0, id=16, opid=1) at index.c:373 #10 0x0814eec1 in hdb_index_entry (op=0x83799c0, txn=0x839bfe0, opid=1, e=0x83946e8) at index.c:544 #11 0x0813ce65 in hdb_add (op=0x83799c0, rs=0x306218c) at add.c:304 #12 0x080e8903 in overlay_op_walk (op=0x83799c0, rs=0x306218c, which=op_add, oi=0x830c800, on=0x0) at backover.c:650 #13 0x080e8ab8 in over_op_func (op=0x83799c0, rs=0x306218c, which=op_add) at backover.c:702 #14 0x080e8bc4 in over_op_add (op=0x83799c0, rs=0x306218c) at backover.c:748 #15 0x080869e1 in fe_op_add (op=0x83799c0, rs=0x306218c) at add.c:342 #16 0x08086457 in do_add (op=0x83799c0, rs=0x306218c) at add.c:182 #17 0x0807e428 in connection_operation (ctx=0x3062218, arg_v=0x83799c0) at connection.c:1133 #18 0x081c1d40 in ldap_int_thread_pool_wrapper (xpool=0x82c86c8) at tpool.c:478 #19 0x00a633cc in start_thread () from /lib/tls/libpthread.so.0 #20 0x008cb1ae in clone () from /lib/tls/libc.so.6 Thread 1 (process 10976): #0 0x007e87a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00829815 in raise () from /lib/tls/libc.so.6 #2 0x0082b279 in abort () from /lib/tls/libc.so.6 #3 0x081c2b9e in error (file=0x82749bd "thr_debug.c", line=784, msg=0x82750a0 "ldap_pvt_thread_mutex_unlock", var=0x8274d72 "rc", val=1) at thr_debug.c:155 #4 0x081c44ec in ldap_pvt_thread_mutex_unlock (mutex=0x830cd04) at thr_debug.c:784 #5 0x08183fdf in accesslog_response (op=0x8386bc8, rs=0x220318c) at accesslog.c:918 #6 0x08184f14 in accesslog_mod_cleanup (op=0x8386bc8, rs=0x220318c) at accesslog.c:1241 #7 0x0808fcca in send_ldap_response (op=0x8386bc8, rs=0x220318c) at result.c:458 #8 0x080903f1 in slap_send_ldap_result (op=0x8386bc8, rs=0x220318c) at result.c:574 #9 0x0813d474 in hdb_add (op=0x8386bc8, rs=0x220318c) at add.c:409 #10 0x080e8903 in overlay_op_walk (op=0x8386bc8, rs=0x220318c, which=op_add, oi=0x830c800, on=0x0) at backover.c:650 #11 0x080e8ab8 in over_op_func (op=0x8386bc8, rs=0x220318c, which=op_add) at backover.c:702 #12 0x080e8bc4 in over_op_add (op=0x8386bc8, rs=0x220318c) at backover.c:748 #13 0x080869e1 in fe_op_add (op=0x8386bc8, rs=0x220318c) at add.c:342 #14 0x08086457 in do_add (op=0x8386bc8, rs=0x220318c) at add.c:182 #15 0x0807e428 in connection_operation (ctx=0x2203218, arg_v=0x8386bc8) at connection.c:1133 #16 0x081c1d40 in ldap_int_thread_pool_wrapper (xpool=0x82c86c8) at tpool.c:478 #17 0x00a633cc in start_thread () from /lib/tls/libpthread.so.0 #18 0x008cb1ae in clone () from /lib/tls/libc.so.6

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs