openldap-bugs February 2008

openldap-bugs@openldap.org

42 participants
207 discussions

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

← Newer
1
...
5
6
7
8
9
10
11
...
21
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2008