Re: (ITS#5533) test035-meta crashes --without-threads
by pierangelo.masarati＠sys-net.it
Hallvard B Furuseth wrote:
> pierangelo.masarati(a)sys-net.it writes:
>
>> I couldn't reproduce this issue with HEAD; do you confirm it's a re24 only?
>>
>
> Still happens in HEAD as well as RE24. Not RE23 though.
>
Odd. I've been running test035 in HEAD for >100 times after rebuilding
--without-threads with no failure. Anything I might be missing?
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, 4 months
Re: (ITS#5533) test035-meta crashes --without-threads
by h.b.furuseth＠usit.uio.no
pierangelo.masarati(a)sys-net.it writes:
> I couldn't reproduce this issue with HEAD; do you confirm it's a re24 only?
Still happens in HEAD as well as RE24. Not RE23 though.
--
Hallvard
15 years, 4 months
Re: (ITS#5533) test035-meta crashes --without-threads
by pierangelo.masarati＠sys-net.it
h.b.furuseth(a)usit.uio.no wrote:
> quanah(a)zimbra.com writes:
>
>> Isn't this just a duplicate of ITS#5489?
>>
>
> Apparently not. Got it again at 4th run with daemon.c 1.380.2.12.
> Also in a somewhat patched HEAD with the same configuration.
>
> Hm, the crashes happen for extended operations. So far
> 6 times "Passwd ExOp failed (1)!", once "WhoAmI failed (49)!".
>
I couldn't reproduce this issue with HEAD; do you confirm it's a re24 only?
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, 4 months
Re: (ITS#5540) Normalization assertion in attr.c
by hyc＠symas.com
Sean Burford wrote:
> Hi,
>
> On Fri, May 30, 2008 at 2:40 AM,<hyc(a)symas.com> wrote:
>> I wrote the attached patch for the original issue. Unfortunately it asserted
>> right away:
> ...
>> It was adding the createTimestamp attribute, without providing normalized
>> values. slap_add_opattrs was written before the generalizedTimeNormalize
>> function was written... I suspect there will be a fair number of cases that
>> need to be cleaned up. I don't have time at the moment to chase them all down.
>> Anyone else want to jump in here? If not, we may have to push this back a bit.
>
> I've modified my copy of the source to normalize data where needed.
> slapd starts up and my test can run. With the old assertion in place
> it fails exactly as it did before, because the old attr_merge()
> assertion runs before your new attr_valadd() normalization check.
That aspect of the patch is not optional. The old check is in the wrong place
and must be removed. It misses the other places where attrs are being added,
while attr_valadd catches all of them.
> Removing the old attr_merge() assertion results in your new
> attr_valadd() check being triggered. Removing the old assertion looks
> safe, since attr_merge() calls attr_valadd() almost immediately after
> the assertion anyway.
>
> With these changes, running my test script from the original tarball results in:
> bdb_modify_internal: add testAttribute
> attr_valadd: database inconsistent with schema definition of
> testAttribute, reload the DB
> bdb_modify_internal: 80 modify/add: testAttribute: merge error (80)
> hdb_modify: modify failed (80)
>
> I'm working through 'make test' now to find more instances that need
> fixing. After that I'll send some patches.
>
>> Note that this patch will probably require a fair number of databases to be
>> reloaded.
>
> I'm not even sure that attributes can be automatically renormalized
> when a problem is detected, since bugs (eg. with the generation of
> timestamps, CSNs or referalls) can also trigger the normalization
> checks.
I think it's important to continue to assert as in my patch, at least at this
stage, so we can catch all of those bugs. I also don't think we can silently
renormalize just the cases that the "reload the DB" message detects, because
that's obviously only going to happen on entries that are explicitly modified,
and the rest of the DB will still have problems.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 4 months
Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com
I'm having some trouble working out where to set the normalized value
for ContextCSN in the modlist for the syncrepl refresh consumer
(test017-syncreplication-refresh fails).
The assertion backtrace looks like this:
#0 0x00007f472879d095 in raise () from /lib/libc.so.6
#1 0x00007f472879eaf0 in abort () from /lib/libc.so.6
#2 0x00007f47287962df in __assert_fail () from /lib/libc.so.6
#3 0x0000000000425903 in attr_valadd (a=0x8fb380, vals=0xc72130,
nvals=0x0, nn=1) at attr.c:398
#4 0x000000000046714c in modify_add_values (e=0x41ff5bb0,
mod=0x41ff60e0, permissive=0, text=0x41ff6090,
textbuf=0x41ff5cb0 "", textlen=256) at mods.c:155
#5 0x000000000048147d in bdb_modify_internal (op=0x41ff6780,
tid=0xc71f50, modlist=0x41ff60e0, e=0x41ff5bb0,
text=0x41ff6090, textbuf=0x41ff5cb0 "", textlen=256) at modify.c:133
#6 0x0000000000481f6d in bdb_modify (op=0x41ff6780, rs=0x41ff6070) at
modify.c:578
#7 0x0000000000477d32 in overlay_op_walk (op=0x41ff6780,
rs=0x41ff6070, which=op_modify, oi=0x858990, on=0x0)
at backover.c:646
#8 0x00000000004782b3 in over_op_func (op=0x41ff6780, rs=0x41ff6070,
which=op_modify) at backover.c:698
#9 0x000000000046dc59 in syncrepl_updateCookie (si=0x858560,
op=0x249e, pdn=<value optimized out>, syncCookie=0x41ff6310)
at syncrepl.c:2785
#10 0x0000000000472bea in do_syncrep2 (op=0x41ff6780, si=0x858560) at
syncrepl.c:961
#11 0x0000000000475072 in do_syncrepl (ctx=0x0, arg=0x8588f0) at syncrepl.c:1276
#12 0x00000000004daa4a in ldap_int_thread_pool_wrapper
(xpool=0x82e440) at tpool.c:663
#13 0x00007f47296d03f7 in start_thread () from /lib/libpthread.so.0
#14 0x00007f4728842b2d in clone () from /lib/libc.so.6
#15 0x0000000000000000 in ?? ()
In frame 3 a->a_desc->ad_type->sat_equality has a value but nvals has
not been set, which is why the assertion triggers:
(gdb) print a->a_desc->ad_type->sat_equality
$39 = (MatchingRule *) 0x821be0
Way back in frame 10 do_syncrepl passes a modlist containing an
unnormalized contextCSN to do_syncrep2, leading me to believe that
I've missed something in syncrepl.c:
(gdb) print *op->o_request->oq_modify->rs_mods->rs_modlist
$44 = {sml_mod = {sm_desc = 0x824b70, sm_values = 0xc72130, sm_nvalues
= 0x0, sm_numvals = 1, sm_op = 2, sm_flags = 0, sm_type = {bv_len =
10, bv_val = 0x824be0 "contextCSN"}}, sml_next = 0x0}
The debug output up to the assertion is:
slap_queue_csn: queing 0xc72ae0 20080531010928.580166Z#000000#000#000000
daemon: epoll: listen=10 active_threads=0 tvp=zero
=> bdb_entry_get: ndn: "dc=example,dc=com"
=> bdb_entry_get: oc: "(null)", at: "(null)"
bdb_dn2entry("dc=example,dc=com")
=> bdb_entry_get: found entry: "dc=example,dc=com"
bdb_entry_get: rc=0
bdb_modify: dc=example,dc=com
bdb_dn2entry("dc=example,dc=com")
bdb_modify_internal: 0x00000001: dc=example,dc=com
<= acl_access_allowed: granted to database root
bdb_modify_internal: replace contextCSN
slapd: attr.c:398: attr_valadd: Assertion `have_norm == new_nval' failed.
--
Thanks,
Sean Burford
15 years, 4 months
Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com
Hi,
On Fri, May 30, 2008 at 2:40 AM, <hyc(a)symas.com> wrote:
>
> I wrote the attached patch for the original issue. Unfortunately it asserted
> right away:
...
> It was adding the createTimestamp attribute, without providing normalized
> values. slap_add_opattrs was written before the generalizedTimeNormalize
> function was written... I suspect there will be a fair number of cases that
> need to be cleaned up. I don't have time at the moment to chase them all down.
> Anyone else want to jump in here? If not, we may have to push this back a bit.
I've modified my copy of the source to normalize data where needed.
slapd starts up and my test can run. With the old assertion in place
it fails exactly as it did before, because the old attr_merge()
assertion runs before your new attr_valadd() normalization check.
Removing the old attr_merge() assertion results in your new
attr_valadd() check being triggered. Removing the old assertion looks
safe, since attr_merge() calls attr_valadd() almost immediately after
the assertion anyway.
With these changes, running my test script from the original tarball results in:
bdb_modify_internal: add testAttribute
attr_valadd: database inconsistent with schema definition of
testAttribute, reload the DB
bdb_modify_internal: 80 modify/add: testAttribute: merge error (80)
hdb_modify: modify failed (80)
I'm working through 'make test' now to find more instances that need
fixing. After that I'll send some patches.
> Note that this patch will probably require a fair number of databases to be
> reloaded.
I'm not even sure that attributes can be automatically renormalized
when a problem is detected, since bugs (eg. with the generation of
timestamps, CSNs or referalls) can also trigger the normalization
checks.
--
Thanks,
Sean Burford
15 years, 4 months
Re: (ITS#5540) Normalization assertion in attr.c
by hyc＠symas.com
Sean Burford wrote:
> Not all attributes have an equality matching rule. This causes your
> patch to segfault since sat_equality is NULL:
>
> have_norm = a->a_desc->ad_type->sat_equality->smr_normalize != NULL;
>
>
> This seems to be a better way to generate have_norm:
>
> have_norm = a->a_desc->ad_type->sat_equality != NULL &&
> a->a_desc->ad_type->sat_equality->smr_normalize != NULL;
Thanks, looks fine.
> Once that is fixed the config backend causes an assert for me when it
> attempts to add createTimestamp, which is exactly the problem you describe.
>
> I'll create a patch that addresses any of these normalization issues
> that I can identify and send it to one of the openldap lists. Would
> openldap-its or openldap-devel be preferable?
Just continue to reply to this ITS for now.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 4 months
Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com
------=_Part_7327_2415938.1212167698754
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi,
On Fri, May 30, 2008 at 2:40 AM, <hyc(a)symas.com> wrote:
> This is a multi-part message in MIME format.
> --------------050600010007030200030106
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
>
> hyc(a)symas.com wrote:
> > We'll probably need to discuss on the -devel list what steps to take from
> here.
> >
> I wrote the attached patch for the original issue. Unfortunately it
> asserted
> right away:
>
> [Switching to Thread 1090525504 (LWP 23577)]
> 0x00002b55e738d535 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0 0x00002b55e738d535 in raise () from /lib64/libc.so.6
> #1 0x00002b55e738e990 in abort () from /lib64/libc.so.6
> #2 0x00002b55e7386c16 in __assert_fail () from /lib64/libc.so.6
> #3 0x00000000004410e5 in attr_valadd (a=0xb866c8, vals=0x41000670,
> nvals=0x0,
> nn=1) at ../../../r24/servers/slapd/attr.c:394
> #4 0x0000000000441a06 in attr_merge_one (e=0xb72c08, desc=0x8b3780,
> val=0x41000670, nval=0x0)
> at ../../../r24/servers/slapd/attr.c:599
> #5 0x000000000043ea0f in slap_add_opattrs (op=0x965ec0, text=<value
> optimized
> out>, textbuf=<value optimized out>,
> textlen=<value optimized out>, manage_ctxcsn=<value optimized out>) at
> ../../../r24/servers/slapd/add.c:664
> #6 0x00000000004d9c42 in hdb_add (op=0x965ec0, rs=0x41000ca0) at add.c:108
> #7 0x000000000043f1a6 in fe_op_add (op=0x965ec0, rs=0x41000ca0) at
> ../../../r24/servers/slapd/add.c:334
> #8 0x000000000043fa12 in do_add (op=0x965ec0, rs=0x41000ca0) at
> ../../../r24/servers/slapd/add.c:194
> #9 0x00000000004383a7 in connection_operation (ctx=0x41000de0,
> arg_v=0x965ec0) at ../../../r24/servers/slapd/connection.c:1084
> #10 0x00000000004388cf in connection_read_thread (ctx=0x41000de0, argv=0xc)
> at
> ../../../r24/servers/slapd/connection.c:1211
> #11 0x000000000054b8ca in ldap_int_thread_pool_wrapper (xpool=0x8bf070) at
> ../../../r24/libraries/libldap_r/tpool.c:663
> #12 0x00002b55e655e09e in start_thread () from /lib64/libpthread.so.0
> #13 0x00002b55e741e4cd in clone () from /lib64/libc.so.6
> #14 0x0000000000000000 in ?? ()
>
> It was adding the createTimestamp attribute, without providing normalized
> values. slap_add_opattrs was written before the generalizedTimeNormalize
> function was written... I suspect there will be a fair number of cases that
> need to be cleaned up. I don't have time at the moment to chase them all
> down.
> Anyone else want to jump in here? If not, we may have to push this back a
> bit.
> Note that this patch will probably require a fair number of databases to be
> reloaded.
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
> --------------050600010007030200030106
> Content-Type: text/plain;
> name="dif.txt"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
> filename="dif.txt"
>
> Index: attr.c
> ===================================================================
> RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/attr.c,v
> retrieving revision 1.112.2.7
> diff -u -r1.112.2.7 attr.c
> --- attr.c 11 Feb 2008 23:26:43 -0000 1.112.2.7
> +++ attr.c 30 May 2008 09:33:43 -0000
> @@ -366,8 +366,39 @@
> BerVarray nvals,
> int nn )
> {
> - int i;
> BerVarray v2;
> + int i;
> +
> + {
> + /* FIXME: if the schema has been edited, and an equality
> matching rule
> + * has been added or removed from the attribute definition,
> the database
> + * values may no longer be in sync with our expectations.
> Currently this
> + * means the DB must be reloaded.
> + */
> + int have_norm, have_nval, new_nval;
> + have_norm = a->a_desc->ad_type->sat_equality->smr_normalize
> != NULL;
Not all attributes have an equality matching rule. This causes your patch
to segfault since sat_equality is NULL:
> have_norm = a->a_desc->ad_type->sat_equality->smr_normalize != NULL;
>
This seems to be a better way to generate have_norm:
> have_norm = a->a_desc->ad_type->sat_equality != NULL &&
> a->a_desc->ad_type->sat_equality->smr_normalize != NULL;
>
Once that is fixed the config backend causes an assert for me when it
attempts to add createTimestamp, which is exactly the problem you describe.
I'll create a patch that addresses any of these normalization issues that I
can identify and send it to one of the openldap lists. Would openldap-its
or openldap-devel be preferable?
+ have_nval = a->a_nvals != a->a_vals;
> + new_nval = nvals != NULL;
> +
> + /* this check is only relevant if any values already exist
> */
> + if ( a->a_vals != NULL && have_norm != have_nval ) {
> + Debug(LDAP_DEBUG_ANY,
> + "attr_valadd: database inconsistent with
> schema definition of %s, reload the DB\n",
> + a->a_desc->ad_cname.bv_val, 0, 0 );
> + return LDAP_OTHER;
> + /* no need to compare have_nval with new_nval; by
> transitivity they will match if
> + * the above check and the following check succeed.
> + */
> + }
> +
> + assert( have_norm == new_nval );
> + if ( have_norm != new_nval ) {
> + Debug(LDAP_DEBUG_ANY,
> + "attr_valadd: new values of %s not properly
> normalized (should never happen!)\n",
> + a->a_desc->ad_cname.bv_val, 0, 0 );
> + return LDAP_OTHER;
> + }
> + }
>
> v2 = (BerVarray) SLAP_REALLOC( (char *) a->a_vals,
> (a->a_numvals + nn + 1) * sizeof(struct berval) );
> @@ -469,15 +500,6 @@
>
> if ( *a == NULL ) {
> *a = attr_alloc( desc );
> - } else {
> - /*
> - * FIXME: if the attribute already exists, the presence
> - * of nvals and the value of (*a)->a_nvals must be
> consistent
> - */
> - assert( ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals )
> - || ( nvals != NULL && (
> - ( (*a)->a_vals == NULL &&
> (*a)->a_nvals == NULL )
> - || ( (*a)->a_nvals != (*a)->a_vals
> ) ) ) );
> }
>
> if ( vals != NULL ) {
>
> --------------050600010007030200030106--
>
>
>
--
Thanks,
Sean Burford
------=_Part_7327_2415938.1212167698754
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi,<br><br><div class="gmail_quote">On Fri, May 30, 2008 at 2:40 AM, <<a href="mailto:hyc@symas.com">hyc(a)symas.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This is a multi-part message in MIME format.<br>
--------------050600010007030200030106<br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
Content-Transfer-Encoding: 7bit<br>
<div class="Ih2E3d"><br>
<a href="mailto:hyc@symas.com">hyc(a)symas.com</a> wrote:<br>
> We'll probably need to discuss on the -devel list what steps to take from here.<br>
><br>
</div>I wrote the attached patch for the original issue. Unfortunately it asserted<br>
right away:<br>
<br>
[Switching to Thread 1090525504 (LWP 23577)]<br>
0x00002b55e738d535 in raise () from /lib64/libc.so.6<br>
(gdb) bt<br>
#0 0x00002b55e738d535 in raise () from /lib64/libc.so.6<br>
#1 0x00002b55e738e990 in abort () from /lib64/libc.so.6<br>
#2 0x00002b55e7386c16 in __assert_fail () from /lib64/libc.so.6<br>
#3 0x00000000004410e5 in attr_valadd (a=0xb866c8, vals=0x41000670, nvals=0x0,<br>
nn=1) at ../../../r24/servers/slapd/attr.c:394<br>
#4 0x0000000000441a06 in attr_merge_one (e=0xb72c08, desc=0x8b3780,<br>
val=0x41000670, nval=0x0)<br>
at ../../../r24/servers/slapd/attr.c:599<br>
#5 0x000000000043ea0f in slap_add_opattrs (op=0x965ec0, text=<value optimized<br>
out>, textbuf=<value optimized out>,<br>
textlen=<value optimized out>, manage_ctxcsn=<value optimized out>) at<br>
../../../r24/servers/slapd/add.c:664<br>
#6 0x00000000004d9c42 in hdb_add (op=0x965ec0, rs=0x41000ca0) at add.c:108<br>
#7 0x000000000043f1a6 in fe_op_add (op=0x965ec0, rs=0x41000ca0) at<br>
../../../r24/servers/slapd/add.c:334<br>
#8 0x000000000043fa12 in do_add (op=0x965ec0, rs=0x41000ca0) at<br>
../../../r24/servers/slapd/add.c:194<br>
#9 0x00000000004383a7 in connection_operation (ctx=0x41000de0,<br>
arg_v=0x965ec0) at ../../../r24/servers/slapd/connection.c:1084<br>
#10 0x00000000004388cf in connection_read_thread (ctx=0x41000de0, argv=0xc) at<br>
../../../r24/servers/slapd/connection.c:1211<br>
#11 0x000000000054b8ca in ldap_int_thread_pool_wrapper (xpool=0x8bf070) at<br>
../../../r24/libraries/libldap_r/tpool.c:663<br>
#12 0x00002b55e655e09e in start_thread () from /lib64/libpthread.so.0<br>
#13 0x00002b55e741e4cd in clone () from /lib64/libc.so.6<br>
#14 0x0000000000000000 in ?? ()<br>
<br>
It was adding the createTimestamp attribute, without providing normalized<br>
values. slap_add_opattrs was written before the generalizedTimeNormalize<br>
function was written... I suspect there will be a fair number of cases that<br>
need to be cleaned up. I don't have time at the moment to chase them all down.<br>
Anyone else want to jump in here? If not, we may have to push this back a bit.<br>
Note that this patch will probably require a fair number of databases to be<br>
reloaded.<br>
<div class="Ih2E3d"><br>
--<br>
-- Howard Chu<br>
CTO, Symas Corp. <a href="http://www.symas.com" target="_blank">http://www.symas.com</a><br>
Director, Highland Sun <a href="http://highlandsun.com/hyc/" target="_blank">http://highlandsun.com/hyc/</a><br>
Chief Architect, OpenLDAP <a href="http://www.openldap.org/project/" target="_blank">http://www.openldap.org/project/</a><br>
<br>
</div>--------------050600010007030200030106<br>
Content-Type: text/plain;<br>
name="dif.txt"<br>
Content-Transfer-Encoding: 7bit<br>
Content-Disposition: inline;<br>
filename="dif.txt"<br>
<br>
Index: attr.c<br>
===================================================================<br>
RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/attr.c,v<br>
retrieving revision <a href="http://1.112.2.7" target="_blank">1.112.2.7</a><br>
diff -u -r1.112.2.7 attr.c<br>
--- attr.c 11 Feb 2008 23:26:43 -0000 <a href="http://1.112.2.7" target="_blank">1.112.2.7</a><br>
+++ attr.c 30 May 2008 09:33:43 -0000<br>
@@ -366,8 +366,39 @@<br>
BerVarray nvals,<br>
int nn )<br>
{<br>
- int i;<br>
BerVarray v2;<br>
+ int i;<br>
+<br>
+ {<br>
+ /* FIXME: if the schema has been edited, and an equality matching rule<br>
+ * has been added or removed from the attribute definition, the database<br>
+ * values may no longer be in sync with our expectations. Currently this<br>
+ * means the DB must be reloaded.<br>
+ */<br>
+ int have_norm, have_nval, new_nval;<br>
+ have_norm = a->a_desc->ad_type->sat_equality->smr_normalize != NULL;</blockquote><div><br>Not all attributes have an equality matching rule. This causes your patch to
segfault since sat_equality is NULL:<br>
<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; font-family: courier new,monospace;" class="gmail_quote">have_norm = a->a_desc->ad_type->sat_equality->smr_normalize != NULL;<br>
</blockquote>
<br>This seems to be a better way to generate
have_norm:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><span style="font-family: courier new,monospace;">have_norm = a->a_desc->ad_type->sat_equality != NULL &&</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> a->a_desc->ad_type->sat_equality->smr_normalize != NULL;</span><br></blockquote><br>Once that is fixed the config backend causes an assert for me when it attempts to add createTimestamp, which is exactly the problem you describe.<br>
<br>I'll create a patch that addresses any of these normalization issues that I can identify and send it to one of the openldap lists. Would openldap-its or openldap-devel be preferable?<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
+ have_nval = a->a_nvals != a->a_vals;<br>
+ new_nval = nvals != NULL;<br>
+<br>
+ /* this check is only relevant if any values already exist */<br>
+ if ( a->a_vals != NULL && have_norm != have_nval ) {<br>
+ Debug(LDAP_DEBUG_ANY,<br>
+ "attr_valadd: database inconsistent with schema definition of %s, reload the DB\n",<br>
+ a->a_desc->ad_cname.bv_val, 0, 0 );<br>
+ return LDAP_OTHER;<br>
+ /* no need to compare have_nval with new_nval; by transitivity they will match if<br>
+ * the above check and the following check succeed.<br>
+ */<br>
+ }<br>
+<br>
+ assert( have_norm == new_nval );<br>
+ if ( have_norm != new_nval ) {<br>
+ Debug(LDAP_DEBUG_ANY,<br>
+ "attr_valadd: new values of %s not properly normalized (should never happen!)\n",<br>
+ a->a_desc->ad_cname.bv_val, 0, 0 );<br>
+ return LDAP_OTHER;<br>
+ }<br>
+ }<br>
<br>
v2 = (BerVarray) SLAP_REALLOC( (char *) a->a_vals,<br>
(a->a_numvals + nn + 1) * sizeof(struct berval) );<br>
@@ -469,15 +500,6 @@<br>
<br>
if ( *a == NULL ) {<br>
*a = attr_alloc( desc );<br>
- } else {<br>
- /*<br>
- * FIXME: if the attribute already exists, the presence<br>
- * of nvals and the value of (*a)->a_nvals must be consistent<br>
- */<br>
- assert( ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals )<br>
- || ( nvals != NULL && (<br>
- ( (*a)->a_vals == NULL && (*a)->a_nvals == NULL )<br>
- || ( (*a)->a_nvals != (*a)->a_vals ) ) ) );<br>
}<br>
<br>
if ( vals != NULL ) {<br>
<br>
--------------050600010007030200030106--<br>
<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>Thanks,<br>Sean Burford
------=_Part_7327_2415938.1212167698754--
15 years, 4 months
Re: (ITS#5541) slapd segfaults with specific search on string bdb and hdb backend
by hyc＠symas.com
pwadas(a)jewish.org.pl wrote:
> Full_Name: Piotr Wadas
> Version: 2.4.7 upto 2.4.9
> OS: debian 2.6.18+ kernel
> URL:
> Submission from: (NULL) (195.95.182.4)
>
>
> The issue is discussed at
> http://www.openldap.org/lists/openldap-software/200805/msg00136.html
>
> List message contains debug information, steps to reproduce,
> backtrace logs etc.
> Issue appears since 2.4.7 in 2.4 series.
The config info you posted is missing your index configuration, which is most
relevant here.
From your traces, we could use a little more info as well:
frame 4
print *ava->aa_desc
print *mr
>
> gdb bt quick ref:
>
> #0 0xb7b4842c in free () from /usr/lib/i486-linux-gnu/i686/cmov/libc.so.6
> #1 0xb7e901aa in ber_memfree_x (p=0x0, ctx=0x0) at
> /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory.c:152
> #2 0xb7e9019c in ber_memfree_x (p=0x0, ctx=0x0) at
> /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory.c:159
> #3 0xb7e90235 in ber_bvarray_free_x (a=0xa96e3354, ctx=0x8279658) at
> /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory.c:731
> #4 0xb73028e5 in bdb_filter_candidates (op=0x82792e0, locker=34, f=0xa96e325c,
> ids=0xa9062008, tmp=0xa8ee2008, stack=0xa90e2008)
> at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:803
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 4 months
