openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#5533) test035-meta crashes --without-threads
by pierangelo.masarati＠sys-net.it 31 May '08

31 May '08

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 ---------------------------------------

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by hyc＠symas.com 31 May '08

31 May '08

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/

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 30 May '08

30 May '08

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

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 30 May '08

30 May '08

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

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by hyc＠symas.com 30 May '08

30 May '08

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/

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 30 May '08

30 May '08

------=_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, <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: <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. --------------050600010007030200030106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit <div class="Ih2E3d"> <a href="mailto:hyc@symas.com">hyc(a)symas.com</a> wrote: > We'll probably need to discuss on the -devel list what steps to take from here. > </div>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. <div class="Ih2E3d"> --   -- Howard Chu   CTO, Symas Corp.           <a href="http://www.symas.com" target="_blank">http://www.symas.com</a>   Director, Highland Sun     <a href="http://highlandsun.com/hyc/" target="_blank">http://highlandsun.com/hyc/</a>   Chief Architect, OpenLDAP  <a href="http://www.openldap.org/project/" target="_blank">http://www.openldap.org/project/</a> </div>--------------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 <a href="http://1.112.2.7" target="_blank">1.112.2.7</a> diff -u -r1.112.2.7 attr.c --- attr.c      11 Feb 2008 23:26:43 -0000      <a href="http://1.112.2.7" target="_blank">1.112.2.7</a> +++ 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;</blockquote><div> Not all attributes have an equality matching rule.  This causes your patch to segfault since sat_equality is NULL: <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; </blockquote> This seems to be a better way to generate have_norm: <blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">have_norm = a->a_desc->ad_type->sat_equality != NULL &&           a->a_desc->ad_type->sat_equality->smr_normalize != NULL; </blockquote> 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? </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; +               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-- </blockquote></div> -- Thanks, Sean Burford ------=_Part_7327_2415938.1212167698754--

1 0

Re: (ITS#5541) slapd segfaults with specific search on string bdb and hdb backend
by hyc＠symas.com 30 May '08

30 May '08

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/

1 0

Re: (ITS#5542) Bug in libldap/t61.c (for your information)
by hyc＠symas.com 30 May '08

30 May '08

emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.3.39 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.68.44.148) > In t61.c/ldap_utf8s_to_t61s(), the second loop is an infinite loop, there misses > a "i += j; c += j" at the end of the loop. Congratulations, you're the first person to use this code in over 6 years. Out of curiosity, why do you need it? Thanks for the report, fixed in CVS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5542) Bug in libldap/t61.c (for your information)
by emmanuel.duru＠atosorigin.com 30 May '08

30 May '08

Full_Name: Emmanuel Duru Version: 2.3.39 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.68.44.148) In t61.c/ldap_utf8s_to_t61s(), the second loop is an infinite loop, there misses a "i += j; c += j" at the end of the loop.

1 0

(ITS#5541) slapd segfaults with specific search on string bdb and hdb backend
by pwadas＠jewish.org.pl 30 May '08

30 May '08

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. 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 #5 0xb7303064 in list_candidates (op=0x82792e0, locker=34, flist=0xa96e31ec, ftype=160, ids=0xa8fe2008, tmp=0xa8ee2008, save=0xa9062008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:581 #6 0xb73017c7 in bdb_filter_candidates (op=0x82792e0, locker=34, f=0xa96e32bc, ids=0xa8fe2008, tmp=0xa8ee2008, stack=0xa9062008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:198 #7 0xb7303064 in list_candidates (op=0x82792e0, locker=34, flist=0xa9be2ec8, ftype=161, ids=0xa8f62008, tmp=0xa8ee2008, save=0xa8fe2008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:581 #8 0xb73015ca in bdb_filter_candidates (op=0x82792e0, locker=34, f=0xa9be2ebc, ids=0xa8f62008, tmp=0xa8ee2008, stack=0xa8fe2008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:204 #9 0xb7303064 in list_candidates (op=0x82792e0, locker=34, flist=0xa9be2eb0, ftype=160, ids=0xa9b22e1c, tmp=0xa8ee2008, save=0xa8f62008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:581 #10 0xb73017c7 in bdb_filter_candidates (op=0x82792e0, locker=34, f=0xa9be2ed4, ids=0xa9b22e1c, tmp=0xa8ee2008, stack=0xa8f62008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:198 #11 0xb72fc858 in bdb_search (op=0x82792e0, rs=0xa9be4168) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/search.c:1109 #12 0x080d76f1 in overlay_op_walk (op=0x82792e0, rs=0xa9be4168, which=op_search, oi=0x81f63d8, on=0x81f64d8) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/backover.c:646 #13 0x080d7c5d in over_op_func (op=0x82792e0, rs=0xa9be4168, which=op_search) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/backover.c:698 #14 0x08077fd3 in fe_op_search (op=0x82792e0, rs=0xa9be4168) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/search.c:366 #15 0x080787fc in do_search (op=0x82792e0, rs=0xa9be4168) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/search.c:217 #16 0x08075a9f in connection_operation (ctx=0xa9be4248, arg_v=0x82792e0) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/connection.c:1084 #17 0x08076196 in connection_read_thread (ctx=0xa9be4248, argv=0x10) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/connection.c:1211 #18 0xb7ea1d64 in ldap_int_thread_pool_wrapper (xpool=0x81b09b8) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/libldap_r/tpool.c:663 #19 0xb7c2c4fb in start_thread () from /usr/lib/i486-linux-gnu/i686/cmov/libpthread.so.0 #20 0xb7bafe8e in clone () from /usr/lib/i486-linux-gnu/i686/cmov/libc.so.6

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs