openldap-bugs March 2008

openldap-bugs@openldap.org

34 participants
162 discussions

Re: Segfault in slapd 2.4.8 - syncrepl and glue (ITS#5430)
by Duncan.Gibb＠SiriusIT.co.uk 18 Mar '08

18 Mar '08

Thanks, Gavin. My GDB foo is not up to getting useful info out of your core dump, but I have placed one from one of our test rigs at http://pastebin.siriusit.co.uk/slapd-2.4.8-nullpointer-bin-and-core.tar.gz Note that this expects to be looked at with 64-bit GDB 6.7.1 from Debian Lenny/Sid (GDB 6.4.90 from Etch doesn't work). Re your previous comments: The engineer who put together the test case did look for bug reporting guidelines, but their location in the FAQ is, IMHO, non-obvious; perhaps one day I'll fix that. I reviewed and edited the report before sending it and I think it meets any reasonable person's definition of at least attempting to be helpful whilst not unduly verbose. Posting to the wrong list was my fault and I apologise. The moderator was correct to reject the original message. We know all kinds of weird stuff happens if you restart the crashed server(s) - that's how we come to be looking at this in the first place. We have, however, tried very hard to come up with a simple, confined case of this particular null pointer dereference, which is the first thing that goes wrong if you start from a clean sheet with empty databases each time and follow the recipe. In the four environments we can easily construct (RHEL vs Debian, i386 vs amd64) the segfault of server1 happens immediately you submit any change via LDAP to server2. Can anyone else reproduce this, or do we need to work on more examples? Cheers Duncan

1 0

(ITS#5436) htons() expects an unsigned short
by rein＠basefarm.no 18 Mar '08

18 Mar '08

Full_Name: Rein Tollevik Version: 2.4.8 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.215.2.34) libraries/libldap/os-ip.c casts the argument to htons() to a short, it should be an explicit unsigned short. This causes the use of high port numbers to fail on systems where shorts are signed by default. Rein Tollevik Basefarm AS

1 0

(ITS#5435) Seg. fault due to dereference of NULL ConfigReply * arguments.
by rein＠basefarm.no 18 Mar '08

18 Mar '08

Full_Name: Rein Tollevik Version: 2.4.8 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.215.2.34) Functions in servers/slapd/back-bdb/init.c dereference their ConfigReply * arguments without testing that they are non-NULL first, which causes seg. faults. I have only seen this happen when I tried to slapcat a database that hadn't had its directory created or some other stupidity, but anyhow... I don't include my patch to this, as it is probably easier to fix it again in your source than to apply a patch. Rein Tollevik Basefarm AS

1 0

(ITS#5434) syncprov in a glue'ed environment must search through the glue overlay
by rein＠basefarm.no 18 Mar '08

18 Mar '08

Full_Name: Rein Tollevik Version: 2.4.8 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.215.2.34) When the syncprov overlay is stacked on top of other overlays (notably the glue overlay) it must search through the next overlay, not the original backend DB. Otherwise it will not find any entries from the subordinate databases and consumers will remove those entries when they enters the refresh phase of the syncrepl protocol. The attached patch fixes this problem. Rein Tollevik Basefarm AS Index: OpenLDAP/servers/slapd/overlays/syncprov.c diff -u OpenLDAP/servers/slapd/overlays/syncprov.c:1.6 OpenLDAP/servers/slapd/overlays/syncprov.c:1.7 --- OpenLDAP/servers/slapd/overlays/syncprov.c:1.6 Tue Mar 18 17:22:41 2008 +++ OpenLDAP/servers/slapd/overlays/syncprov.c Tue Mar 18 18:02:32 2008 @@ -696,7 +696,11 @@ break; } - fop.o_bd->bd_info = on->on_info->oi_orig; + if ( on->on_next ) { + fop.o_bd->bd_info = (BackendInfo *) on->on_next; + } else { + fop.o_bd->bd_info = on->on_info->oi_orig; + } fop.o_bd->be_search( &fop, &frs ); fop.o_bd->bd_info = (BackendInfo *)on; @@ -1522,7 +1526,11 @@ fop.ors_filter = ⁡ cb.sc_response = playlog_cb; - fop.o_bd->bd_info = on->on_info->oi_orig; + if (on->on_next) { + fop.o_bd->bd_info = (BackendInfo *) on->on_next; + } else { + fop.o_bd->bd_info = on->on_info->oi_orig; + } for ( i=ndel; i<num; i++ ) { if ( uuids[i].bv_len == 0 ) continue;

1 0

(ITS#5433) syncprov in a glue'ed environment write contextCSN to random subordinate DB
by rein＠basefarm.no 18 Mar '08

18 Mar '08

Full_Name: Rein Tollevik Version: 2.4.8 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.215.2.34) syncprov_checkpoint() writes the contextCSN attribute to the suffix of the backend DB that is currently being written when it is triggered. When syncprov is stacked on top of a set of glue'ed databases this can be any of the subordinate backend DBs. The attached patch fixes this problem. Rein Tollevik Basefarm AS Index: OpenLDAP/servers/slapd/overlays/syncprov.c diff -u OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.11 OpenLDAP/servers/slapd/overlays/syncprov.c:1.5 --- OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.11 Thu Feb 21 14:55:36 2008 +++ OpenLDAP/servers/slapd/overlays/syncprov.c Fri Mar 14 16:23:48 2008 @@ -1301,6 +1301,7 @@ Operation opm; SlapReply rsm = { 0 }; slap_callback cb = {0}; + BackendInfo *bi = on->on_info->oi_origdb->bd_info; mod.sml_numvals = si->si_numcsns; mod.sml_values = si->si_ctxcsn; @@ -1316,8 +1317,9 @@ opm.o_callback = &cb; opm.orm_modlist = &mod; opm.orm_no_opattrs = 1; - opm.o_req_dn = op->o_bd->be_suffix[0]; - opm.o_req_ndn = op->o_bd->be_nsuffix[0]; + opm.o_bd = on->on_info->oi_origdb; + opm.o_req_dn = opm.o_bd->be_suffix[0]; + opm.o_req_ndn = opm.o_bd->be_nsuffix[0]; opm.o_bd->bd_info = on->on_info->oi_orig; opm.o_managedsait = SLAP_CONTROL_NONCRITICAL; opm.o_no_schema_check = 1; @@ -1326,6 +1328,7 @@ slap_mods_free( mod.sml_next, 1 ); } opm.orm_no_opattrs = 0; + opm.o_bd->bd_info = bi; } static void

1 0

(ITS#5432) syncrepl seg. faults if received a sync cookie with an empty csn= value
by rein＠basefarm.no 18 Mar '08

18 Mar '08

Full_Name: Rein Tollevik Version: 2.4.8 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.215.2.34) The attached patch fixes a seg. fault in compare_csns() in syncrepl.c if it receives a sync cookie with an empty "csn=" value. syncprov_playlog() in syncprov.c generates such invalid cookies when replaying a sessionlog where no entries has been deleted. The patch also fixes this bug. Rein Tollevik Basefarm AS Index: OpenLDAP/servers/slapd/syncrepl.c diff -u OpenLDAP/servers/slapd/syncrepl.c:1.6 OpenLDAP/servers/slapd/syncrepl.c:1.7 --- OpenLDAP/servers/slapd/syncrepl.c:1.6 Fri Mar 14 16:27:41 2008 +++ OpenLDAP/servers/slapd/syncrepl.c Tue Mar 18 17:15:30 2008 @@ -669,8 +669,8 @@ return -1; } - for (i=0; !BER_BVISNULL( &sc1->ctxcsn[i] ); i++) { - for (j=0; !BER_BVISNULL( &sc2->ctxcsn[j] ); j++) { + for (i=0; !BER_BVISEMPTY( &sc1->ctxcsn[i] ); i++) { + for (j=0; !BER_BVISEMPTY( &sc2->ctxcsn[j] ); j++) { if ( sc1->sids[i] != sc2->sids[j] ) continue; value_match( &match, slap_schema.si_ad_entryCSN, Index: OpenLDAP/servers/slapd/overlays/syncprov.c diff -u OpenLDAP/servers/slapd/overlays/syncprov.c:1.5 OpenLDAP/servers/slapd/overlays/syncprov.c:1.6 --- OpenLDAP/servers/slapd/overlays/syncprov.c:1.5 Fri Mar 14 16:23:48 2008 +++ OpenLDAP/servers/slapd/overlays/syncprov.c Tue Mar 18 17:22:41 2008 @@ -1413,8 +1413,7 @@ num * UUID_LEN, op->o_tmpmemctx ); uuids[0].bv_val = (char *)(uuids + num + 1); - delcsn[0].bv_len = 0; - delcsn[0].bv_val = cbuf; + BER_BVZERO(&delcsn[0]); BER_BVZERO(&delcsn[1]); /* Make a copy of the relevant UUIDs. Put the Deletes up front @@ -1453,6 +1452,7 @@ i++; AC_MEMCPY( cbuf, se->se_csn.bv_val, se->se_csn.bv_len ); delcsn[0].bv_len = se->se_csn.bv_len; + delcsn[0].bv_val = cbuf; delcsn[0].bv_val[delcsn[0].bv_len] = '\0'; } else { nmods++;

1 0

(ITS#5431) syncrepl on a subordinate DB writes contextCSN to suffix of parent DB
by rein＠basefarm.no 18 Mar '08

18 Mar '08

Full_Name: Rein Tollevik Version: 2.4.8 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.215.2.34) syncrepl_updateCookie() writes the contextCSN to the suffix of si->si_wbe (assigned to op->o_bd). In a subordinate database this is the parent DB, it should be written to the suffix of si->si_be instead as the attached patch fixes. I first considered writing it directly to si->si_be rather than through si->si_wbe, but I'm not familiar enough with the syncrepl/syncprov code to tell whether that would be correct or not. Rein Tollevik Basefarm AS Index: OpenLDAP/servers/slapd/syncrepl.c diff -u OpenLDAP/servers/slapd/syncrepl.c:1.5 OpenLDAP/servers/slapd/syncrepl.c:1.6 --- OpenLDAP/servers/slapd/syncrepl.c:1.5 Mon Mar 3 14:04:54 2008 +++ OpenLDAP/servers/slapd/syncrepl.c Fri Mar 14 16:27:41 2008 @@ -2683,8 +2683,8 @@ cb.sc_private = si; op->o_callback = &cb; - op->o_req_dn = op->o_bd->be_suffix[0]; - op->o_req_ndn = op->o_bd->be_nsuffix[0]; + op->o_req_dn = si->si_be->be_suffix[0]; + op->o_req_ndn = si->si_be->be_nsuffix[0]; /* update contextCSN */ op->o_msgid = SLAP_SYNC_UPDATE_MSGID;

1 0

(ITS#5430) Segfault in slapd 2.4.8 - syncrepl and glue
by duncan.gibb＠siriusit.co.uk 18 Mar '08

18 Mar '08

Full_Name: Duncan Gibb Version: 2.4.8 OS: Linux (Debian Etch and RHEL 4, x86 and x86_64) URL: Submission from: (NULL) (217.207.197.142) (Previously sent by email to openldap-devel, but lost or moderated out) In the course of debugging a fairly complex OpenLDAP deployment, we've found a reproducible segfault in 2.4.8. Below is a simplified testcase. Server1 is master for the main database and syncrepl consumer for a subordinate (starting at ou=dept2,... in our example). It's syncrepl provider for both parts of the tree. Server2 is master for the subordinate database, and consumer for the main database. Server3 is 100% consumer, taking both parts of the database from Server1 (in the real environment there is no routing between Server2 and Server3). Starting with empty databases, we populate Server1 with "main.ldif", and Server2 with "dept2.ldif". Then start 1 and 2 (only). With servers 1 and 2 running, we have full replication in both directions. When we start Server3 with an empty database, it replicates the whole tree from Server1. However: - subsequent changes in the main database (on Server1) replicate only to Server2 and not to Server3 - the next change in the subordinate database (on Server2) replicates to 1 and 3, but segfaults Server1 thus: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x41001950 (LWP 5512)] 0x000000000045c95e in test_filter (op=0x41000710, e=0xa29c08, f=0x0) at filterentry.c:69 69 if ( f->f_choice & SLAPD_FILTER_UNDEFINED ) {(gdb) bt #0 0x000000000045c95e in test_filter (op=0x41000710, e=0xa29c08, f=0x0) at filterentry.c:69 #1 0x00002b9fcd9dddf2 in syncprov_matchops (op=0x41000710, opc=0xdb4c40, saveit=1) at syncprov.c:1212 #2 0x00002b9fcd9dfd4c in syncprov_op_mod (op=0x41000710, rs=0x41000290) at syncprov.c:1807 #3 0x00000000004b5dce in overlay_op_walk (op=0x41000710, rs=0x41000290, which=op_modify, oi=0x7f1ab0, on=0x7f1f40) at backover.c:643 #4 0x00000000004b6060 in over_op_func (op=0x41000710, rs=0x41000290, which=op_modify) at backover.c:705 #5 0x00000000004b613e in over_op_modify (op=0x41000710, rs=0x41000290) at backover.c:739 #6 0x00000000004abfac in syncrepl_updateCookie (si=0x7f1020, op=0x41000710, pdn=0x7f01c0, syncCookie=0x41000500) at syncrepl.c:2693 #7 0x00000000004a5987 in do_syncrep2 (op=0x41000710, si=0x7f1020) at syncrepl.c:848 #8 0x00000000004a6e66 in do_syncrepl (ctx=0x41000e00, arg=0x7f0c20) at syncrepl.c:1226 #9 0x00000000004359fd in connection_read_thread (ctx=0x41000e00, argv=0x10) at connection.c:1213 #10 0x00002b9fc9f34ae5 in ldap_int_thread_pool_wrapper (xpool=0x7ab720) at tpool.c:625 #11 0x00002b9fca8f03f7 in start_thread () from /lib/libpthread.so.0 #12 0x00002b9fcba3997d in clone () from /lib/libc.so.6 #13 0x0000000000000000 in ?? () (gdb) We've reproduced this on RHEL4/i386 both under Xen and under QEMU, and also on Debian Etch/amd64 using Xen virtuals and using three slapds listening on different ports on the same machine. Below are config files for the last of these, which should be the simplest to rig up (127.0.N.1 represents ServerN). Ideas and comments welcome. Cheers Duncan -8<-- slapd.conf.127.0.1.1 -8<---8<---8<---8<---8<---8<---8<-- # slapd.conf for 127.0.1.1 include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema loglevel any sizelimit unlimited timelimit unlimited pidfile /home/ldaptest/rel/var/run/slapd_127.0.1.1.pid argsfile /home/ldaptest/rel/var/run/slapd_127.0.1.1.args modulepath /home/ldaptest/rel/libexec/openldap moduleload back_bdb moduleload syncprov.la database bdb suffix "ou=dept2,dc=ldaplab,dc=siriusit,dc=co,dc=uk" rootdn "cn=admin,dc=ldaplab,dc=siriusit,dc=co,dc=uk" overlay syncprov subordinate directory /home/ldaptest/rel/var/openldap-data/127.0.1.1/dept2 index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index entryCSN eq,pres syncrepl rid=103 provider=ldap://127.0.2.1:38902 type=refreshAndPersist retry="10 +" searchbase="ou=dept2,dc=ldaplab,dc=siriusit,dc=co,dc=uk" bindmethod="simple" binddn="cn=admin,dc=ldaplab,dc=siriusit,dc=co,dc=uk" credentials="secret" updateref ldap://127.0.2.1:38902 database bdb suffix "dc=ldaplab,dc=siriusit,dc=co,dc=uk" rootdn "cn=admin,dc=ldaplab,dc=siriusit,dc=co,dc=uk" overlay glue overlay syncprov directory /home/ldaptest/rel/var/openldap-data/127.0.1.1/main index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index entryCSN eq,pres -8<-- slapd.conf.127.0.2.1 -8<---8<---8<---8<---8<---8<---8<-- # slapd.conf for 127.0.2.1 include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema loglevel any sizelimit unlimited timelimit unlimited pidfile /home/ldaptest/rel/var/run/slapd_127.0.2.1.pid argsfile /home/ldaptest/rel/var/run/slapd_127.0.2.1.args modulepath /home/ldaptest/rel/libexec/openldap moduleload back_bdb moduleload syncprov.la database bdb suffix "ou=dept2,dc=ldaplab,dc=siriusit,dc=co,dc=uk" rootdn "cn=admin,dc=ldaplab,dc=siriusit,dc=co,dc=uk" overlay syncprov subordinate directory /home/ldaptest/rel/var/openldap-data/127.0.2.1/dept2 index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index entryCSN eq,pres database bdb suffix "dc=ldaplab,dc=siriusit,dc=co,dc=uk" rootdn "cn=admin,dc=ldaplab,dc=siriusit,dc=co,dc=uk" overlay glue overlay syncprov directory /home/ldaptest/rel/var/openldap-data/127.0.2.1/main index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index entryCSN eq,pres syncrepl rid=100 provider=ldap://127.0.1.1:38901 type=refreshAndPersist retry="10 +" searchbase="dc=ldaplab,dc=siriusit,dc=co,dc=uk" bindmethod="simple" binddn="cn=admin,dc=ldaplab,dc=siriusit,dc=co,dc=uk" credentials="secret" updateref ldap://127.0.1.1:38901 -8<-- slapd.conf.127.0.3.1 -8<---8<---8<---8<---8<---8<---8<-- # slapd.conf for 127.0.3.1 include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema loglevel any sizelimit unlimited timelimit unlimited pidfile /home/ldaptest/rel/var/run/slapd_127.0.3.1.pid argsfile /home/ldaptest/rel/var/run/slapd_127.0.3.1.args modulepath /home/ldaptest/rel/libexec/openldap moduleload back_bdb moduleload syncprov.la database bdb suffix "ou=dept2,dc=ldaplab,dc=siriusit,dc=co,dc=uk" rootdn "cn=admin,dc=ldaplab,dc=siriusit,dc=co,dc=uk" subordinate directory /home/ldaptest/rel/var/openldap-data/127.0.3.1/dept2 index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index entryCSN eq,pres syncrepl rid=104 provider=ldap://127.0.1.1:38901 type=refreshAndPersist retry="10 +" searchbase="ou=dept2,dc=ldaplab,dc=siriusit,dc=co,dc=uk" bindmethod="simple" binddn="cn=admin,dc=ldaplab,dc=siriusit,dc=co,dc=uk" credentials="secret" updateref ldap://127.0.2.1:38902 database bdb suffix "dc=ldaplab,dc=siriusit,dc=co,dc=uk" rootdn "cn=admin,dc=ldaplab,dc=siriusit,dc=co,dc=uk" overlay glue directory /home/ldaptest/rel/var/openldap-data/127.0.3.1/main index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index entryCSN eq,pres syncrepl rid=105 provider=ldap://127.0.1.1:38901 type=refreshAndPersist retry="10 +" searchbase="dc=ldaplab,dc=siriusit,dc=co,dc=uk" bindmethod="simple" binddn="cn=admin,dc=ldaplab,dc=siriusit,dc=co,dc=uk" credentials="secret" updateref ldap://127.0.1.1:38901 -8<-- main.ldif -8<---8<---8<---8<---8<---8<---8<-- # LDIF for main tree dn: dc=ldaplab,dc=siriusit,dc=co,dc=uk dc: ldaplab o: ldaplab objectClass: dcObject objectClass: organization dn: cn=admin,dc=ldaplab,dc=siriusit,dc=co,dc=uk cn: admin objectClass: organizationalRole objectClass: simpleSecurityObject userPassword: {SSHA}HEadVOU0EenIL0NX1bMblWYLAHrVW8Jy dn: ou=dept1,dc=ldaplab,dc=siriusit,dc=co,dc=uk ou: dept1 objectClass: organizationalUnit dn: cn=person11,ou=dept1,dc=ldaplab,dc=siriusit,dc=co,dc=uk sn: person11 cn: person11 objectClass: person dn: cn=person12,ou=dept1,dc=ldaplab,dc=siriusit,dc=co,dc=uk sn: person12 cn: person12 objectClass: person -8<-- dept2.ldif -8<---8<---8<---8<---8<---8<---8<-- # LDIF for "dept2" delegated subordinate tree dn: ou=dept2,dc=ldaplab,dc=siriusit,dc=co,dc=uk ou: dept2 objectClass: organizationalUnit dn: cn=person21,ou=dept2,dc=ldaplab,dc=siriusit,dc=co,dc=uk sn: person21 cn: person21 objectClass: person dn: cn=person22,ou=dept2,dc=ldaplab,dc=siriusit,dc=co,dc=uk sn: person22 cn: person22 objectClass: person

1 0

(ITS#5429) component Matching
by ron＠zytrax.com 17 Mar '08

17 Mar '08

Full_Name: Ron Aitchison Version: 2.4.8 OS: FreeBSD (5.4/6.2) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.148.181.131) Component matching (RFC 3687) is defined to be released with 2.4.8. However it is conditionally compiled from the variable LDAP_COMP_MATCH which is only set (in servers/slapd/slap.h) if LDAP_DEVEL is set. LDAP_DEVEL is not set by default in a normal build. The net result is that component matching is not included in an OpenLDAP build.

1 0

Re: (ITS#5419) test048 fails...
by hyc＠symas.com 17 Mar '08

17 Mar '08

luca(a)OpenLDAP.org wrote: > h.b.furuseth(a)usit.uio.no wrote: >> hyc(a)symas.com writes: >> >>> op->o_bd is essentially supposed to be a constant once it is set on an >>> operation. Operations within a backend are generally not allowed to >>> access other backends so it should not be overriding the backend that >>> was given to it. >>> >> "grep -n -e '.->o_bd *=[^=]' *.c */*.c" finds 10 from 'orig'something. >> Some of the other 202 matches also restore an old o_bd. >> > Seems fixed. can we close it? Yes, fine, as long as no one is seeing any unexpected side-effects from the fixes. -- -- 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

← Newer
1
...
5
6
7
8
9
10
11
...
17
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 March 2008