openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#5163) slapd segfaults when running as proxy-caching server
by toby＠inf.ed.ac.uk 02 Oct '07

02 Oct '07

Hi there, Firstly, thanks for the really quick reply. > I think this issue has been already fixed, incidentally, in HEAD/re24, but > went unnoticed in re23. You should replace the call to ch_malloc() that's > around line 1140 in servers/slapd/overlays/pcache.c with a call to > ch_calloc(); something like > > *new_attrs = (AttributeName*)ch_calloc( count + 1, > sizeof(AttributeName)); Yep, it's there - line 1138. I'll patch this and report back. > (sorry, I can't access the network right now but by webmail). In > fact, right now, the array of AttributeName "new_attrs" is accessed > by an_find() while not yet NULL terminated. Please check and report > (to create the problem, you need to use filters that contain the > attributes that will be cached). I would have expected the problem to show up more frequently, if I just need to use a filter that will result in attributes being cached. Cheers Toby

1 0

(ITS#5164) slapi plugins prevent slapd starting.
by m.d.t.evans＠qmul.ac.uk 02 Oct '07

02 Oct '07

Full_Name: Martin Evans Version: 2.4.5beta OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (138.37.8.140) This is mentioned in #4611 but marked as fixed there. If you compile and load in the plugin from 4611 slapd does not start and you get the following errors from -d-1: ... 2.5.13.0 (objectIdentifierMatch): matchingRuleUse: ( 2.5.13.0 NAME 'objectIdentifierMatch' APPLIES ( supportedControl $ supportedExtension $ supportedFeatures $ supportedApplicationContext ) ) slapd startup: initiated. backend_startup: bi_db_open(frontend) failed! (1) slapd shutdown: initiated ====> bdb_cache_release_all backend_startup: bi_db_close(frontend) failed! (1) slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy. This is the plugin from 4611: #include "slapi-plugin.h" #include <stdio.h> int auth(Slapi_PBlock *pb) { slapi_send_ldap_result( pb, 0, NULL, NULL, 0, NULL ); return (0); } int auth_plugin_init(Slapi_PBlock *pb) { if (slapi_pblock_set( pb, SLAPI_PLUGIN_PRE_BIND_FN, (void*) auth) != 0) { slapi_log_error(SLAPI_LOG_PLUGIN, "auth", "Error registering function.\n" ); return (-1); } slapi_log_error( SLAPI_LOG_PLUGIN, "auth_plugin_init", "Plug-ins successfully registered.\n" ); return (0); }

1 0

Re: (ITS#5163) slapd segfaults when running as proxy-caching server
by ando＠sys-net.it 02 Oct '07

02 Oct '07

> While running slapd as a proxy-caching server, it sometimes falls over > with a > signal 11 segfault. I haven't been able to reproduce this and it can > occur when > the system is quiet and nothing much running.... I think this issue has been already fixed, incidentally, in HEAD/re24, but went unnoticed in re23. You should replace the call to ch_malloc() that's around line 1140 in servers/slapd/overlays/pcache.c with a call to ch_calloc(); something like *new_attrs = (AttributeName*)ch_calloc( count + 1, sizeof(AttributeName)); (sorry, I can't access the network right now but by webmail). In fact, right now, the array of AttributeName "new_attrs" is accessed by an_find() while not yet NULL terminated. Please check and report (to create the problem, you need to use filters that contain the attributes that will be cached). 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

(ITS#5163) slapd segfaults when running as proxy-caching server
by toby＠inf.ed.ac.uk 02 Oct '07

02 Oct '07

Full_Name: Toby Blake Version: 2.3.38 OS: Fedora Core 5/6 URL: Submission from: (NULL) (129.215.218.33) While running slapd as a proxy-caching server, it sometimes falls over with a signal 11 segfault. I haven't been able to reproduce this and it can occur when the system is quiet and nothing much running.... Core was generated by `/usr/sbin/slapd -h ldap:///'. Program terminated with signal 11, Segmentation fault. #0 0x008314f3 in strcasecmp () from /lib/libc.so.6 Here's the db portion of slapd.conf: database ldap suffix dc=inf,dc=ed,dc=ac,dc=uk rootdn uid=ldaprep/clive.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth uri "ldap://testdir.inf.ed.ac.uk/" idassert-bind mode=none bindmethod=sasl saslmech=GSSAPI idassert-authzFrom "dn:*" overlay pcache proxycache bdb 5000 2 500 300 proxycachequeries 10000 proxyattrset 0 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass afsHomeDirectory primaryRoles secondary Roles proxyattrset 1 cn userPassword memberUid uniqueMember gidNumber nisNe tgroupTriple memberNisNetgroup objectClass proxytemplate (uid=) 0 1800 1800 proxytemplate (&(objectClass=)(uid=)) 0 1800 1800 proxytemplate (&(objectClass=)(cn=)) 1 1800 1800 proxytemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) 0 1800 1800 proxytemplate (&(objectClass=)(uniqueMember=)) 0 1800 1800 proxytemplate (&(objectClass=)(memberUid=)) 0 1800 1800 proxytemplate (&(objectClass=)(uidNumber=)) 0 1800 1800 proxytemplate (&(objectClass=)(gidNumber=)) 1 1800 1800 directory /var/openldap-data dbconfig set_cachesize 0 16777216 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 include /etc/openldap/slapd.conf.indices And, here's the full backtrace from gdb... #0 0x008314f3 in strcasecmp () from /lib/libc.so.6 No symbol table info available. #1 0x0809c83d in an_find (a=0xb0c412d0, s=0xad1f8994) at ad.c:842 No locals. #2 0x08117321 in pcache_op_search (op=0xb0c271b8, rs=0xad6f91c4) at pcache.c:1150 cb = <value optimized out> on = (slap_overinst *) 0x8a4f9d0 cm = (cache_manager *) 0x8a4fac0 qm = (query_manager *) 0x8a6aed8 i = <value optimized out> filter_attrs = (AttributeName *) 0xad1f896c query = {filter = 0xb0c3d178, attrs = 0xb0c411b8, save_attrs = 0xad1f88cc, base = {bv_len = 24, bv_val = 0xad1f81e4 "dc=inf,dc=ed,dc=ac,dc=uk"}, scope = 2} attr_set = 0 template_id = 3 answerable = <value optimized out> cacheable = 1 fattr_cnt = 3 fattr_got_oc = 1 tempstr = {bv_len = 47, bv_val = 0xad1f88fc "(&(objectClass=)(|(memberUid=)(uniqueMember=)))"} #3 0x080bb404 in overlay_op_walk (op=0xb0c271b8, rs=0xad6f91c4, which=op_search, oi=0x8a4f8e0, on=0x8a4f9d0) at backover.c:639 rc = -1329434184 #4 0x080bb89d in over_op_func (op=0xb0c271b8, rs=0xad6f91c4, which=op_search) at backover.c:701 oi = (slap_overinfo *) 0x8a4f8e0 on = (slap_overinst *) 0x8a4f9d0 be = (BackendDB *) 0x8a4f4c8 db = {bd_info = 0x8a4f9d0, be_ctrls = "\000", '\001' <repeats 14 times>, '\0' <repeats 17 times>, "\001", be_flags = 257, be_restrictops = 0, be_requires = 0, be_ssf_set = { sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x8a6af10, be_nsuffix = 0x8a6ade0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 64, bv_val = 0x8a4f838 "uid=ldaprep/clive.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth"}, be_rootndn = {bv_len = 64, bv_val = 0x8a4f898 "uid=ldaprep/clive.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 24576, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x8a6a6c0, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8aa4820, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x8a4f598, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x81cd360, be_private = 0x8a4f5d0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x0, sc_response = 0x80bb180 <over_back_response>, sc_cleanup = 0, sc_private = 0x8a4f8e0} rc = 0 __PRETTY_FUNCTION__ = "over_op_func" #5 0x0806316f in fe_op_search (op=0xb0c271b8, rs=0xad6f91c4) at search.c:355 entry = (Entry *) 0xad6f8118 bd = (BackendDB *) 0x81d1240 #6 0x08063b21 in do_search (op=0xb0c271b8, rs=0xad6f91c4) at search.c:217 base = {bv_len = 24, bv_val = 0xb0c40440 "dc=inf,dc=ed,dc=ac,dc=uk"} siz = 1 i = 1 #7 0x080611f9 in connection_operation (ctx=0xad6f9238, arg_v=0xb0c271b8) at connection.c:1133 curelm = <value optimized out> rc = <value optimized out> rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = (Connection *) 0xb6885288 memctx = (void *) 0x8b0c630 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #8 0x08131fd3 in ldap_int_thread_pool_wrapper (xpool=0x8a324f8) at tpool.c:478 ctx = (ldap_int_thread_ctx_t *) 0xb0c16600 ltc_key = {{ltk_key = 0x80ac320, ltk_data = 0x8b0c630, ltk_free = 0x80ac210 <slap_sl_mem_destroy>}, {ltk_key = 0x8aa5430, ltk_data = 0x9b, ltk_free = 0x80e9550 <bdb_locker_id_free>}, { ltk_key = 0x80c9170, ltk_data = 0xac9f7008, ltk_free = 0x80c9230 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 29 times>} tid = 2909772688 i = 583 hash = <value optimized out> #9 0x0093945b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #10 0x0089123e in clone () from /lib/libc.so.6 No symbol table info available. (gdb) Please let me know if any more deugging information would be useful. Cheers Toby Blake University of Edinburgh

1 0

(ITS#5162) Bus Error - core dumped
by piotr.tarnowski＠us.edu.pl 02 Oct '07

02 Oct '07

Full_Name: Piotr Tarnowski (DrFugazi) Version: 2.3.38 OS: Solaris 10 U4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (155.158.96.61) Hello, I compiled the newest version of OpenLDAP (2.3.38) on Solaris 10 U4 (8/07) system. I tried many times with many compilation options, but I still have an error with 'gmake test': >>>>> Starting test001-slapadd ... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve all the entries... Waiting 5 seconds for slapd to start... 4378 Bus Error - core dumped Waiting 5 seconds for slapd to start... ------------ In tests/testrun/slapd.1.log I found: daemon: select: listen=8 active_threads=0 tvp=NULL daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read activity on 12 connection_get(12) connection_get(12): got connid=0 connection_read(12): checking for input on id=0 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 60 07 02 0....`.. ldap_read: want=6, got=6 0000: 01 03 04 00 80 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x001cbef0 ptr=0x001cbef0 end=0x001cbefc len=12 0000: 02 01 01 60 07 02 01 03 04 00 80 00 ...`........ ber_get_next ldap_read: want=8 error=Resource temporarily unavailable daemon: select: listen=8 active_threads=0 tvp=NULL do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=0x001cbef0 ptr=0x001cbef3 end=0x001cbefc len=9 0000: 60 07 02 01 03 04 00 80 00 `........ ber_scanf fmt (m}) ber: ber_dump: buf=0x001cbef0 ptr=0x001cbefa end=0x001cbefc len=2 0000: 00 00 .. >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 conn=0 op=0 BIND dn="" method=128 send_ldap_result: conn=0 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 ber_flush: 14 bytes to sd 12 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ conn=0 op=0 RESULT tag=97 err=0 text= do_bind: v3 anonymous bind daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read activity on 12 connection_get(12) connection_get(12): got connid=0 connection_read(12): checking for input on id=0 ber_get_next ldap_read: want=8, got=8 0000: 30 36 02 01 02 63 31 04 06...c1. ldap_read: want=48, got=48 0000: 11 64 63 3d 65 78 61 6d 70 6c 65 2c 64 63 3d 63 .dc=example,dc=c 0010: 6f 6d 0a 01 02 0a 01 00 02 01 00 02 01 00 01 01 om.............. 0020: 00 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 30 00 ...objectclass0. ber_get_next: tag 0x30 len 54 contents: ber_dump: buf=0x001acdd8 ptr=0x001acdd8 end=0x001ace0e len=54 0000: 02 01 02 63 31 04 11 64 63 3d 65 78 61 6d 70 6c ...c1..dc=exampl 0010: 65 2c 64 63 3d 63 6f 6d 0a 01 02 0a 01 00 02 01 e,dc=com........ 0020: 00 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 63 .........objectc 0030: 6c 61 73 73 30 00 lass0. ber_get_next do_search ldap_read: want=8 error=Resource temporarily unavailable ber_scanf fmt ({miiiib) ber: ber_dump: buf=0x001acdd8 ptr=0x001acddb end=0x001ace0e len=51 0000: 63 31 04 11 64 63 3d 65 78 61 6d 70 6c 65 2c 64 c1..dc=example,d 0010: 63 3d 63 6f 6d 0a 01 02 0a 01 00 02 01 00 02 01 c=com........... 0020: 00 01 01 00 87 0b 6f 62 6a 65 63 74 63 6c 61 73 ......objectclas 0030: 73 30 00 s0. daemon: select: listen=8 active_threads=0 tvp=NULL >>> dnPrettyNormal: <dc=example,dc=com> => ldap_bv2dn(dc=example,dc=com,0) <= ldap_bv2dn(dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=example,dc=com)=0 <<< dnPrettyNormal: <dc=example,dc=com>, <dc=example,dc=com> SRCH "dc=example,dc=com" 2 0 0 0 0 begin get_filter PRESENT ber_scanf fmt (m) ber: ber_dump: buf=0x001acdd8 ptr=0x001acdff end=0x001ace0e len=15 0000: 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 30 00 ..objectclass0. end get_filter 0 filter: (objectClass=*) ber_scanf fmt ({M}}) ber: ber_dump: buf=0x001acdd8 ptr=0x001ace0c end=0x001ace0e len=2 ----------- Output from truss: (...) 26487/3: write(2, " b d b _ d n 2 e n t r y".., 34) = 34 26487/3: write(2, " = > b d b _ d n 2 i d".., 34) = 34 26487/3: write(2, " < = b d b _ d n 2 i d".., 32) = 32 26487/3: Incurred fault #5, FLTACCESS %pc = 0x7E72B4D0 26487/3: siginfo: SIGBUS BUS_ADRALN addr=0x00000032 26487/3: Received signal #10, SIGBUS [default] 26487/3: siginfo: SIGBUS BUS_ADRALN addr=0x00000032 26392: waitid(P_PID, 26517, 0xFFBFF5C0, WEXITED|WTRAPPED|WNOWAIT) (sleeping...) (...) ------------- Is this a software error, or compiler/system issue ? I use Sun Studio 12 on sparc. Machine hardware: sun4u OS version: 5.10 Processor type: sparc Hardware: SUNW,Sun-Fire-V890 The following components are installed on your system: Sun Studio 12 Sun Studio 12 C Compiler Sun Studio 12 C++ Compiler Sun Studio 12 Tools.h++ 7.1 Sun Studio 12 C++ Standard 64-bit Class Library Sun Studio 12 Garbage Collector Sun Studio 12 Fortran 95 Sun Studio 12 Debugging Tools (including dbx) Sun Studio 12 IDE Sun Studio 12 Debugger GUI Sun Studio 12 Performance Analyzer (including collect, ...) Sun Studio 12 X-Designer Sun Studio 12 VIM editor Sun Studio 12 XEmacs editor Sun Studio 12 Performance Library Sun Studio 12 LockLint Sun Studio 12 Building Software (including dmake) Sun Studio 12 Documentation Set Sun Studio 12 /usr symbolic links and GNOME menu item version of "/opt/SUNWspro/bin/../prod/bin/../../bin/cc": Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/CC": Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/f90": Sun Fortran 95 8.3 SunOS_sparc Patch 127000-01 2007/07/18 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dbx": Sun Dbx Debugger 7.6 SunOS_sparc Patch 124872-02 2007/08/16 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/analyzer": Sun Analyzer 7.6 SunOS_sparc Patch 126995-01 2007/07/17 version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dmake": Sun Distributed Make 7.8 SunOS_sparc Patch 126503-01 2007/07/19 Regards -- Piotr (DrFugazi) Tarnowski

1 0

Re: (ITS#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 01 Oct '07

01 Oct '07

--On Tuesday, October 02, 2007 2:35 AM +0000 hyc(a)symas.com wrote: > quanah(a)zimbra.com wrote: >> --On October 1, 2007 11:22:11 PM +0000 quanah(a)zimbra.com wrote: >> >>> The following files will be uploaded to the ftp site, where # will be >>> the assigned ITS number. >> >> URL's specifically are: >> >> <ftp://ftp.openldap.org/incoming/5161-pstak.out.2007-10-01> >> <ftp://ftp.openldap.org/incoming/5161-dbstat.delta.out.2007-10-01> >> <ftp://ftp.openldap.org/incoming/5161-db_stat.out.2007-10-01> > > The pstack output is a bit odd, is this a regular debug build? With frame > pointers, etc? Can you get a stack trace in gdb? It is a regular build, and they killed and restarted it before getting any gdb information. We've asked them to please get the gdb information in the future. Since it has happened twice now for thi particular group in about a month, I'm hopeful it'll happen again before too long. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5161) delta-syncrepl mutex lockup
by hyc＠symas.com 01 Oct '07

01 Oct '07

quanah(a)zimbra.com wrote: > --On October 1, 2007 11:22:11 PM +0000 quanah(a)zimbra.com wrote: > >> The following files will be uploaded to the ftp site, where # will be the >> assigned ITS number. > > URL's specifically are: > > <ftp://ftp.openldap.org/incoming/5161-pstak.out.2007-10-01> > <ftp://ftp.openldap.org/incoming/5161-dbstat.delta.out.2007-10-01> > <ftp://ftp.openldap.org/incoming/5161-db_stat.out.2007-10-01> The pstack output is a bit odd, is this a regular debug build? With frame pointers, etc? Can you get a stack trace in gdb? -- -- 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

Re: (ITS#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 01 Oct '07

01 Oct '07

--On October 1, 2007 11:22:11 PM +0000 quanah(a)zimbra.com wrote: > The following files will be uploaded to the ftp site, where # will be the > assigned ITS number. URL's specifically are: <ftp://ftp.openldap.org/incoming/5161-pstak.out.2007-10-01> <ftp://ftp.openldap.org/incoming/5161-dbstat.delta.out.2007-10-01> <ftp://ftp.openldap.org/incoming/5161-db_stat.out.2007-10-01> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 01 Oct '07

01 Oct '07

Full_Name: Quanah Gibson-Mount Version: 2.3.37 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.104.138.6) Several customers have found delta-syncrepl will lock up after a time. Today it occurred again, and this time some logging data was able to be gathered. The last operation logged was a MOD op. This matches past lockups, which were also either MOD or ADD operations. The following files will be uploaded to the ftp site, where # will be the assigned ITS number. #-dbstat.delta.out.2007-10-01 which is the db_stat information for the accesslog DB #-db_stat.out.2007-10-01 which is the db_stat information for the main DB #-pstak.out.2007-10-01 which is the pstack information for the slapd process Unfortunately no GDB info was retrieved this time, and reportedly gcore hung. The most interesting part is I see no WRITE locks held in either DB, and all the client threads are hung in a mutex.

1 0

Re: (ITS#5160) syncrepl of glued and syncrepl'd databases causes unwanted deletes on the end consumer
by hyc＠symas.com 01 Oct '07

01 Oct '07

jclarke(a)linagora.com wrote: > I have tested this on both 2.3.38 and HEAD (same version on all 3 servers), and > behaviour is quite different, though the end result is the same. Due to multiple limitations, this is not expected to work in 2.3 at all. > On HEAD, things are quite different: > request done: ld 0x82c2228 msgid 2 > do_syncrep2: rid=7 LDAP_RES_SEARCH_RESULT > nonpresent_callback: rid=7 got UUID b5797e8c-0486-102c-83e0-79137da6179f, dn > dc=ossa,dc=linagora,dc=org > nonpresent_callback: rid=7 got UUID b5a2f834-0486-102c-83e1-79137da6179f, dn > uid=root,dc=ossa,dc=linagora,dc=org > nonpresent_callback: rid=7 got UUID b5a31526-0486-102c-83e2-79137da6179f, dn > uid=replicator,dc=ossa,dc=linagora,dc=org > adresse de be_modify : 80c8840 > null_callback : error code 0x32 > syncrepl_updateCookie: rid=7 be_modify failed (50) This is Insufficient Access. You have not configured the glue databases with identical rootDN's, which is clearly documented as a requirement for glued databases. -- -- 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

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