- openldap-bugs - openldap.org

Re: (ITS#5894) test039 fails: ldap_back_conn_delete: Assertion
by hyc＠symas.com 18 Jan '09

18 Jan '09

Michael Ströder wrote: > Howard Chu wrote: >> michael(a)stroeder.com wrote: >>> Full_Name: Michael Ströder >>> Version: HEAD >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (84.163.100.169) >>> >>> >>> lt-slapd: bind.c:157: ldap_back_conn_delete: Assertion >>> `!(*(&((lc))->lc_lcflags) >>> & (((0x00000020U))))' failed. >> I'm not seeing that here. Ran into a couple other problems though, fixed >> now in HEAD. Please re-test... > > Now test008 hangs... Works fine for me on my single-core and dual-core machines. -- -- 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#5888) MSVC 9.0 build issue
by Kurt＠OpenLDAP.org 17 Jan '09

17 Jan '09

On Jan 14, 2009, at 2:02 PM, kurt(a)openldap.org wrote: > Full_Name: Kurt Zeilenga > Version: HEAD > OS: Windows Server 2008 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2002:4b8d:e980:0:217:f2ff:fed0:27f1) > Submitted by: kurt > > > The current configure script checks for _vsnprintf and then defines > a macro > #define vsnprintf _vsnprintf. > But the system has a vsnprintf. This causes a clash in <stdio.h> > which defines > both vsnprintf and _vsnprintf. > > configure.in and include/portable.in need a bit of work to detected > this > situation.... I've committed a few changes to the build system to address this issue. Hopefully I didn't break any working builds.... -- Kurt

1 0

Re: (ITS#5894) test039 fails: ldap_back_conn_delete: Assertion
by michael＠stroeder.com 17 Jan '09

17 Jan '09

Howard Chu wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Ströder >> Version: HEAD >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.163.100.169) >> >> >> lt-slapd: bind.c:157: ldap_back_conn_delete: Assertion >> `!(*(&((lc))->lc_lcflags) >> & (((0x00000020U))))' failed. > > I'm not seeing that here. Ran into a couple other problems though, fixed > now in HEAD. Please re-test... Now test008 hangs... Ciao, Michael.

1 0

Re: (ITS#5880) back-bdb segfault
by quanah＠zimbra.com 16 Jan '09

16 Jan '09

--On Saturday, January 17, 2009 2:38 AM +0000 jwm(a)horde.net wrote: > On Fri, Jan 16, 2009 at 06:14:01PM -0800, Quanah Gibson-Mount wrote: >> --On Saturday, January 17, 2009 2:08 AM +0000 jwm(a)horde.net wrote: >> > RE24 as of 13 January 2009 is still crashing, sometimes due to an >> > assertion failure and sometimes due to a segfault when manipulating the >> > back-bdb cache. >> >> Well, I'm not sure I'd use RE24 CVS right now. There's a lot of pending >> fixes that I'll be doing soon to go into it. > > So your recommendation would be... to revert to 2.4.13 and wait for these > fixes to land in RE24 to see if they fix the back-bdb cache-related > segfaults I'm reporting in this ITS? I'm just warning that current RE24 is not expected to be at all stable. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5880) back-bdb segfault
by jwm＠horde.net 16 Jan '09

16 Jan '09

On Fri, Jan 16, 2009 at 06:14:01PM -0800, Quanah Gibson-Mount wrote: > --On Saturday, January 17, 2009 2:08 AM +0000 jwm(a)horde.net wrote: > > RE24 as of 13 January 2009 is still crashing, sometimes due to an > > assertion failure and sometimes due to a segfault when manipulating the > > back-bdb cache. > > Well, I'm not sure I'd use RE24 CVS right now. There's a lot of pending > fixes that I'll be doing soon to go into it. So your recommendation would be... to revert to 2.4.13 and wait for these fixes to land in RE24 to see if they fix the back-bdb cache-related segfaults I'm reporting in this ITS? john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

Re: (ITS#5880) back-bdb segfault
by quanah＠zimbra.com 16 Jan '09

16 Jan '09

--On Saturday, January 17, 2009 2:08 AM +0000 jwm(a)horde.net wrote: > RE24 as of 13 January 2009 is still crashing, sometimes due to an > assertion failure and sometimes due to a segfault when manipulating the > back-bdb cache. Well, I'm not sure I'd use RE24 CVS right now. There's a lot of pending fixes that I'll be doing soon to go into it. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5880) back-bdb segfault
by jwm＠horde.net 16 Jan '09

16 Jan '09

RE24 as of 13 January 2009 is still crashing, sometimes due to an assertion failure and sometimes due to a segfault when manipulating the back-bdb cache. john Program received signal SIGABRT, Aborted. [Switching to Thread -2060530768 (LWP 15691)] 0xb7f1e410 in ?? () Thread 34 (Thread 2023709616 (LWP 15733)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x789f5288 in ?? () No symbol table info available. #2 0x0667e8e1 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 33 (Thread 2027908016 (LWP 15732)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x78df6288 in ?? () No symbol table info available. #2 0x0667e8d5 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 32 (Thread 2032106416 (LWP 15731)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x791f7288 in ?? () No symbol table info available. #2 0x0667e8de in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 31 (Thread 2036304816 (LWP 15730)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x795f7918 in ?? () No symbol table info available. #2 0x00000002 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 30 (Thread 2040503216 (LWP 15729)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x799f9208 in ?? () No symbol table info available. #2 0x00000002 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 29 (Thread 2044701616 (LWP 15728)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x79dfa288 in ?? () No symbol table info available. #2 0x0667e8e4 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 28 (Thread 2048900016 (LWP 15727)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x7a0f9758 in ?? () No symbol table info available. #2 0x00000000 in ?? () No symbol table info available. Thread 27 (Thread 2108611504 (LWP 15726)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x7daed288 in ?? () No symbol table info available. #2 0x0667e8d7 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 26 (Thread 2112809904 (LWP 15725)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x7deee288 in ?? () No symbol table info available. #2 0x0667e8fc in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 25 (Thread 2117008304 (LWP 15724)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x7e2ef288 in ?? () No symbol table info available. #2 0x0667e8d8 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 24 (Thread 2121206704 (LWP 15723)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x7e6f0288 in ?? () No symbol table info available. #2 0x0667e8ef in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 23 (Thread 2125405104 (LWP 15722)): #0 0xb7e69f82 in __db_shalloc () from /usr/lib/libdb-4.4.so No symbol table info available. #1 0xb7e937ff in __memp_alloc () from /usr/lib/libdb-4.4.so No symbol table info available. #2 0xb7e94f46 in __memp_fget () from /usr/lib/libdb-4.4.so No symbol table info available. #3 0xb7df3de5 in __bam_search () from /usr/lib/libdb-4.4.so No symbol table info available. #4 0xb7de6066 in __bam_c_init () from /usr/lib/libdb-4.4.so No symbol table info available. #5 0xb7de6fc5 in __bam_c_init () from /usr/lib/libdb-4.4.so No symbol table info available. #6 0xb7e517d4 in __db_c_get () from /usr/lib/libdb-4.4.so No symbol table info available. #7 0xb7e585e0 in __db_c_get_pp () from /usr/lib/libdb-4.4.so No symbol table info available. #8 0xb7677bb7 in bdb_id2entry (be=0x823f6e0, tid=0x825b5098, id=108293, e=0x7ea2fec8) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/back-bdb/id2entry.c:125 bdb = <value optimized out> db = <value optimized out> key = {data = 0x7ea2fe34, size = 4, ulen = 0, dlen = 0, doff = 0, flags = 0} data = {data = 0x7ea2fe24, size = 0, ulen = 16, dlen = 16, doff = 0, flags = 40} cursor = (DBC *) 0x86e6598 eh = {bv = {bv_len = 136575368, bv_val = 0x823f88c "\210ù#\b"}, data = 0x7ea2fe28 "Hþ¢~Öêí·\210ù#\b", nattrs = -1209133891, nvals = 136575368} buf = "ü;ñ·Hþ¢~Öêí·\210ù#\b" rc = 136922528 off = <value optimized out> nid = 94830848 #9 0xb767c7b2 in bdb_cache_find_id (op=0x6d5396b0, tid=0x825b5098, id=108293, eip=0x7eaf00ec, flag=0, lock=0x7eaf0044) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/back-bdb/cache.c:844 bdb = (struct bdb_info *) 0x823f7e0 ep = (Entry *) 0x0 rc = <value optimized out> load = <value optimized out> ei = {bei_parent = 0x0, bei_id = 108293, bei_lockpad = 0, bei_state = 0, bei_finders = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0} #10 0xb766f3b5 in bdb_search (op=0x6d5396b0, rs=0x7eaf11e8) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/back-bdb/search.c:705 scopeok = 1 bdb = (struct bdb_info *) 0x823f7e0 id = 108293 cursor = 1 lastid = 4294967295 candidates = {1, 108293, 1116174, 566139, 566155, 566157, 566550, 566680, 566820, 566837, 566847, 566997, 567006, 567010, 567011, 567012, 567013, 567014, 567016, 567017, 567018, 567019, 567020, 567021, 567022, 567023, 567024, 567025, 567026, 567027, 567028, 567029, 567030, 567031, 567032, 567033, 567034, 567035, 567036, 567037, 567038, 567039, 567040, 567041, 567042, 567043, 567044, 567045, 567046, 567047, 567048, 567049, 567050, 567051, 567052, 567053, 567054, 567055, 567056, 567057, 567058, 567059, 567060, 567061, 567062, 567063, 567064, 567065, 567066, 567067, 567068, 567069, 567070, 567071, 567072, 567073, 567074, 567075, 567076, 567077, 567078, 567079, 567080, 567081, 567082, 567083, 567084, 567085, 567086, 567087, 567088, 567089, 567090, 567091, 567092, 567093, 567094, 567095, 567096, 567097, 567098, 567099, 567100, 567101, 567102, 567103, 567104, 567105, 567106, 567107, 567108, 567109, 567110, 567111, 567112, 567113, 567114, 567115, 567116, 567117, 567118, 567119, 567120, 567121, 567122, 567123, 567124, 567125, 567126, 567127, 567128, 567129, 567130, 567131, 567132, 567133, 567134, 567135, 567136, 567137, 567138, 567139, 567140, 567141, 567142, 567143, 567144, 567145, 567146, 567147, 567148, 567149, 567150, 567151, 567152, 567153, 567154, 567155, 567156, 567157, 567158, 567159, 567160, 567161, 567162, 567163, 567164, 567165, 567166, 567167, 567168, 567169, 567170, 567171, 567172, 567173, 567174, 567175, 567176, 567177, 567178, 567179, 567180, 567181, 567182, 567183, 567184, 567185, 567186, 567187, 567188, 567189, 567190, 567191, 567192, 567193, 567194, 567195, 567196, 567197...} scopes = {0 <repeats 64575 times>, 2125394152, 2050, 4, 3082275187, 0, 2125394172, 3085773032, 3898, 3075299736, 2125394184, 3085762252, 3898, 4, 2050, 0, 3085773032, 160652680, 2125398328, 3085762532, 3898, 1, 0 <repeats 248 times>, 1873467851, 2125397492, 134969792, 2125397492, 2125395240, 134969835, 2097046852, 136294584, 0, 0, 0, 136295264, 2125395272, 135218913, 2125397492, 136295248, 0, 2125397492, 2125397620, 2125397624, 2125395304, 134965375, 136097816, 2125397492, 134969792, 0, 2097046828, 2097046828, 2125397528, 134959773, 2125397492, 59, 1, 0, 0, 0, 0, 0, 0, 2097046852, 1873467851, 2125397652, 134969792, 2125397652, 2125395400, 134969835, 2097046788, 136294584, 0, 0, 0, 136295264, 2125395432, 135218913, 2125397652, 136295248, 0, 2125397652, 2125397780, 2125397784, 2125395464, 134965375, 136097816, 2125397652, 134969792, 1708152080, 2097046764, 2097046764, 2125397688, 134959773, 2125397652, 59, 1, 134837599, 1806731104, 0, 0, 0, 0, 2097046788, 0, 2097046789, 0, 0, 0, 0, 0, 1, 136295072, 2125397844, 134969792, 0, 1705695691, 2125397860, 134969792, 2125397860, 2125395608, 134969835, 1883145885, 136403296, 0, 135218913, 2125397844, 136404184, 2125395640, 135218913, 2125397860, 136403392, 2125395656, 2125397860, 2125402620, 2125397956, 2125395672, 134965375, 136097816, 2125397860, 134969792, 134959773, 2125397996, 2125397996, 2125397896, 134959773, 2125397860, 59, 10, 135218913, 2125397940, 1864288817, 1940576715, 2125398004, 134969792, 2125398004, 2125395752, 134969835, 1841762540, 136379720, 0, 134837599, 2125398076, 136380088, 2125395784, 135218913, 2125398004, 136380072, 1940576715, 2125398004, 2125402620, 2097046236, 1873467851, 2125398084, 134969792, 2125398084, 2125395832, 134969835, 2097045556, 136294584, 0, 134959773, 2125398004...} e = (Entry *) 0xa1ebd26c base = {e_id = 1, e_name = {bv_len = 3085773032, bv_val = 0x70ab8e30 "\002"}, e_nname = {bv_len = 10, bv_val = 0x6b3931b0 "o=example"}, e_attrs = 0xb7ed28e8, e_ocflags = 1890291248, e_bv = {bv_len = 2125398124, bv_val = 0x7eaf0018 "\210"}, e_private = 0x829eb30} e_root = (Entry *) 0x8c52700c matched = (Entry *) 0x0 ei = (EntryInfo *) 0x0 realbase = {bv_len = 10, bv_val = 0x6b3931b0 "o=example"} mask = <value optimized out> manageDSAit = 0 tentries = 1 nentries = 1 idflag = 0 lock = {off = 0, ndx = 386, gen = 9278918, mode = DB_LOCK_READ} opinfo = (struct bdb_op_info *) 0x0 ltid = (DB_TXN *) 0x825b5098 oex = (OpExtra *) 0x0 #11 0x080760d6 in fe_op_search (op=0x6d5396b0, rs=0x7eaf11e8) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/search.c:366 defref = <value optimized out> bd = (BackendDB *) 0x815bdc0 #12 0x080768b7 in do_search (op=0x6d5396b0, rs=0x7eaf11e8) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/search.c:217 base = {bv_len = 10, bv_val = 0x6b5ba71f "o=example"} siz = 2 i = 2125402760 #13 0x08073b11 in connection_operation (ctx=0x7eaf12c8, arg_v=0x6d5396b0) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/connection.c:1090 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 *) 0xb74d0c40 memctx = (void *) 0x87152e0 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #14 0x0807412e in connection_read_thread (ctx=0x7eaf12c8, argv=0xf03) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/connection.c:1216 s = <value optimized out> #15 0xb7ee0b66 in ldap_int_thread_pool_wrapper (xpool=0x81e7ba8) at /tmp/buildd/openldap-2.4.14~cvs20090113/libraries/libldap_r/tpool.c:663 task = (ldap_int_thread_task_t *) 0x82962c0 work_list = <value optimized out> ctx = {ltu_id = 2125405104, ltu_key = {{ltk_key = 0x8072c80, ltk_data = 0x87151f0, ltk_free = 0x8072d40 <conn_counter_destroy>}, {ltk_key = 0x80c87e0, ltk_data = 0x87152e0, ltk_free = 0x80c8320 <slap_sl_mem_destroy>}, {ltk_key = 0x82945a0, ltk_data = 0x825b5098, ltk_free = 0xb767ac40 <bdb_reader_free>}, {ltk_key = 0x8087450, ltk_data = 0x6da7c9a0, ltk_free = 0x8087250 <slap_op_q_destroy>}, {ltk_key = 0xb766d5b0, ltk_data = 0x75eea008, ltk_free = 0xb766d690 <search_stack_free>}, {ltk_key = 0x82927b8, ltk_data = 0x6eda6798, ltk_free = 0xb767ac40 <bdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x6bc8b3e8, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = <value optimized out> keyslot = 984 hash = 6357976 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #16 0xb7b77240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 No symbol table info available. #17 0xb7b0c49e in clone () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. Thread 22 (Thread 2129603504 (LWP 15721)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x7eef2288 in ?? () No symbol table info available. #2 0x0667e8f9 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 21 (Thread 2143247280 (LWP 15720)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x7fbf5288 in ?? () No symbol table info available. #2 0x0667e8fa in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 20 (Thread -2139128912 (LWP 15719)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x807f7288 in ?? () No symbol table info available. #2 0x0667e8d6 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 19 (Thread -2132825168 (LWP 15718)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x80dfa288 in ?? () No symbol table info available. #2 0x0667e8f4 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 18 (Thread -2128626768 (LWP 15717)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x811fb288 in ?? () No symbol table info available. #2 0x0667e8fb in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 17 (Thread -2124428368 (LWP 15716)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x815fc288 in ?? () No symbol table info available. #2 0x0667e8e3 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 16 (Thread -2120229968 (LWP 15715)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x819fd288 in ?? () No symbol table info available. #2 0x0667e8e0 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 15 (Thread -2116031568 (LWP 15714)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x81dfe288 in ?? () No symbol table info available. #2 0x0667e8f6 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 14 (Thread -2111833168 (LWP 15713)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x821ff288 in ?? () No symbol table info available. #2 0x0667e8f2 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 13 (Thread -1945556048 (LWP 15682)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x8c090338 in ?? () No symbol table info available. #2 0x00000002 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 12 (Thread -1949754448 (LWP 15683)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x8bc91288 in ?? () No symbol table info available. #2 0x0667e8f7 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 11 (Thread -1953952848 (LWP 15684)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x8b88f0f8 in ?? () No symbol table info available. #2 0x00000002 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 10 (Thread -1958151248 (LWP 15685)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x8b48f288 in ?? () No symbol table info available. #2 0x0667e905 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 9 (Thread -1962349648 (LWP 15686)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x8b08e288 in ?? () No symbol table info available. #2 0x0667e8df in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 8 (Thread -1980777552 (LWP 15687)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x89efb288 in ?? () No symbol table info available. #2 0x0667e8e2 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 7 (Thread -1986028624 (LWP 15688)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x899f9288 in ?? () No symbol table info available. #2 0x0667e904 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 6 (Thread -1990227024 (LWP 15689)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x895f8288 in ?? () No symbol table info available. #2 0x0667e8eb in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 5 (Thread -2038494288 (LWP 15690)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x8672ea78 in ?? () No symbol table info available. #2 0x00004000 in ?? () No symbol table info available. #3 0x96d240a0 in ?? () No symbol table info available. #4 0xb7afbe76 in pread64 () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. #5 0xb7ea2a51 in __os_io () from /usr/lib/libdb-4.4.so No symbol table info available. #6 0xb7e94389 in __memp_pgread () from /usr/lib/libdb-4.4.so No symbol table info available. #7 0xb7e954c3 in __memp_fget () from /usr/lib/libdb-4.4.so No symbol table info available. #8 0xb7df3de5 in __bam_search () from /usr/lib/libdb-4.4.so No symbol table info available. #9 0xb7de6066 in __bam_c_init () from /usr/lib/libdb-4.4.so No symbol table info available. #10 0xb7de6fc5 in __bam_c_init () from /usr/lib/libdb-4.4.so No symbol table info available. #11 0xb7e517d4 in __db_c_get () from /usr/lib/libdb-4.4.so No symbol table info available. #12 0xb7e585e0 in __db_c_get_pp () from /usr/lib/libdb-4.4.so No symbol table info available. #13 0xb7677bb7 in bdb_id2entry (be=0x823f6e0, tid=0x82bca98, id=107884, e=0x8672eec8) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/back-bdb/id2entry.c:125 bdb = <value optimized out> db = <value optimized out> key = {data = 0x8672ee34, size = 4, ulen = 0, dlen = 0, doff = 0, flags = 0} data = {data = 0x8672ee24, size = 0, ulen = 16, dlen = 16, doff = 0, flags = 40} cursor = (DBC *) 0x7b402018 eh = {bv = {bv_len = 136575368, bv_val = 0x823f88c "\210ù#\b"}, data = 0x8672ee28 "Hîr\206Öêí·\210ù#\b", nattrs = -1209133891, nvals = 136575368} buf = "ü;ñ·Hîr\206Öêí·\210ù#\b" rc = 136922528 off = <value optimized out> nid = 1822753024 #14 0xb767c7b2 in bdb_cache_find_id (op=0x6db21f70, tid=0x82bca98, id=107884, eip=0x867ef0ec, flag=0, lock=0x867ef044) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/back-bdb/cache.c:844 bdb = (struct bdb_info *) 0x823f7e0 ep = (Entry *) 0x0 rc = <value optimized out> load = <value optimized out> ei = {bei_parent = 0x0, bei_id = 107884, bei_lockpad = 0, bei_state = 0, bei_finders = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0} #15 0xb766f3b5 in bdb_search (op=0x6db21f70, rs=0x867f01e8) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/back-bdb/search.c:705 scopeok = 1 bdb = (struct bdb_info *) 0x823f7e0 id = 107884 cursor = 1 lastid = 4294967295 candidates = {1, 107884, 1116174, 566139, 566155, 566157, 566550, 566680, 566820, 566837, 566847, 566997, 567006, 567010, 567011, 567012, 567013, 567014, 567016, 567017, 567018, 567019, 567020, 567021, 567022, 567023, 567024, 567025, 567026, 567027, 567028, 567029, 567030, 567031, 567032, 567033, 567034, 567035, 567036, 567037, 567038, 567039, 567040, 567041, 567042, 567043, 567044, 567045, 567046, 567047, 567048, 567049, 567050, 567051, 567052, 567053, 567054, 567055, 567056, 567057, 567058, 567059, 567060, 567061, 567062, 567063, 567064, 567065, 567066, 567067, 567068, 567069, 567070, 567071, 567072, 567073, 567074, 567075, 567076, 567077, 567078, 567079, 567080, 567081, 567082, 567083, 567084, 567085, 567086, 567087, 567088, 567089, 567090, 567091, 567092, 567093, 567094, 567095, 567096, 567097, 567098, 567099, 567100, 567101, 567102, 567103, 567104, 567105, 567106, 567107, 567108, 567109, 567110, 567111, 567112, 567113, 567114, 567115, 567116, 567117, 567118, 567119, 567120, 567121, 567122, 567123, 567124, 567125, 567126, 567127, 567128, 567129, 567130, 567131, 567132, 567133, 567134, 567135, 567136, 567137, 567138, 567139, 567140, 567141, 567142, 567143, 567144, 567145, 567146, 567147, 567148, 567149, 567150, 567151, 567152, 567153, 567154, 567155, 567156, 567157, 567158, 567159, 567160, 567161, 567162, 567163, 567164, 567165, 567166, 567167, 567168, 567169, 567170, 567171, 567172, 567173, 567174, 567175, 567176, 567177, 567178, 567179, 567180, 567181, 567182, 567183, 567184, 567185, 567186, 567187, 567188, 567189, 567190, 567191, 567192, 567193, 567194, 567195, 567196, 567197...} scopes = {0 <repeats 63566 times>, 2256458040, 10477568, 0, 3081815370, 0, 0, 0, 0, 10477568, 2256458104, 8192, 2256458168, 2256458104, 3082274740, 8192, 3085575758, 50, 2256458168, 8192, 1, 0, 0, 0, 0, 2256458168, 8192, 8192, 3085711272, 1809692152, 136914872, 2256466376, 3085374890, 136914872, 1809692152, 2256458168, 8192, 2256466360, 0, 0, 0, 0, 0, 2256458168, 0 <repeats 966 times>, 2256462056, 2050, 4, 3082275187, 0, 2256462076, 3085773032, 3898, 3075299736, 2256462088, 3085762252, 3898, 4, 2050, 0, 3085773032, 1884323152, 2256466232, 3085762532, 3898, 1, 0 <repeats 248 times>, 1873467851, 2256465396, 134969792, 2256465396, 2256463144, 134969835, 2251224388, 136294584, 0, 0, 0, 136295264, 2256463176, 135218913, 2256465396, 136295248, 0, 2256465396, 2256465524, 2256465528, 2256463208, 134965375, 136097816, 2256465396, 134969792, 0, 2251224364, 2251224364, 2256465432, 134959773, 2256465396, 59, 1, 0, 0, 0, 0, 0, 0, 2251224388, 1873467851, 2256465556, 134969792, 2256465556, 2256463304, 134969835, 2251224324, 136294584, 0, 0, 0, 136295264, 2256463336, 135218913, 2256465556, 136295248, 0, 2256465556, 2256465684, 2256465688, 2256463368, 134965375, 136097816, 2256465556, 134969792, 0, 2251224300, 2251224300, 2256465592, 134959773, 2256465556, 59, 1, 0, 0, 0, 0, 0, 0, 2251224324, 0, 2251224325, 0, 0, 0, 0, 0, 1, 1940576715, 2256465748, 134969792, 2256465748, 1705695691, 2256465764, 134969792, 2256465764, 2256463512, 134969835, 1883145888, 136403296, 0, 135218913, 2256465748, 136404184, 2256463544, 135218913...} e = (Entry *) 0xa1ebe644 base = {e_id = 1, e_name = {bv_len = 3085773032, bv_val = 0x6ffde498 "\002"}, e_nname = {bv_len = 10, bv_val = 0x6edbf238 "o=example"}, e_attrs = 0xb7ed28e8, e_ocflags = 1878910104, e_bv = {bv_len = 2256466028, bv_val = 0x867ef018 "\210ð~\206\224\227ì·\230äýolð~\206"}, e_private = 0x829eb30} e_root = (Entry *) 0x8c52700c matched = (Entry *) 0x0 ei = (EntryInfo *) 0x0 realbase = {bv_len = 10, bv_val = 0x6edbf238 "o=example"} mask = <value optimized out> manageDSAit = 0 tentries = 1 nentries = 1 idflag = 0 lock = {off = 0, ndx = 386, gen = 9278894, mode = DB_LOCK_READ} opinfo = (struct bdb_op_info *) 0x0 ltid = (DB_TXN *) 0x82bca98 oex = (OpExtra *) 0x0 #16 0x080760d6 in fe_op_search (op=0x6db21f70, rs=0x867f01e8) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/search.c:366 defref = <value optimized out> bd = (BackendDB *) 0x815bdc0 #17 0x080768b7 in do_search (op=0x6db21f70, rs=0x867f01e8) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/search.c:217 base = {bv_len = 10, bv_val = 0x6ea522f8 "o=example"} siz = 1 i = 2256470664 #18 0x08073b11 in connection_operation (ctx=0x867f02c8, arg_v=0x6db21f70) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/connection.c:1090 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 *) 0xb7437bf8 memctx = (void *) 0x82bdd80 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #19 0x0807412e in connection_read_thread (ctx=0x867f02c8, argv=0x836) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/connection.c:1216 s = <value optimized out> #20 0xb7ee0b66 in ldap_int_thread_pool_wrapper (xpool=0x81e7ba8) at /tmp/buildd/openldap-2.4.14~cvs20090113/libraries/libldap_r/tpool.c:663 task = (ldap_int_thread_task_t *) 0x6f6d4df8 work_list = <value optimized out> ctx = {ltu_id = 2256473008, ltu_key = {{ltk_key = 0x8072c80, ltk_data = 0x82b5f30, ltk_free = 0x8072d40 <conn_counter_destroy>}, {ltk_key = 0x80c87e0, ltk_data = 0x82bdd80, ltk_free = 0x80c8320 <slap_sl_mem_destroy>}, {ltk_key = 0x82945a0, ltk_data = 0x82bca98, ltk_free = 0xb767ac40 <bdb_reader_free>}, {ltk_key = 0x8087450, ltk_data = 0x6f9e6da0, ltk_free = 0x8087250 <slap_op_q_destroy>}, {ltk_key = 0xb766d5b0, ltk_data = 0x85aee008, ltk_free = 0xb766d690 <search_stack_free>}, {ltk_key = 0x82927b8, ltk_data = 0x7070b738, ltk_free = 0xb767ac40 <bdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x6bc8b3e8, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = <value optimized out> keyslot = 416 hash = 6334880 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #21 0xb7b77240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 No symbol table info available. #22 0xb7b0c49e in clone () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. Thread 4 (Thread -2060530768 (LWP 15691)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x852eb008 in ?? () No symbol table info available. #2 0x00000006 in ?? () No symbol table info available. #3 0x00003d4b in ?? () No symbol table info available. #4 0xb7a69811 in raise () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. #5 0xb7a6afb9 in abort () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. #6 0xb7a62fbf in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. #7 0x0806e59c in slap_listener_thread (ctx=0x852ec2c8, ptr=0x819d178) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/daemon.c:1803 No locals. #8 0xb7ee0b66 in ldap_int_thread_pool_wrapper (xpool=0x81e7ba8) at /tmp/buildd/openldap-2.4.14~cvs20090113/libraries/libldap_r/tpool.c:663 task = (ldap_int_thread_task_t *) 0x86ce628 work_list = <value optimized out> ctx = {ltu_id = 2234436528, ltu_key = {{ltk_key = 0x8072c80, ltk_data = 0x82f9900, ltk_free = 0x8072d40 <conn_counter_destroy>}, {ltk_key = 0x80c87e0, ltk_data = 0x82f7d50, ltk_free = 0x80c8320 <slap_sl_mem_destroy>}, {ltk_key = 0x82945a0, ltk_data = 0x82f99f0, ltk_free = 0xb767ac40 <bdb_reader_free>}, {ltk_key = 0x8087450, ltk_data = 0x6a57b6d8, ltk_free = 0x8087250 <slap_op_q_destroy>}, {ltk_key = 0xb766d5b0, ltk_data = 0x83be6008, ltk_free = 0xb766d690 <search_stack_free>}, {ltk_key = 0x82927b8, ltk_data = 0x6e724b40, ltk_free = 0xb767ac40 <bdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x6cf15908, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = <value optimized out> keyslot = 110 hash = 6545518 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #9 0xb7b77240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 No symbol table info available. #10 0xb7b0c49e in clone () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. Thread 3 (Thread -2065781840 (LWP 15692)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x84dea288 in ?? () No symbol table info available. #2 0x0667e903 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 2 (Thread -2071032912 (LWP 15693)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0x848e8288 in ?? () No symbol table info available. #2 0x0667e8f8 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 1 (Thread -1214183744 (LWP 15680)): #0 0xb7f1e410 in ?? () No symbol table info available. #1 0xbfa5f578 in ?? () No symbol table info available. #2 0x00003d42 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. #0 0xb7f1e410 in ?? () Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1962181712 (LWP 23118)] 0xb7ba2024 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0 Thread 34 (Thread 1807735728 (LWP 23173)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x6bbfd288 in ?? () No symbol table info available. #2 0x06ec61f2 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 33 (Thread 1811934128 (LWP 23172)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x6bffe288 in ?? () No symbol table info available. #2 0x06ec61df in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 32 (Thread 1816132528 (LWP 23171)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x6c3ff288 in ?? () No symbol table info available. #2 0x06ec61e1 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 31 (Thread 1844444080 (LWP 23169)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x6deff288 in ?? () No symbol table info available. #2 0x06ec61fb in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 30 (Thread 1877937072 (LWP 23166)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x6fef0288 in ?? () No symbol table info available. #2 0x06ec6202 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 29 (Thread 1882135472 (LWP 23165)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x702f1288 in ?? () No symbol table info available. #2 0x06ec61ee in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 28 (Thread 1887386544 (LWP 23164)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x707f3288 in ?? () No symbol table info available. #2 0x06ec61e2 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 27 (Thread 1910475696 (LWP 23163)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x71df8288 in ?? () No symbol table info available. #2 0x06ec61f6 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 26 (Thread 1914674096 (LWP 23162)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x721f9288 in ?? () No symbol table info available. #2 0x06ec61fd in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 25 (Thread 1937763248 (LWP 23161)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x737fe288 in ?? () No symbol table info available. #2 0x06ec620e in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 24 (Thread 1941961648 (LWP 23160)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x73bff288 in ?? () No symbol table info available. #2 0x06ec61f8 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 23 (Thread 2092932016 (LWP 23154)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x7cbf9288 in ?? () No symbol table info available. #2 0x06ec61e8 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 22 (Thread 2097130416 (LWP 23153)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x7cffa288 in ?? () No symbol table info available. #2 0x06ec61e6 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 21 (Thread 2109721520 (LWP 23152)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x7dbfc288 in ?? () No symbol table info available. #2 0x06ec6205 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 20 (Thread 2114972592 (LWP 23151)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x7e0fe288 in ?? () No symbol table info available. #2 0x06ec6211 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 19 (Thread 2119170992 (LWP 23150)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x7e4ff288 in ?? () No symbol table info available. #2 0x06ec6206 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 18 (Thread -2056344656 (LWP 23149)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x856ea288 in ?? () No symbol table info available. #2 0x06ec61db in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 17 (Thread -2052146256 (LWP 23148)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x85aeb288 in ?? () No symbol table info available. #2 0x06ec61ec in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 16 (Thread -2047947856 (LWP 23147)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x85eec288 in ?? () No symbol table info available. #2 0x06ec6214 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 15 (Thread -2043749456 (LWP 23146)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x862ed288 in ?? () No symbol table info available. #2 0x06ec61f4 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 14 (Thread -2039551056 (LWP 23145)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x866ee288 in ?? () No symbol table info available. #2 0x06ec6201 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 13 (Thread -2035352656 (LWP 23144)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x86aef288 in ?? () No symbol table info available. #2 0x06ec61f0 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 12 (Thread -2031154256 (LWP 23143)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x86ef0288 in ?? () No symbol table info available. #2 0x06ec6208 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 11 (Thread -2017510480 (LWP 23142)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x87bf3288 in ?? () No symbol table info available. #2 0x06ec61ff in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 10 (Thread -2013312080 (LWP 23141)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x87ff4288 in ?? () No symbol table info available. #2 0x06ec61ea in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 9 (Thread -1945388112 (LWP 23114)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x8c0bb458 in ?? () No symbol table info available. #2 0x00002000 in ?? () No symbol table info available. #3 0xb79d5008 in ?? () No symbol table info available. #4 0xb7b35b0e in epoll_wait () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. #5 0x08070647 in slapd_daemon_task (ptr=0x0) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/daemon.c:2291 i = 0 revents = (struct epoll_event *) 0xb79d5008 tv = {tv_sec = 9, tv_usec = 0} rtask = <value optimized out> ns = 1 at = 0 now = 1232127902 tvp = (struct timeval *) 0x8c0bb444 cat = {tv_sec = 1232127911, tv_usec = 0} l = 4 last_idle_check = 0 ebadf = 0 #6 0xb7ba0240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 No symbol table info available. #7 0xb7b3549e in clone () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. Thread 8 (Thread -1949586512 (LWP 23115)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x8bcba288 in ?? () No symbol table info available. #2 0x06ec61d9 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 7 (Thread -1953784912 (LWP 23116)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x8b8b9288 in ?? () No symbol table info available. #2 0x06ec6212 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 6 (Thread -1957983312 (LWP 23117)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x8b4b8288 in ?? () No symbol table info available. #2 0x06ec61dd in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 5 (Thread -1962181712 (LWP 23118)): #0 0xb7ba2024 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0 No symbol table info available. #1 0xb7f0a51d in ldap_pvt_thread_mutex_lock (mutex=0x20) at /tmp/buildd/openldap-2.4.14~cvs20090113/libraries/libldap_r/thr_posix.c:296 No locals. #2 0xb76a4535 in bdb_cache_delete_internal (cache=0x5a4e, e=0x771938f8, decr=0) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/back-bdb/cache.c:1320 rc = -1962975752 #3 0xb76a4df8 in bdb_cache_lru_purge (bdb=0x823f7e0) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/back-bdb/cache.c:741 lock = {off = 0, ndx = 357, gen = 1229360, mode = DB_LOCK_WRITE} lockp = (DB_LOCK *) 0x8aff5e2c elru = (EntryInfo *) 0x771938f8 elnext = (EntryInfo *) 0x745e59c0 count = 1 eimax = 20000 #4 0xb76a5858 in bdb_cache_find_id (op=0x746c3468, tid=0x8a909ec8, id=137758, eip=0x8b0b60ec, flag=0, lock=0x8b0b6044) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/back-bdb/cache.c:1001 bdb = (struct bdb_info *) 0x823f7e0 ep = (Entry *) 0x0 rc = 0 load = 1 ei = {bei_parent = 0x0, bei_id = 137758, bei_lockpad = 0, bei_state = 0, bei_finders = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0} #5 0xb76983b5 in bdb_search (op=0x746c3468, rs=0x8b0b71e8) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/back-bdb/search.c:705 scopeok = 1 bdb = (struct bdb_info *) 0x823f7e0 id = 137758 cursor = 1 lastid = 4294967295 candidates = {1, 137758, 1117527, 1117527, 566155, 566157, 566550, 566680, 566820, 566837, 566847, 566997, 567006, 567010, 567011, 567012, 567013, 567014, 567016, 567017, 567018, 567019, 567020, 567021, 567022, 567023, 567024, 567025, 567026, 567027, 567028, 567029, 567030, 567031, 567032, 567033, 567034, 567035, 567036, 567037, 567038, 567039, 567040, 567041, 567042, 567043, 567044, 567045, 567046, 567047, 567048, 567049, 567050, 567051, 567052, 567053, 567054, 567055, 567056, 567057, 567058, 567059, 567060, 567061, 567062, 567063, 567064, 567065, 567066, 567067, 567068, 567069, 567070, 567071, 567072, 567073, 567074, 567075, 567076, 567077, 567078, 567079, 567080, 567081, 567082, 567083, 567084, 567085, 567086, 567087, 567088, 567089, 567090, 567091, 567092, 567093, 567094, 567095, 567096, 567097, 567098, 567099, 567100, 567101, 567102, 567103, 567104, 567105, 567106, 567107, 567108, 567109, 567110, 567111, 567112, 567113, 567114, 567115, 567116, 567117, 567118, 567119, 567120, 567121, 567122, 567123, 567124, 567125, 567126, 567127, 567128, 567129, 567130, 567131, 567132, 567133, 567134, 567135, 567136, 567137, 567138, 567139, 567140, 567141, 567142, 567143, 567144, 567145, 567146, 567147, 567148, 567149, 567150, 567151, 567152, 567153, 567154, 567155, 567156, 567157, 567158, 567159, 567160, 567161, 567162, 567163, 567164, 567165, 567166, 567167, 567168, 567169, 567170, 567171, 567172, 567173, 567174, 567175, 567176, 567177, 567178, 567179, 567180, 567181, 567182, 567183, 567184, 567185, 567186, 567187, 567188, 567189, 567190, 567191, 567192, 567193, 567194, 567195, 567196, 567197...} scopes = {0 <repeats 63526 times>, 2332770456, 10477568, 0, 3081983306, 0, 0, 0, 0, 10477568, 2332770520, 8192, 2332770584, 2332770520, 3082442676, 8192, 3085743694, 30, 2332770584, 8192, 1, 1831694433, 1702130529, 774975602, 779382377, 2332770584, 8192, 8192, 3085879208, 2325686600, 136914872, 2332778792, 3085542826, 136914872, 2325686600, 2332770584, 8192, 2332778776, 0, 0, 0, 0, 0, 2332770584, 0 <repeats 1006 times>, 2332774632, 2050, 4, 3082443123, 0, 2332774652, 3085940968, 4461, 3075670352, 2332774664, 3085930188, 4461, 4, 2050, 0, 3085940968, 1981826248, 2332778808, 3085930468, 4461, 1, 0 <repeats 248 times>, 1873635787, 2332777972, 134969792, 2332777972, 2332775720, 134969835, 2326484332, 136294584, 0, 0, 0, 136295264, 2332775752, 135218913, 2332777972, 136295248, 0, 2332777972, 2332778100, 2332778104, 2332775784, 134965375, 136097816, 2332777972, 134969792, 0, 2326484308, 2326484308, 2332778008, 134959773, 2332777972, 59, 1, 0, 0, 0, 0, 0, 0, 2326484332, 1873635787, 2332778132, 134969792, 2332778132, 2332775880, 134969835, 2326484228, 136294584, 0, 0, 0, 136295264, 2332775912, 135218913, 2332778132, 136295248, 0, 2332778132, 2332778260, 2332778264, 2332775944, 134965375, 136097816, 2332778132, 134969792, 0, 2326484204, 2326484204, 2332778168, 134959773, 2332778132, 59, 1, 0, 0, 0, 0, 0, 0, 2326484228, 0, 2326484229, 0, 0, 0, 0, 0, 1, 136295072, 2332778324, 134969792, 0, 1705863627, 2332778340, 134969792, 2332778340, 2332776088, 134969835, 173350243, 136403296, 0, 135218913, 2332778324, 136404184, 2332776120, 135218913...} e = (Entry *) 0x8c585cfc base = {e_id = 1, e_name = {bv_len = 3085940968, bv_val = 0x67e3cca8 "\002"}, e_nname = {bv_len = 10, bv_val = 0xab3a280 "o=example"}, e_attrs = 0xb7efb8e8, e_ocflags = 1742982312, e_bv = {bv_len = 2332778604, bv_val = 0x8b0b6018 "\210`\v\213\224'ï·šÌãgl`\v\213"}, e_private = 0x8298ba0} e_root = (Entry *) 0x8c55000c matched = (Entry *) 0x0 ei = (EntryInfo *) 0x75f14cc0 realbase = {bv_len = 10, bv_val = 0xab3a280 "o=example"} mask = <value optimized out> manageDSAit = 0 tentries = 1 nentries = 1 idflag = 0 lock = {off = 296712, ndx = 263, gen = 1126223, mode = DB_LOCK_READ} opinfo = (struct bdb_op_info *) 0x0 ltid = (DB_TXN *) 0x8a909ec8 oex = (OpExtra *) 0x0 #6 0x080760d6 in fe_op_search (op=0x746c3468, rs=0x8b0b71e8) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/search.c:366 defref = <value optimized out> bd = (BackendDB *) 0x815bdc0 #7 0x080768b7 in do_search (op=0x746c3468, rs=0x8b0b71e8) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/search.c:217 base = {bv_len = 10, bv_val = 0xa355d30 "o=example"} siz = 10 i = 2332783240 #8 0x08073b11 in connection_operation (ctx=0x8b0b72c8, arg_v=0x746c3468) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/connection.c:1090 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 *) 0xb7460928 memctx = (void *) 0x82959f8 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #9 0x0807412e in connection_read_thread (ctx=0x8b0b72c8, argv=0x834) at /tmp/buildd/openldap-2.4.14~cvs20090113/servers/slapd/connection.c:1216 s = <value optimized out> #10 0xb7f09b66 in ldap_int_thread_pool_wrapper (xpool=0x81e7ba8) at /tmp/buildd/openldap-2.4.14~cvs20090113/libraries/libldap_r/tpool.c:663 task = (ldap_int_thread_task_t *) 0x786e9858 work_list = <value optimized out> ctx = {ltu_id = 2332785584, ltu_key = {{ltk_key = 0x80c87e0, ltk_data = 0x82959f8, ltk_free = 0x80c8320 <slap_sl_mem_destroy>}, {ltk_key = 0x82927b8, ltk_data = 0x8a908680, ltk_free = 0xb76a3c40 <bdb_reader_free>}, {ltk_key = 0x8072c80, ltk_data = 0x8a909dd8, ltk_free = 0x8072d40 <conn_counter_destroy>}, {ltk_key = 0x8294348, ltk_data = 0x8a909ec8, ltk_free = 0xb76a3c40 <bdb_reader_free>}, {ltk_key = 0x8087450, ltk_data = 0x66f7d6b0, ltk_free = 0x8087250 <slap_op_q_destroy>}, {ltk_key = 0xb76965b0, ltk_data = 0x88efb008, ltk_free = 0xb7696690 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x9a758b0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = <value optimized out> keyslot = 737 hash = 6459105 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #11 0xb7ba0240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 No symbol table info available. #12 0xb7b3549e in clone () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. Thread 4 (Thread -1997558864 (LWP 23138)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x88efa288 in ?? () No symbol table info available. #2 0x06ec620c in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 3 (Thread -2002809936 (LWP 23139)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x889f8288 in ?? () No symbol table info available. #2 0x06ec620a in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 2 (Thread -2008061008 (LWP 23140)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0x884f6288 in ?? () No symbol table info available. #2 0x06ec61e4 in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. Thread 1 (Thread -1214015808 (LWP 23112)): #0 0xb7f47410 in ?? () No symbol table info available. #1 0xbfe16a08 in ?? () No symbol table info available. #2 0x00005a4a in ?? () No symbol table info available. #3 0x00000000 in ?? () No symbol table info available. #0 0xb7ba2024 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0 -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

Re: (ITS#5890) N-Way Multi-Master replication - delete problem
by hyc＠symas.com 16 Jan '09

16 Jan '09

joao.alfredo(a)gmail.com wrote: > ------=_Part_90349_22260400.1232120449784 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > Content-Disposition: inline > > Hello, > > but the problem persist if you do not use sessionlog (that is my case), if > you do more then 1000 deletes, the problem will happen too. > > SessionLog is a in-memory log, so, if you clean out the memory (with a > re-start) the problem will happen. > > This could be a work-around, but do not solve the problem. Correct. Since this ITS appears to be a dup of #5843 and all of the relevant info is also there, this ITS will be closed. Followups should go to #5843. -- -- 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#5894) test039 fails: ldap_back_conn_delete: Assertion
by hyc＠symas.com 16 Jan '09

16 Jan '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.100.169) > > > lt-slapd: bind.c:157: ldap_back_conn_delete: Assertion `!(*(&((lc))->lc_lcflags) > & (((0x00000020U))))' failed. I'm not seeing that here. Ran into a couple other problems though, fixed now in HEAD. Please re-test... -- -- 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#5890) N-Way Multi-Master replication - delete problem
by joao.alfredo＠gmail.com 16 Jan '09

16 Jan '09

------=_Part_90349_22260400.1232120449784 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, but the problem persist if you do not use sessionlog (that is my case), if you do more then 1000 deletes, the problem will happen too. SessionLog is a in-memory log, so, if you clean out the memory (with a re-start) the problem will happen. This could be a work-around, but do not solve the problem. Best regards, Joao Alfredo. On Fri, Jan 16, 2009 at 1:11 PM, Andreas Schoe <andi(a)gfz-potsdam.de> wrote: > Hello, > > at the documentation center. In section the "N-Way Multi-Master > replication" there is a hint that you have to configure > syncprov-sessionlog <size>. > This option is used by file based configuration. > > In dynamic configuration 'olcSessionlog' is described as follows: > ( OLcfgOvAt:1.2 NAME 'olcSpSessionlog' DESC 'Session log size in ops' > SYNTAX OMsInteger SINGLE-VALUE ) > > Best regards > Andreas > > > Adrien Futschik schrieb: > > Thanks a lot ! > > > > This seems to be working fine. Is this documented anywhere ? > > I never saw that option before. > > > > Adrien Futschik > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Hello, > > > > add olcSpSessionlog to syncprov. I choose 1000 as value. > > > > Best regards > > Andreas > > > -- > > Andreas Schoe > > Abteilung: Daten- und Rechenzentrum (DRZ) > Tel.: +49 (0)331/288-1719 > Fax: +49 (0)331/288-1701 > Email: andi(a)gfz-potsdam.de > ___________________________________ > > Helmholtz-Zentrum Potsdam > Deutsches GeoForschungsZentrum - GFZ > Stiftung des =F6ff. Rechts Land Brandenburg > Telegrafenberg, D-14473 Potsdam > > ------=_Part_90349_22260400.1232120449784 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, but the problem persist if you do not use sessionlog (that is= my case), if you do more then 1000 deletes, the problem will happen too.<b= r> SessionLog is a in-memory log, so, if you clean out the memory (with = a re-start) the problem will happen. This could be a work-around, but do not solve the problem. Best = regards, Joao Alfredo. <div class=3D"gmail_quote">On Fri,= Jan 16, 2009 at 1:11 PM, Andreas Schoe <<a href=3D"ma= ilto:andi@gfz-potsdam.de">andi(a)gfz-potsdam.de</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hello, at the documentation center. In section the "N-Way Multi-Master replication" there is a hint that you have to configure syncprov-sessionlog <size>. This option is used by file based configuration. In dynamic configuration 'olcSessionlog' is described as follows:<b= r> ( OLcfgOvAt:1.2 NAME 'olcSpSessionlog' DESC 'Session log size i= n ops' SYNTAX OMsInteger SINGLE-VALUE ) Best regards Andreas Adrien Futschik schrieb: <div><div></div><div class=3D"Wj3C7c">> Thanks a lot ! > > This seems to be working fine. Is this documented anywhere ? > I never saw that option before. > > Adrien Futschik > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >  Hello, > >  add olcSpSessionlog to syncprov. I choose 1000 as value. > >  Best regards >  Andreas > </div></div>-- Andreas Schoe Abteilung: Daten- und Rechenzentrum (DRZ) Tel.: +49 (0)331/288-1719 Fax: +49 (0)331/288-1701 Email: <a href=3D"mailto:andi@gfz-potsdam.de">andi(a)gfz-potsdam.de</a> ___________________________________ Helmholtz-Zentrum Potsdam Deutsches GeoForschungsZentrum - GFZ Stiftung des =F6ff. Rechts Land Brandenburg Telegrafenberg, D-14473 Potsdam </blockquote></div> ------=_Part_90349_22260400.1232120449784--

1 0

Re: (ITS#5890) N-Way Multi-Master replication - delete problem
by andi＠gfz-potsdam.de 16 Jan '09

16 Jan '09

Hello, at the documentation center. In section the "N-Way Multi-Master replication" there is a hint that you have to configure syncprov-sessionlog <size>. This option is used by file based configuration. In dynamic configuration 'olcSessionlog' is described as follows: ( OLcfgOvAt:1.2 NAME 'olcSpSessionlog' DESC 'Session log size in ops' SYNTAX OMsInteger SINGLE-VALUE ) Best regards Andreas Adrien Futschik schrieb: > Thanks a lot ! > > This seems to be working fine. Is this documented anywhere ? > I never saw that option before. > > Adrien Futschik > > ======================================== > > Hello, > > add olcSpSessionlog to syncprov. I choose 1000 as value. > > Best regards > Andreas > -- Andreas Schoe Abteilung: Daten- und Rechenzentrum (DRZ) Tel.: +49 (0)331/288-1719 Fax: +49 (0)331/288-1701 Email: andi(a)gfz-potsdam.de ___________________________________ Helmholtz-Zentrum Potsdam Deutsches GeoForschungsZentrum - GFZ Stiftung des öff. Rechts Land Brandenburg Telegrafenberg, D-14473 Potsdam

1 0

Re (ITS#5843) N-way Multi-master doesn't replicate deletes under certain circumstances.
by adrien.futschik＠atosorigin.com 16 Jan '09

16 Jan '09

Thanks a lot ! This seems to be working fine. Is this documented anywhere ? I never saw that option before. Adrien Futschik ======================================== Hello, add olcSpSessionlog to syncprov. I choose 1000 as value. Best regards Andreas

1 0

Re: Re: (ITS#5890) N-Way Multi-Master replication - delete problem
by adrien.futschik＠atosorigin.com 16 Jan '09

16 Jan '09

Thanks a lot ! This seems to be working fine. Is this documented anywhere ? I never saw that option before. Adrien Futschik ======================================== Hello, add olcSpSessionlog to syncprov. I choose 1000 as value. Best regards Andreas

1 0

(ITS#5894) test039 fails: ldap_back_conn_delete: Assertion
by michael＠stroeder.com 16 Jan '09

16 Jan '09

Full_Name: Michael Ströder Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.100.169) lt-slapd: bind.c:157: ldap_back_conn_delete: Assertion `!(*(&((lc))->lc_lcflags) & (((0x00000020U))))' failed.

1 0

(ITS#5893) test scripts should stop immediately if slapd crashed
by michael＠stroeder.com 16 Jan '09

16 Jan '09

Full_Name: karlsruhe Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.100.169) Currently test039-glue-ldap-concurrency fails with a lot of these messages (see below). Maybe the test scripts could be modified to detect this situation and stop immediately. slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=1600: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=1600 - Bind done 1000 in 2.987727 seconds. m

1 0

Re:%20(ITS#5843)%20Multi-master%20doesn't%20replicate%20deletes%20under%20certain%20circumstances.
by adrien.futschik＠atosorigin.com 16 Jan '09

16 Jan '09

Hello, I might be facing the same problem. Here is what I did : I'm testing N-Way Multi-Master replication with OpenLDAP 2.4.11 & 2.4.13 I have setup 2 Masters (m1 & m2) starting form test050-syncrepl-multimaster and modifying it. Every thing seems to work fine except deleting entries. Let me explain. case 1 : . When I add an entry on m1 it is successfully replicated on m2. . When I try to delete this entry on m1, it is successfully removed from m1, but not replicated on m2. . When, I try to delete this entry on m2, it is successfully removed from m2 & m1. case 2 : . When I add an entry on m2 it is successfully replicated on m1. . When I try to delete this entry on m2, it is successfully removed from m2, but not replicated on m1. . When, I try to delete this entry on m1, it is successfully removed from m1 & m2. I don't have the same problem when I delete an attribute or update an entry. Here is how I have setup-ed my masters : m1 -config : dn: cn=config objectClass: olcGlobal cn: config olcServerID: 1 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW:< file://$CONFIGPWF m2 - config : dn: cn=config objectClass: olcGlobal cn: config olcServerID: 2 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW:< file://$CONFIGPWF m1 - syncprov : dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 $URI1 olcServerID: 2 $URI2 dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 - add: olcMirrorMode olcMirrorMode: TRUE m2 - syncrepl : dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 - add: olcMirrorMode olcMirrorMode: TRUE m1 - schema : include: file://$ABS_SCHEMADIR/core.ldif include: file://$ABS_SCHEMADIR/cosine.ldif include: file://$ABS_SCHEMADIR/inetorgperson.ldif include: file://$ABS_SCHEMADIR/openldap.ldif include: file://$ABS_SCHEMADIR/nis.ldif m1 - backend : dn: olcDatabase={1}$BACKEND,cn=config objectClass: olcDatabaseConfig objectClass: olc${BACKEND}Config olcDatabase: {1}$BACKEND olcSuffix: $BASEDN olcDbDirectory: ./openldap-data olcRootDN: $MANAGERDN olcRootPW: $PASSWD olcSyncRepl: rid=004 provider=$URI1 binddn="$MANAGERDN" bindmethod=simple credentials=$PASSWD searchbase="$BASEDN" type=refreshOnly interval=$INTERVAL retry="5 5 300 5" timeout=3 olcSyncRepl: rid=005 provider=$URI2 binddn="$MANAGERDN" bindmethod=simple credentials=$PASSWD searchbase="$BASEDN" type=refreshOnly interval=$INTERVAL retry="5 5 300 5" timeout=3 olcMirrorMode: TRUE dn: olcOverlay=syncprov,olcDatabase={1}${BACKEND},cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov Did I miss something ? Adrien Futschik

1 0

(ITS#5892) slapadd doesn't fail on invalid include statements
by aredridel＠nbtsc.org 15 Jan '09

15 Jan '09

Full_Name: Aria Stewart Version: 2.4.13 OS: PLD Linux (Th) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:8935:7:21b:fcff:fe77:1757) An ldif file with include statements in the form of: include: /filename rather than include: file:///filename silently fail. Slapadd stops at that point, but does not print an error message.

1 0

(ITS#5891) Update slapdadd (and related tools) -n option
by quanah＠OpenLDAP.org 15 Jan '09

15 Jan '09

Full_Name: Quanah Gibson-Mount Version: RE24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) With the new cn=config backend, people can use slap* tools to populate cn=config. However, the man page fails to note that you need to use -n 0 to select the config database. The current description has: Add entries to the dbnum−th database listed in the configuration file." However, since no config database exists yet, there is no configuration file (or db yet).

1 0

(ITS#5890) N-Way Multi-Master replication - delete problem
by adrien.futschik＠atosorigin.com 15 Jan '09

15 Jan '09

Full_Name: Adrien Futschik Version: 2.4.13 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.54.193.59) I'm testing N-Way Multi-Master replication with OpenLDAP 2.4.11 & 2.4.13 I have setup 2 Masters (m1 & m2) starting form test050-syncrepl-multimaster and modifying it. Every thing seems to work fine except deleting entries. Let me explain. case 1 : . When I add an entry on m1 it is successfully replicated on m2. . When I try to delete this entry on m1, it is successfully removed from m1, but not replicated on m2. . When, I try to delete this entry on m2, it is successfully removed from m2 & m1. case 2 : . When I add an entry on m2 it is successfully replicated on m1. . When I try to delete this entry on m2, it is successfully removed from m2, but not replicated on m1. . When, I try to delete this entry on m1, it is successfully removed from m1 & m2. I don't have the same problem when I delete an attribute or update an entry. Here is how I have setup-ed my masters : m1 -config : dn: cn=config objectClass: olcGlobal cn: config olcServerID: 1 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW:< file://$CONFIGPWF m2 - config : dn: cn=config objectClass: olcGlobal cn: config olcServerID: 2 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW:< file://$CONFIGPWF m1 - syncprov : dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 $URI1 olcServerID: 2 $URI2 dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 - add: olcMirrorMode olcMirrorMode: TRUE m2 - syncrepl : dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 - add: olcMirrorMode olcMirrorMode: TRUE m1 - schema : include: file://$ABS_SCHEMADIR/core.ldif include: file://$ABS_SCHEMADIR/cosine.ldif include: file://$ABS_SCHEMADIR/inetorgperson.ldif include: file://$ABS_SCHEMADIR/openldap.ldif include: file://$ABS_SCHEMADIR/nis.ldif m1 - backend : dn: olcDatabase={1}$BACKEND,cn=config objectClass: olcDatabaseConfig objectClass: olc${BACKEND}Config olcDatabase: {1}$BACKEND olcSuffix: $BASEDN olcDbDirectory: ./openldap-data olcRootDN: $MANAGERDN olcRootPW: $PASSWD olcSyncRepl: rid=004 provider=$URI1 binddn="$MANAGERDN" bindmethod=simple credentials=$PASSWD searchbase="$BASEDN" type=refreshOnly interval=$INTERVAL retry="5 5 300 5" timeout=3 olcSyncRepl: rid=005 provider=$URI2 binddn="$MANAGERDN" bindmethod=simple credentials=$PASSWD searchbase="$BASEDN" type=refreshOnly interval=$INTERVAL retry="5 5 300 5" timeout=3 olcMirrorMode: TRUE dn: olcOverlay=syncprov,olcDatabase={1}${BACKEND},cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov Did I miss something ? Adrien Futschik

1 0

(ITS#5889) [PATCH] Sending dereference field when retrying connection in meta backend
by jorge.perez＠adaptia.net 15 Jan '09

15 Jan '09

Full_Name: Jorge Perez Burgos Version: 2.4.11 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/jorge-perez-burgos-090115.ext Submission from: (NULL) (194.237.142.6) When we have two slapds with a established meta connection between them and the connection is reset, for example by a router, the next search query will always be send with never in dereferencing. Steps to reproduce: - Established a meta connection between 2 slapds - Reset the connection, for example with cutter - Send a search dereferencing with something different to never. - See the results are no dereferenced. Patch attached.

1 0

(ITS#5888) MSVC 9.0 build issue
by kurt＠OpenLDAP.org 14 Jan '09

14 Jan '09

Full_Name: Kurt Zeilenga Version: HEAD OS: Windows Server 2008 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2002:4b8d:e980:0:217:f2ff:fed0:27f1) Submitted by: kurt The current configure script checks for _vsnprintf and then defines a macro #define vsnprintf _vsnprintf. But the system has a vsnprintf. This causes a clash in <stdio.h> which defines both vsnprintf and _vsnprintf. configure.in and include/portable.in need a bit of work to detected this situation....

1 0

Re: (ITS#5887) Fix GnuTLS support for TLS_CIPHER_SUITE
by simon＠josefsson.org 14 Jan '09

14 Jan '09

Quanah Gibson-Mount <quanah(a)zimbra.com> writes: > --On Wednesday, January 14, 2009 7:29 PM +0000 hyc(a)symas.com wrote: > >> quanah(a)OpenLDAP.org wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.4.13 >>> OS: NA >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (75.111.29.239) >>> >>> >>> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510346 >>> >>> Summary from Simon Josefsson: >>> >>> A proper fix requires co-ordination with the OpenLDAP people. Either >>> they 1) remove all strange code for parsing ciphers for GnuTLS and only >>> use gnutls_priority_set_direct on the TLS_CIPHER_SUITE string, or 2) >>> they introduce a new configuration keyword TLS_PRIORITY that is is sent >>> to GnuTLS's priority functions. Given that TLS_CIPHER_SUITE accepts >>> OpenSSL strings like 'HIGH:+SSLv2' I believe that matches GnuTLS >>> priority strings, so I would recommend 1). And improve the >>> documentation to point at, e.g., gnutls_priority_init(3) or the GnuTLS >>> manual in the OpenLDAP documentation. >> >> Sounds like we should do (1). There was no such API in GnuTLS when our >> support was written, which is why we had to go to the trouble of parsing >> the cipher suites ourselves. I'm fine with ripping that all out, if >> someone will tell us what minimum version of GnuTLS provides the new API. > > Simon? The APIs were released as stable for v2.2.0 on 2007-12-14. Perhaps you could have an autoconf test for gnutls_priority_set_direct and only enable the new code conditionally. /Simon

1 0

Re: (ITS#5887) Fix GnuTLS support for TLS_CIPHER_SUITE
by quanah＠zimbra.com 14 Jan '09

14 Jan '09

--On Wednesday, January 14, 2009 7:29 PM +0000 hyc(a)symas.com wrote: > quanah(a)OpenLDAP.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.13 >> OS: NA >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.29.239) >> >> >> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510346 >> >> Summary from Simon Josefsson: >> >> A proper fix requires co-ordination with the OpenLDAP people. Either >> they 1) remove all strange code for parsing ciphers for GnuTLS and only >> use gnutls_priority_set_direct on the TLS_CIPHER_SUITE string, or 2) >> they introduce a new configuration keyword TLS_PRIORITY that is is sent >> to GnuTLS's priority functions. Given that TLS_CIPHER_SUITE accepts >> OpenSSL strings like 'HIGH:+SSLv2' I believe that matches GnuTLS >> priority strings, so I would recommend 1). And improve the >> documentation to point at, e.g., gnutls_priority_init(3) or the GnuTLS >> manual in the OpenLDAP documentation. > > Sounds like we should do (1). There was no such API in GnuTLS when our > support was written, which is why we had to go to the trouble of parsing > the cipher suites ourselves. I'm fine with ripping that all out, if > someone will tell us what minimum version of GnuTLS provides the new API. Simon? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5887) Fix GnuTLS support for TLS_CIPHER_SUITE
by hyc＠symas.com 14 Jan '09

14 Jan '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.13 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510346 > > Summary from Simon Josefsson: > > A proper fix requires co-ordination with the OpenLDAP people. Either > they 1) remove all strange code for parsing ciphers for GnuTLS and only > use gnutls_priority_set_direct on the TLS_CIPHER_SUITE string, or 2) > they introduce a new configuration keyword TLS_PRIORITY that is is sent > to GnuTLS's priority functions. Given that TLS_CIPHER_SUITE accepts > OpenSSL strings like 'HIGH:+SSLv2' I believe that matches GnuTLS > priority strings, so I would recommend 1). And improve the > documentation to point at, e.g., gnutls_priority_init(3) or the GnuTLS > manual in the OpenLDAP documentation. Sounds like we should do (1). There was no such API in GnuTLS when our support was written, which is why we had to go to the trouble of parsing the cipher suites ourselves. I'm fine with ripping that all out, if someone will tell us what minimum version of GnuTLS provides the new API. -- -- 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#5853) LDAP search crashes when chasing multiple referrals
by jsafrane＠redhat.com 14 Jan '09

14 Jan '09

This is a multi-part message in MIME format. --------------090400040509090303060604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ando(a)sys-net.it wrote: > jsafrane(a)redhat.com wrote: > >> Following ldapsearch crashes when referral chasing is enabled in very unusual >> environment with many AD servers referring to each other (I had to increase >> refhoplimit to chase all the referrals). > > Thanks for the detailed report. However, IMHO, automatic referral > chasing Is Broken. Clients should explicitly chase them, possibly > providing some interactive means for rebinding. This is what is > currently done, for example, by slapd when using slapo-chain(5), and > what should be done by proxy backends as well. nss_ldap does not have an option to chase referrals, it depends on ldap libraries to do the dirty job. I think that referral chasing in OpenLDAP libraries works pretty well apart my crash. Is there anything I am not aware of? Instead adding new features to nss_ldap, it would be better to fix OpenLDAP, more applications would benefit from that. I tried to work around the crash, see patch attached (apply to current 2.4 branch in CVS). I was not able to prevent deleting connections during referral chasing (I admit I got lost in the code and various code paths). So I added very simple mechanism to detect possibly freed connection and restart the loop in wait4msg(). It seems to help in my scenario. Jan --------------090400040509090303060604 Content-Type: text/plain; name="openldap-2.4-refer-crash.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="openldap-2.4-refer-crash.patch" Index: libraries/libldap/ldap-int.h =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/libldap/ldap-int.h,v retrieving revision 1.168.2.9 diff -u -r1.168.2.9 ldap-int.h --- libraries/libldap/ldap-int.h 8 Nov 2008 00:14:45 -0000 1.168.2.9 +++ libraries/libldap/ldap-int.h 14 Jan 2009 14:54:09 -0000 @@ -401,6 +401,7 @@ LDAPConn *ld_defconn; /* default connection */ LDAPConn *ld_conns; /* list of server connections */ + int ld_conns_version; /* unique id tracking deletions in ld_conns list */ void *ld_selectinfo; /* platform specifics for select */ }; #define LDAP_VALID(ld) ( (ld)->ld_valid == LDAP_VALID_SESSION ) Index: libraries/libldap/request.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/libldap/request.c,v retrieving revision 1.125.2.12 diff -u -r1.125.2.12 request.c --- libraries/libldap/request.c 8 Nov 2008 01:15:17 -0000 1.125.2.12 +++ libraries/libldap/request.c 14 Jan 2009 14:54:09 -0000 @@ -697,6 +698,7 @@ } prevlc = tmplc; } + ld->ld_conns_version++; #ifdef LDAP_R_COMPILE ldap_pvt_thread_mutex_unlock( &ld->ld_conn_mutex ); #endif Index: libraries/libldap/result.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/libldap/result.c,v retrieving revision 1.124.2.14 diff -u -r1.124.2.14 result.c --- libraries/libldap/result.c 10 Nov 2008 17:39:16 -0000 1.124.2.14 +++ libraries/libldap/result.c 14 Jan 2009 14:54:09 -0000 @@ -396,6 +396,7 @@ if ( lc->lconn_status == LDAP_CONNST_CONNECTED && ldap_is_read_ready( ld, lc->lconn_sb ) ) { + int version = ld->ld_conns_version; #ifdef LDAP_R_COMPILE ldap_pvt_thread_mutex_unlock( &ld->ld_conn_mutex ); #endif @@ -403,12 +404,12 @@ #ifdef LDAP_R_COMPILE ldap_pvt_thread_mutex_lock( &ld->ld_conn_mutex ); #endif - if ( lc == NULL ) { + if ( version != ld->ld_conns_version || lc == NULL ) { /* if lc gets free()'d, * there's no guarantee - * lc->lconn_next is still + * lc or lc->lconn_next is still * sane; better restart - * (ITS#4405) */ + * (ITS#4405, ITS#5853) */ lc = ld->ld_conns; /* don't get to next conn! */ --------------090400040509090303060604--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs