Re: (ITS#5378) hot slapcat for slapadd issues with delta-sync
by ando＠sys-net.it
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
---------------------------------------
15 years, 7 months
Re: ITS#5375
by ando＠sys-net.it
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
---------------------------------------
15 years, 7 months
Re: (ITS#5378) hot slapcat for slapadd issues with delta-sync
by hyc＠OpenLDAP.org
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/
15 years, 7 months
(ITS#5378) hot slapcat for slapadd issues with delta-sync
by quanah＠OpenLDAP.org
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
15 years, 7 months
RE: (ITS#5375) Slapd core dumps (fwd)
by quanah＠zimbra.com
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
15 years, 7 months
RE: (ITS#5375) Slapd core dumps (fwd)
by quanah＠zimbra.com
------------ 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
15 years, 7 months
RE: (ITS#5375) Slapd core dumps (fwd)
by quanah＠zimbra.com
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
15 years, 7 months
Re: (ITS#5376) Full sync fails with delta-syncrepl, refreshAndPersist, and high modifications
by quanah＠zimbra.com
--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
15 years, 7 months
ITS#5375
by ecizaguirre＠gmv.com
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.
______________________
15 years, 7 months
(ITS#5377) Why can I delete attributeType and objectClass together
by bsdrab＠gmail.com
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"
15 years, 7 months
