openldap-bugs March 2012

openldap-bugs@openldap.org

28 participants
78 discussions

Re: (ITS#7211) mdb inconsistency without LAZY_LOCKS
by h.b.furuseth＠usit.uio.no 19 Mar '12

19 Mar '12

I wrote: > I'm sleeping for write transactions only since that's when the > inconsistent copy is written back to disk. Please ignore that, that was another too-paranoid patch -- Hallvard

1 0

(ITS#7211) mdb inconsistency without LAZY_LOCKS
by h.b.furuseth＠usit.uio.no 19 Mar '12

19 Mar '12

Full_Name: Hallvard B Furuseth Version: master, af3a23a1ec93220be392a8ea6372475b7357c171 OS: Linux x86_64 URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard A write transaction can overwrite env->me_metas[]->mm_dbs, me_numdbs and me_dbxs while another txn is copying them in mdb_txn_renew0(), resulting in an inconsistent copy. '#define LAZY_LOCKS 0' fixes it. Without it, test054 dumps core with this patch: diff --git a/libraries/libmdb/mdb.c b/libraries/libmdb/mdb.c index b714119..5e22827 100644 --- a/libraries/libmdb/mdb.c +++ b/libraries/libmdb/mdb.c @@ -1519,2 +1519,4 @@ mdb_txn_renew0(MDB_txn *txn) memcpy(txn->mt_dbs, env->me_metas[txn->mt_toggle]->mm_dbs, 2 * sizeof(MDB_db)); + if ((rand() & 1)) usleep(100000); + assert(!memcmp(txn->mt_dbs, env->me_metas[txn->mt_toggle]->mm_dbs, 2 * sizeof(MDB_db))); if (txn->mt_numdbs > 2) I'm sleeping for write transactions only since that's when the inconsistent copy is written back to disk.

1 0

(ITS#7210) back-mdb endless database growth
by quanah＠OpenLDAP.org 19 Mar '12

19 Mar '12

Full_Name: Quanah Gibson-Mount Version: 2.4.30 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) If you create a script to add & delete the same 50,000 users, and then re-run that script multiple times, the MDB database on disk continues to grow, despite the fact that we are only adding and deleting the same data repeatedly. There should be zero growth to the database. Instead, the data.mdb file went from 108MB in size to over 1.2GB after 5-6 runs. Time to add/delete all the users went from 3 minutes 32 seconds on the first run to over 90 minutes on the final run (5th or 6th, I lost count).

1 0

Re: (ITS#5915) Some man pages still only talk about slapd.conf
by ghenry＠suretecsystems.com 19 Mar '12

19 Mar '12

It is on the list for updating and a migration section. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html On 19 Mar 2012, at 14:51, Bruno Schrade <bs(a)schwarzwald-software.de> wrote: > Sehr geehrter Herr Henry, > > i just moved an OpenLDAP-Server from Debian-5 to Debian-6. Expecting it would simply run using the same configuration file i just copied slapd.conf. This resulted in error messages along the line "missing credentials". So i looked up the QuickStartGuide and continued debugging the authorization process - finally found the reason and cure by reading /etc/init.d/slapd. > > I would like to suggest two changes: > > 1 May i suggest a quick fix: add something like "don't read this" > to the top of the QuickStartGuide. > 2 If possible change your mind on dropping slapd.conf-Support. > - Dropping it will break existing configurations. > - People are quite accustomed to /etc/.../.. .conf-files > > I would like to add that i really appreciate the work you are doing. > > Mit freundlichen Grüssen > > Schwarzwald Software Engineering * Bruno Schrade > Theodor-Kreuz-Strasse 6 * D-79868 Feldberg * Tel. +49 (0)7655 618 > http://www.schwarzwald-software.de >

1 0

Re: (ITS#5915) Some man pages still only talk about slapd.conf
by bs＠schwarzwald-software.de 19 Mar '12

19 Mar '12

Sehr geehrter Herr Henry, i just moved an OpenLDAP-Server from Debian-5 to Debian-6. Expecting it would simply run using the same configuration file i just copied slapd.conf. This resulted in error messages along the line "missing credentials". So i looked up the QuickStartGuide and continued debugging the authorization process - finally found the reason and cure by reading /etc/init.d/slapd. I would like to suggest two changes: 1 May i suggest a quick fix: add something like "don't read this" to the top of the QuickStartGuide. 2 If possible change your mind on dropping slapd.conf-Support. - Dropping it will break existing configurations. - People are quite accustomed to /etc/.../.. .conf-files I would like to add that i really appreciate the work you are doing. Mit freundlichen Grüssen Schwarzwald Software Engineering * Bruno Schrade Theodor-Kreuz-Strasse 6 * D-79868 Feldberg * Tel. +49 (0)7655 618 http://www.schwarzwald-software.de

1 0

Re: (ITS#7209) Changes to libraries/libmdb/mdb.c needed to build on FreeBSD
by h.b.furuseth＠usit.uio.no 16 Mar '12

16 Mar '12

Thanks for your report. We need to hear of OSes which do not provide O_DSYNC and fdatasync() and how to deal with them, so for now MDB demands them unless explicitly disabled. But the solution will not be a bunch of '#if <OS>'es. Maybe some POSIX feature test macros will be enough, or maybe we can use configure and wrap libmdb/mdb in back-mdb/mdb-wrap.c which makes use of the configure macros. On Wed, 14 Mar 2012 21:34:37 GMT, 4glitch(a)gmail.com wrote: > Why ANDROID and __APPLE__ special? I can't speak for Howard, but: Got there during development. MDB is still evolving. The solution will not be a bunch of '#ifdef <OS>'es. Maybe some POSIX feature test macros will be enough, or maybe we can use configure and wrap libmdb/mdb in back-mdb/mdb-wrap.c which makes use of the configure macros. -- Hallvard

1 0

Re: (ITS#7172) SEGFAULT in openldap-2.4.28 & 2.4.29
by david.coutadeur＠linagora.com 16 Mar '12

16 Mar '12

Hi, I finally had the opportunity to get a valgrind analysis of my problem. You can find it below. Thank you for any help. D. ==19496== 12 bytes in 1 blocks are definitely lost in loss record 16 of 52 ==19496== at 0x4005B83: malloc (vg_replace_malloc.c:195) ==19496== by 0x4056977: ber_memalloc_x (memory.c:228) ==19496== by 0x8095D39: ch_malloc (ch_malloc.c:54) ==19496== by 0x80E0297: do_syncrepl (syncrepl.c:706) ==19496== by 0x4016A23: ldap_int_thread_pool_wrapper (tpool.c:688) ==19496== by 0x821831: start_thread (in /lib/libpthread-2.5.so) ==19496== by 0x76146D: clone (in /lib/libc-2.5.so) ==19496== ==19496== 155 (32 direct, 123 indirect) bytes in 1 blocks are definitely lost in loss record 47 of 52 ==19496== at 0x4005B83: malloc (vg_replace_malloc.c:195) ==19496== by 0x4056977: ber_memalloc_x (memory.c:228) ==19496== by 0x4057054: ber_bvarray_dup_x (memory.c:756) ==19496== by 0x80E0212: do_syncrepl (syncrepl.c:699) ==19496== by 0x4016A23: ldap_int_thread_pool_wrapper (tpool.c:688) ==19496== by 0x821831: start_thread (in /lib/libpthread-2.5.so) ==19496== by 0x76146D: clone (in /lib/libc-2.5.so) ==19496== ==19496== 270 (228 direct, 42 indirect) bytes in 3 blocks are definitely lost in loss record 49 of 52 ==19496== at 0x4005B83: malloc (vg_replace_malloc.c:195) ==19496== by 0x4056977: ber_memalloc_x (memory.c:228) ==19496== by 0x8095D39: ch_malloc (ch_malloc.c:54) ==19496== by 0x8195E91: syncprov_op_search (syncprov.c:2473) ==19496== by 0x80E3333: overlay_op_walk (backover.c:661) ==19496== by 0x80E3A09: over_op_func (backover.c:723) ==19496== by 0x807BE85: fe_op_search (search.c:402) ==19496== by 0x807C772: do_search (search.c:247) ==19496== by 0x807988B: connection_operation (connection.c:1150) ==19496== by 0x807A0FC: connection_read_thread (connection.c:1286) ==19496== by 0x4016A23: ldap_int_thread_pool_wrapper (tpool.c:688) ==19496== by 0x821831: start_thread (in /lib/libpthread-2.5.so) Le 20/02/2012 10:32, David Coutadeur a écrit : > > Hi, > > Concerning the cpu : > model name : Intel(R) Xeon(R) CPU L5640 @ 2.27GHz > However, OpenLDAP is used in a virtual machine, with only one dedicated > core. This is 32 bits version of OpenLDAP, on a 32 bits OS. > Linux OS : > Red Hat Enterprise Linux Server release 5.7 (Tikanga) > kernel : > 2 2.6.18-274.3.1.el5 > > You can get the server configuration below. > > Concerning the client, you can find the source code here : > http://loadtesting.sourceforge.net/index.php?lang=en > > > > # > ---------------------------------------------------------------------------- > # Global section > # > ---------------------------------------------------------------------------- > > sizelimit 15000 > > allow bind_v2 > password-hash {SSHA} > threads 8 > loglevel 256 > > serverID 2 > > include /opt/openldap/etc/openldap/inc_shemas/slapd-schemas.conf > > pidfile /opt/openldap/var/run/slapd.pid > argsfile /opt/openldap/var/run/slapd.args > > # ACLs definition (cutted here) > > ####################################################################### > # SSL definitions > ####################################################################### > # Definition of cert files > # --------------------------------- > TLSCipherSuite HIGH:MEDIUM:+SSLv2 > > TLSCACertificateFile /usr/local/openldap/etc/certs/ca.cert > TLSCertificateFile /usr/local/openldap/etc/certs/ldap-master-2.cert > TLSCertificateKeyFile /usr/local/openldap/etc/certs/ldap-master-2.key > > TLSVerifyClient never > > > > ####################################################################### > # BDB database definitions > ####################################################################### > database monitor > > ####################################################################### > # suffix dc=example,dc=com > # -------------------- > ####################################################################### > database bdb > directory /opt/openldap/var/openldap-data > # some indexes > > # > ---------------------------------------------------------------------------- > # root suffix > # > ---------------------------------------------------------------------------- > suffix "dc=example,dc=com" > checkpoint 512 10 > > # > ---------------------------------------------------------------------------- > # cache settings > # > ---------------------------------------------------------------------------- > > cachesize 60000 > dncachesize 60000 > idlcachesize 60000 > cachefree 100 > > rootdn "cn=Manager,dc=example,dc=com" > rootpw secret > > # Password policy : hash the clear passwords > overlay ppolicy > ppolicy_hash_cleartext > > > # > ---------------------------------------------------------------------------- > # REPLICATION definitions > # > ---------------------------------------------------------------------------- > ####################################################################### > > # I am a master (provider) > # ------------------------------------------ > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > > # syncrepl directive (consummer infos) > # ------------------------------------------ > syncrepl rid=001 > provider=ldap://ldap-master-1.example.com > bindmethod=simple > binddn="uid=ReplicationMaster,ou=Replication,ou=Special > Users,dc=example,dc=com" > credentials=secret > searchbase="dc=example,dc=com" > schemachecking=on > type=refreshAndPersist > retry="60 +" > > mirrormode on > > > # > ---------------------------------------------------------------------------- > # limits > # > ---------------------------------------------------------------------------- > > limits dn.exact="uid=ReplicationMaster,ou=Replication,ou=Special > Users,dc=example,dc=com" size=unlimited time=unlimited > limits dn.exact="uid=ReplicationHub,ou=Replication,ou=Special > Users,dc=example,dc=com" size=unlimited time=unlimited > limits dn.exact="uid=ReplicationLSC,ou=Replication,ou=Special > Users,dc=example,dc=com" size=unlimited time=unlimited > > > ####################################################################### > # suffix o=edition > # ---------------- > ####################################################################### > database bdb > > directory /opt/openldap/var/openldap-data-edition > # some indexes > > > # > ---------------------------------------------------------------------------- > # root suffix > # > ---------------------------------------------------------------------------- > suffix "o=edition" > checkpoint 512 10 > > # > ---------------------------------------------------------------------------- > # cache settings > # > ---------------------------------------------------------------------------- > > cachesize 50000 > dncachesize 50000 > idlcachesize 50000 > cachefree 100 > > > > # > ---------------------------------------------------------------------------- > # rootdn > # > ---------------------------------------------------------------------------- > # Cleartext passwords, especially for the rootdn, should > # be avoid. See slappasswd(8) and slapd.conf(5) for details. > # Use of strong authentication encouraged. > rootdn "cn=Manager,o=edition" > rootpw secret > > # Password policy : hash the clear passwords > overlay ppolicy > ppolicy_hash_cleartext > > > ####################################################################### > # REPLICATION definitions > ####################################################################### > > # I am a master (provider) > # ------------------------------------------ > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > > # syncrepl directive (consummer infos) > # ------------------------------------------ > syncrepl rid=002 > provider=ldap://vspar-ldap-master-1.example.com > bindmethod=simple > binddn="uid=ReplicationMaster,ou=Replication,ou=Special > Users,dc=example,dc=com" > credentials=secret > searchbase="o=edition" > schemachecking=on > type=refreshAndPersist > retry="60 +" > > mirrormode on > > # > ---------------------------------------------------------------------------- > # Limits for current BDB > # > ---------------------------------------------------------------------------- > > limits dn.exact="uid=ReplicationMaster,ou=Replication,ou=Special > Users,dc=example,dc=com" size=unlimited time=unlimited > limits dn.exact="uid=ReplicationHub,ou=Replication,ou=Special > Users,dc=example,dc=com" size=unlimited time=unlimited > limits dn.exact="uid=ReplicationLSC,ou=Replication,ou=Special > Users,dc=example,dc=com" size=unlimited time=unlimited > > > > > > Le 17/02/2012 19:00, Howard Chu a écrit : >> dcoutadeur(a)linagora.com wrote: >>> Full_Name: dcoutadeur >>> Version: 2.4.28 >>> OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga) >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (109.197.176.10) >>> >>> >>> >>> Hello, >>> >>> >>> I had a segfault in the last git version of OpenLDAP, after 10 to 15 >>> tests, each >>> interrupted by Ctrl+C. (see what's a test below) >>> The segfault is also reproduced in version 2.4.28. >>> >>> I think I won't be able to reproduce the bug with Valgrind. >> >> If you expect us to try to reproduce the bug, you'll have to provide >> more information. Since this crash is in syncprov there's obviously at >> least two servers involved; what are their configurations? What hardware >> are they running on (in particular, how many CPU cores per server)? >> Since you're using a custom client, can you provide the client source code? >>> >>> Thank you in advance for any help. >>> >>> D. >>> >>> >>> Note : A test is 100 times 100 threads, each doing a bind, an add, a >>> modify, a >>> delete, and a logout. >>> >>> >>> >>> >>> >>> (gdb) bt full >>> #0 sp_avl_cmp (c1=0x8b4004c8, c2=0xa37cf28) at syncprov.c:366 >>> rc =<value optimized out> >>> #1 0x081afe3e in avl_delete (root=0xa255648, data=0x8b4004c8, >>> fcmp=0x81948a0<sp_avl_cmp>) at avl.c:197 >>> p =<value optimized out> >>> q =<value optimized out> >>> r =<value optimized out> >>> top =<value optimized out> >>> side =<value optimized out> >>> side_bf =<value optimized out> >>> shorter =<value optimized out> >>> nside =<value optimized out> >>> pptr = {0x89908, 0x0, 0x0, 0x0, 0xe8043c, 0x0, 0xfdc, >>> 0x8d994858, 0xe7b95c, 0xfdc, 0xa372570, 0x0, 0xa288350, >>> 0xe8043c, 0xa372570, 0x8d994878, 0xe7c324, 0xfdc, 0xa372570, >>> 0x0, 0xe7af2c, 0x8cb9136e, 0x81b3634, 0x0, 0xe8043c, >>> 0xe, 0xa3d3a40, 0x8d9948b8, 0xe7d081, 0xa3e3618, 0x8cb91358, >>> 0x823c27} >>> pdir = >>> "\000\000\000\000lI\231\215\064\066\033\bn>\000\000\244\345t\000\310\004@\213\b\346\067\n\310H\231\215" >>> >>> depth = 0 >>> #2 0x08199f7f in syncprov_op_cleanup (op=0xa37e608, rs=0x8d995108) at >>> syncprov.c:1401 >>> cb = 0x8cb91258 >>> opc = 0x8cb91268 >>> si = 0xa255610 >>> sm = 0xa255688 >>> snext =<value optimized out> >>> mt = 0x8b4004c8 >>> #3 0x08089654 in slap_cleanup_play (op=0xa37e608, rs=0x8d995108) at >>> result.c:541 >>> sc_next = 0x8d994dec >>> sc = 0x8cb91258 >>> scp = 0x8d994928 >>> #4 0x0808a150 in send_ldap_response (op=0xa37e608, rs=0x8d995108) at >>> result.c:733 >>> berbuf = { >>> buffer = "\000\000\001\000\000\001\000\000\377\377\377\377", >>> '\000'<repeats 12 times>, >>> "f\023\271\214\064#\271\214\000\000\000\000f\023\271\214p%7\n\000\000\000\000\314I\231\215\001\000\000\000\000\000\000\000\314mK\236x\271\347\000\001\000\000\000`+@\213D`K\236\230\063\066\n\250<6\n\000\000\000\000\000\000\000\000\005\000\000\000P7@\213`\343\070\n\000\000\000\000\n\000\000\000(\234\200\330\000\000\000\000\000\000\000\000@4\"\000\000\000\000\000(\234\200\330\210J\231\215\270\214 >>> >>> \000\230\063\066\n`+@\213\314mK\236\r\000\000\000\001\000\000\000\021\217;O(\234\200\330\000\000\000\000`&%\n`&%\n8J\231\215b\f\"\000\224mK\236\230\063\066\n(\234\200أ\347\022\b\a", >>> >>> '\000'<repeats 31 times>, "D'%\n\224mK\236\000\000\000", >>> ialign = 65536, lalign = 65536, falign = 9.18354962e-41, >>> dalign = 5.4323095486619588e-312, >>> palign = 0x10000<Address 0x10000 out of bounds>} >>> ber =<value optimized out> >>> rc = 32768 >>> bytes = 14 >>> __PRETTY_FUNCTION__ = "send_ldap_response" >>> #5 0x0808af1f in slap_send_ldap_result (op=0xa37e608, rs=0x8d995108) at >>> result.c:860 >>> tmp = 0x0 >>> otext = 0x0 >>> oref = 0x0 >>> __PRETTY_FUNCTION__ = "slap_send_ldap_result" >>> #6 0x0812bde5 in bdb_add (op=0xa37e608, rs=0x8d995108) at add.c:511 >>> pdn = {bv_len = 23, bv_val = 0x8b40372f >>> "ou=people,dc=afp,dc=com"} >>> p = 0x8fc4c0fc >>> oe = 0x8fc4c804 >>> ei = 0xa37d1c8 >>> textbuf = "\000\000\000\000\320O\"\n", '\000'<repeats 48 >>> times>, "\001", '\000'<repeats 198 times> >>> children = 0xa223b20 >>> entry = 0xa223980 >>> ltid = 0x0 >>> lt2 = 0x8b402bf0 >>> eid = 57976 >>> opinfo = {boi_oe = {oe_next = {sle_next = 0x8d99509c}, oe_key = >>> 0x0}, boi_txn = 0x8b402b60, boi_locks = 0x0, >>> boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0 '\000'} >>> lock = {off = 133260, ndx = 772, gen = 2004, mode = >>> DB_LOCK_READ} >>> num_retries = 0 >>> success = 0 >>> postread_ctrl = 0x0 >>> ctrls = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0} >>> num_ctrls = 0 >>> #7 0x080e33a1 in overlay_op_walk (op=0xa37e608, rs=0x8d995108, >>> which=op_add, oi=0xa254ff0, on=0xa255508) at backover.c:671 >>> rc = 32768 >>> #8 0x080e3a0a in over_op_func (op=0xa37e608, rs=0x8d995108, >>> which=op_add) at backover.c:723 >>> oi = 0xa254ff0 >>> on = 0xa255508 >>> be = 0xa252560 >>> db = {bd_info = 0x821d41c, bd_self = 0xa252560, >>> be_ctrls = >>> "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\001\000\000\000\000\001\000\001\000\000\000\000\000\000\000\000\000\001", >>> >>> be_flags = 563464, 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 = >>> 0xa288350, be_nsuffix = 0xa288368, be_schemadn = { >>> bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, >>> bv_val = 0x0}, be_rootdn = {bv_len = 24, >>> bv_val = 0xa287648 "cn=Manager,dc=afp,dc=com"}, be_rootndn = >>> {bv_len = 24, >>> bv_val = 0xa2876d0 "cn=manager,dc=afp,dc=com"}, be_rootpw = >>> {bv_len = 38, >>> bv_val = 0xa2876f0 >>> "{SSHA}rEmMhg3MU5xkQX5Ng92tH4WzGMlA+nGU"}, be_max_deref_depth = 15, >>> be_def_limit = { >>> lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 15000, >>> lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, >>> lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = >>> 0xa255748, be_acl = 0x0, be_dfltaccess = ACL_READ, >>> be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = >>> 0x0}, be_update_refs = 0x0, >>> be_pending_csn_list = 0xa363388, be_pcl_mutex = {__data = >>> {__lock = 0, __count = 0, __owner = 0, __kind = 0, >>> __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, >>> __size = '\000'<repeats 23 times>, __align = 0}, >>> be_syncinfo = 0xa28aec8, be_pb = 0x0, be_cf_ocs = 0x821f840, >>> be_private = 0xa252660, be_next = { >>> stqe_next = 0xa288538}} >>> cb = {sc_next = 0x0, sc_response = 0x80e30e0 >>> <over_back_response>, sc_cleanup = 0, sc_private = 0xa254ff0} >>> sc =<value optimized out> >>> rc =<value optimized out> >>> __PRETTY_FUNCTION__ = "over_op_func" >>> #9 0x08081129 in fe_op_add (op=0xa37e608, rs=0x8d995108) at add.c:334 >>> repl_user = 0 >>> rc =<value optimized out> >>> bd = 0x82234c0 >>> textbuf = >>> "\000\000\000\000\000\000\000\000\060[\231\215\000\000\000\000\035\000\000\000\020\070@\213\001\000\000\000xN\231\215\270\026@\213(I\"\n\002\000\000\000\250N\231\215\255\214\v\b\270\026@\213\224N\231\215\001\000\000\000\000\000\000\000x9@\213\000\000\000\000\n\000\000\000\001\000\000\000\340\067@\213\n\000\000\000\060\070@\213\320\026@\213(I\"\n\270\026@\213\370N\231\215oc\t\b\002\000\000\000X( >>> >>> \n\370N\231\215\321_\t\bh\234!\n\240\066@\213'<\202\000\000\000\000\000\f\000\000\000W.@\213n>\000\000\244\345t\000\320O\"\n\320O\"\n\370N\231\215\035\205q\000 >>> >>> .\"\b\314h\032\216\030O\231\215\245\063\b\b >>> .\"\b\240\066@\213\000\000\000\000\270\026@\213\244i\032\216\000\000\000\000HO\231\215\267\r\b\b\320O\"\n\320O\"\n\001\000\000\000HO\231\215\020\000\000\000\340h\032\216\377\377\377\377" >>> >>> __PRETTY_FUNCTION__ = "fe_op_add" >>> #10 0x08081a13 in do_add (op=0xa37e608, rs=0x8d995108) at add.c:194 >>> ber =<value optimized out> >>> last = 0x8b402e71 "" >>> dn = {bv_len = 38, bv_val = 0x8b402d98 >>> "uid=dcoutadeur,ou=People,dc=afp,dc=com"} >>> len = 28 >>> tag =<value optimized out> >>> modlist = 0x8b4015f0 >>> modtail = 0x8b403694 >>> tmp = {sml_mod = {sm_desc = 0x80ce5ca, sm_values = 0x8b4036a0, >>> sm_nvalues = 0x0, sm_numvals = 2375635128, >>> sm_op = 0, sm_flags = 0, sm_type = {bv_len = 12, bv_val = >>> 0x8b402e57 "userPassword"}}, sml_next = 0x823c27} >>> textbuf = >>> "\025\000\000\000\310\031@\213\b\026@\213\006\340(\000\220[\231\215\000\000\000\000\000\000\000\000\020\000@\213\025\000\000\000\310\031@\213\310+@\213\005\070/\000\200O@\213T\245(\000\000\000\000\000\020\000@\213\364\237\067\000\220[\231\215\000\000\000\000\233\071@\213@:=\n\370O\231\215T\213\202\000b\213\202\000;\334\347\000\"\000\000\000\233\071@\213\b\000\000\000\201\354(\000\fP\231\215<\004\350\000\270P\231\215\312\315\347\000\370\326\070\n\233\071@\213\b\000\000\000\001\200\255\373\b\347\067\n@\000\000\000\243P\231\215@\000@\213\026\347\067\n@\000@\213\b\347\067\n@\261\067\000,\000\000\000\020\000@\213", >>> >>> '\000'<repeats 20 times>, >>> "5\000\000\000@\000@\213\000\000\000\000\340\021@\213\000\000\000\000\000\000\000\000\260+@\213\000\000\000\000\001\000\000\000\004\000\020\000\350Q\231\215\310P\231\215" >>> >>> rc =<value optimized out> >>> freevals =<value optimized out> >>> oex = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x8081330}, >>> oe_db = 0x0} >>> #11 0x0807988c in connection_operation (ctx=0x8d9951e8, arg_v=0xa37e608) >>> at connection.c:1150 >>> rc =<value optimized out> >>> cancel =<value optimized out> >>> rs = {sr_type = REP_RESULT, sr_tag = 105, sr_msgid = 2, sr_err = >>> 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, >>> sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, >>> r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, >>> r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = >>> 0x0}, sru_extended = {r_rspoid = 0x0, >>> r_rspdata = 0x0}}, sr_flags = 0} >>> tag = 104 >>> opidx = SLAP_OP_ADD >>> conn = 0xb7f3bc10 >>> memctx = 0xa372570 >>> memctx_null = 0x0 >>> __PRETTY_FUNCTION__ = "connection_operation" >>> #12 0x0807a0fd in connection_read_thread (ctx=0x8d9951e8, argv=0x22) at >>> connection.c:1286 >>> s =<value optimized out> >>> #13 0x00717a24 in ldap_int_thread_pool_wrapper (xpool=0xa2265c8) at >>> tpool.c:688 >>> task = 0xa382e10 >>> work_list =<value optimized out> >>> ctx = {ltu_id = 2375637904, ltu_key = {{ltk_key = 0x80ce400, >>> ltk_data = 0xa372570, >>> ltk_free = 0x80ce430<slap_sl_mem_destroy>}, {ltk_key = >>> 0xa363398, ltk_data = 0xa371a88, >>> ltk_free = 0x812e4c0<bdb_reader_free>}, {ltk_key = >>> 0x8078320, ltk_data = 0xa37de68, >>> ltk_free = 0x80783f0<conn_counter_destroy>}, {ltk_key = >>> 0x808dde0, ltk_data = 0x0, >>> ltk_free = 0x808dbf0<slap_op_q_destroy>}, {ltk_key = 0x0, >>> ltk_data = 0x0, ltk_free = 0}<repeats 28 times>}} >>> kctx =<value optimized out> >>> keyslot = 241 >>> hash = 5278961 >>> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" >>> #14 0x00821832 in start_thread () from /lib/libpthread.so.0 >>> No symbol table info available. >>> #15 0x002f746e in clone () from /lib/libc.so.6 >>> No symbol table info available. >>> >>> >>> >>> >>> >> >>

1 0

Re: ITS#7208
by hyc＠symas.com 15 Mar '12

15 Mar '12

andre.cardinal(a)bell.ca wrote: > --_000_7B0942425E628C468907C3029A0F33E49DBC85FAMBX16bellcorpbc_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Has anyone tried to reproduce this at 2.4.24 We only investigate bugs reported against a current release. 2.4.24 is over a year old. There is nothing for us to reproduce, you have not provided any configuration information nor initial database contents nor explicit steps to reproduce. You have not provided a backtrace from any core dump. You have not read any of the relevant documentation: http://www.openldap.org/faq/data/cache/56.html > I have not seen anything in the latest releases that points to that. > > > > From: Cardinal, Andre (520972) > Sent: March-14-12 10:18 AM > To: 'openldap-its(a)openldap.org' > Subject: ITS#7208 > > In order to speed up reproducing the bug, I changed the keep_alive_interval= > to 600000 (10 minutes) > > The Slave coredumped after 10 minutes of not being able to communicate with= > it's Master. > > --_000_7B0942425E628C468907C3029A0F33E49DBC85FAMBX16bellcorpbc_ > Content-Type: text/html; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= > osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= > icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= > :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= > uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= > t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= > m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= > t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= > :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= > soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = > xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= > icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= > schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= > point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= > /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= > =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= > schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= > .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= > /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= > ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= > repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= > xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= > schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= > /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= > ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= > p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/= > /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche= > mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi= > crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat= > s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf= > ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c= > om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa= > ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web= > partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20= > 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200= > 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli= > deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal= > Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:= > st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta http-equi= > v=3DContent-Type content=3D"text/html; charset=3Dus-ascii"><meta name=3DGen= > erator content=3D"Microsoft Word 12 (filtered medium)"><style></style></head><body lang=3DEN-CA link=3Dblue vli= > nk=3Dpurple><div class=3DWordSection1> olor:#1F497D'>Has anyone tried to reproduce this at 2.4.24<o:p></o:p></span= >> <o:p> </o:p></= > span>I have not seen= > anything in the latest releases that points to that.<o:p></o:p>= > <o:p> </o:p>= > <o:p> </o:p></s= > pan><o:p> </o:p= >> <div><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;p= > adding:3.0pt 0cm 0cm 0cm'> =3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:<sp= > an lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"= > '> Cardinal, Andre (520972) Sent: March-14-12 10:18 AM To:= > 'openldap-its(a)openldap.org' Subject: ITS#7208<o:p></o:p></sp= > an></div></div><o:p> </o:p> Normal>In order to speed up reproducing the bug, I changed the keep_alive_i= > nterval to 600000 (10 minutes)<o:p></o:p><o:p>&nbs= > p;</o:p>The Slave coredumped after 10 minutes of n= > ot being able to communicate with it’s Master.<o:p></o:p></div></= > body></html>= > > --_000_7B0942425E628C468907C3029A0F33E49DBC85FAMBX16bellcorpbc_-- > > > -- -- 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#7208
by andre.cardinal＠bell.ca 15 Mar '12

15 Mar '12

--_000_7B0942425E628C468907C3029A0F33E49DBC85FAMBX16bellcorpbc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Has anyone tried to reproduce this at 2.4.24 I have not seen anything in the latest releases that points to that. From: Cardinal, Andre (520972) Sent: March-14-12 10:18 AM To: 'openldap-its(a)openldap.org' Subject: ITS#7208 In order to speed up reproducing the bug, I changed the keep_alive_interval= to 600000 (10 minutes) The Slave coredumped after 10 minutes of not being able to communicate with= it's Master. --_000_7B0942425E628C468907C3029A0F33E49DBC85FAMBX16bellcorpbc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/= /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche= mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi= crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat= s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf= ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c= om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa= ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web= partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20= 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200= 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli= deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal= Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:= st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta http-equi= v=3DContent-Type content=3D"text/html; charset=3Dus-ascii"><meta name=3DGen= erator content=3D"Microsoft Word 12 (filtered medium)"><style></style></head><body lang=3DEN-CA link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1>Has anyone tried to reproduce this at 2.4.24<o:p></o:p></span= ><o:p> </o:p></= span>I have not seen= anything in the latest releases that points to that.<o:p></o:p>= <o:p> </o:p>= <o:p> </o:p></s= pan><o:p> </o:p= ><div><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;p= adding:3.0pt 0cm 0cm 0cm'>From:<sp= an lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"= '> Cardinal, Andre (520972) Sent: March-14-12 10:18 AM To:= 'openldap-its(a)openldap.org' Subject: ITS#7208<o:p></o:p></sp= an></div></div><o:p> </o:p>In order to speed up reproducing the bug, I changed the keep_alive_i= nterval to 600000 (10 minutes)<o:p></o:p><o:p>&nbs= p;</o:p>The Slave coredumped after 10 minutes of n= ot being able to communicate with it’s Master.<o:p></o:p></div></= body></html>= --_000_7B0942425E628C468907C3029A0F33E49DBC85FAMBX16bellcorpbc_--

1 0

Re: (ITS#7209) Changes to libraries/libmdb/mdb.c needed to build on FreeBSD
by 4glitch＠gmail.com 14 Mar '12

14 Mar '12

03/14/2012 11:08 PM, Howard Chu написав(ла): > No. Compile with -DMDB_SYNC and -DMDB_FDATASYNC yourself like it says > in the comments in mdb.c. > Why ANDROID and __APPLE__ special? mdb.c contains definitions of fdatasync(fd) for it.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2012