openldap-bugs February 2012

openldap-bugs@openldap.org

33 participants
146 discussions

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by mattias＠centaurix.com 03 Feb '12

03 Feb '12

On Fri, 03 Feb 2012 20:26:01 +0100, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, January 31, 2012 10:41 AM +0000 mattias(a)centaurix.com > wrote: > >> On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc(a)symas.com> wrote: >> >>> Mattias Andersson wrote: >>>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote: >>>> >>>>> Please provide a full gdb backtrace from the assertion failure. I've >>>>> reproduced this configuration locally but see no crash using >>>>> ldapsearch. >>>>> I don't have the Softerra browser. >>>> >>>> Ok, see attachment. The problem is not reproducible with ldapsearch. >>> >>> Please see if the attached patch alters the behavior. Thanks. >> >> I'm getting an error that MozNSS is not found when I run ./configure. >> >> Mattias > > Hi Mattias, > > Any update? We would like to get a fix for this into OpenLDAP 2.4.29 if > possible. Ok, I didn't apply the patch yet, but now I'm getting a different error than before (before I was using OpenLDAP 2.4.25 from the Ubuntu package repository): cornelian build_unix # /usr/local/libexec/slapd -d 256 -f /etc/ldap/slapd.conf 4f2c5a69 @(#) $OpenLDAP: slapd 2.4.28 (Feb 1 2012 02:31:50) $ root@cornelian:/root/openldap/openldap-2.4.28/servers/slapd 4f2c5a69 hdb_db_open: database "dc=rss,dc=chalmers,dc=se": unclean shutdown detected; attempting recovery. 4f2c5a69 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable 4f2c5a69 slapd starting 4f2c5ac2 conn=1000 fd=12 ACCEPT from IP=127.0.0.1:39354 (IP=0.0.0.0:389) 4f2c5ac2 conn=1000 op=0 BIND dn="" method=128 4f2c5ac2 conn=1000 op=0 RESULT tag=97 err=0 text= 4f2c5ac2 conn=1000 op=1 SRCH base="dc=chalmers,dc=se" scope=2 deref=0 filter="(objectClass=*)" 4f2c5ac2 conn=1000 op=1 SRCH attr=1.1 /usr/local/libexec/slapd: symbol lookup error: /usr/local/libexec/openldap/back_ldap-2.4.so.2: undefined symbol: ldap_get_message_ber This error also happens with ldapsearch. Mattias

1 0

Re: ~*~ [spam] Re: (ITS#7143) Assertion error (crash); using relay backend and translucent ove
by mattias＠centaurix.com 03 Feb '12

03 Feb '12

On Fri, 03 Feb 2012 22:24:36 +0100, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Friday, February 03, 2012 10:19 PM +0100 Mattias Andersson > <mattias(a)centaurix.com> wrote: > >> I'm having some problems with the BDB library: >> >> 4f2c4dd3 bdb_back_initialize: BDB library version mismatch: expected >> Berkeley DB 5.1.29: (October 25, 2011), got Berkeley DB 5.1.25: (January >> 28, 2011) > > You built against BDB 5.1.29, but you have BDB 5.1.25 installed. This > would definitely happen if one system was updated when the other was not. Actually I did install BDB 5.1.29, but probably I need to adjust some library path or change a symlink. Mattias

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by mattias＠centaurix.com 03 Feb '12

03 Feb '12

On Fri, 03 Feb 2012 20:26:01 +0100, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > Hi Mattias, > > Any update? We would like to get a fix for this into OpenLDAP 2.4.29 if > possible. I'm having some problems with the BDB library: 4f2c4dd3 bdb_back_initialize: BDB library version mismatch: expected Berkeley DB 5.1.29: (October 25, 2011), got Berkeley DB 5.1.25: (January 28, 2011) I'll see if I can figure it out. Mattias

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by quanah＠zimbra.com 03 Feb '12

03 Feb '12

--On Tuesday, January 31, 2012 10:41 AM +0000 mattias(a)centaurix.com wrote: > On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc(a)symas.com> wrote: > >> Mattias Andersson wrote: >>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote: >>> >>>> Please provide a full gdb backtrace from the assertion failure. I've >>>> reproduced this configuration locally but see no crash using >>>> ldapsearch. >>>> I don't have the Softerra browser. >>> >>> Ok, see attachment. The problem is not reproducible with ldapsearch. >> >> Please see if the attached patch alters the behavior. Thanks. > > I'm getting an error that MozNSS is not found when I run ./configure. > > Mattias Hi Mattias, Any update? We would like to get a fix for this into OpenLDAP 2.4.29 if possible. Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by quanah＠zimbra.com 03 Feb '12

03 Feb '12

--On Friday, February 03, 2012 10:03 AM +0100 David Coutadeur <david.coutadeur(a)linagora.com> wrote: > > That was my first try. > I have used the option --enable-debug in the configure command, which > seems to produce AC_CFLAGS = -g -O2, itself reinjected in CFLAGS = > $(AC_CFLAGS) $(DEFS) in the Makefile. > > However this has lead to an unusable stacktrace. Thus I preferred using > the binary file (with debug symbols) pointed by > openldap-src/servers/slapd : > /opt/openldap-src/servers/slapd/.libs/lt-slapd > This gave me the stacktrace I first sent. By default, "make install" will strip the binaries of the debugging symbols. You have to prevent that by running it as: make install STRIP="" --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by hyc＠symas.com 03 Feb '12

03 Feb '12

Thanks. A fix for this is now in git master (5584e5b) > Le 03/02/2012 18:15, Howard Chu a écrit : >> david.coutadeur(a)linagora.com wrote: >>> I have reproduced the bug with a fresh new HEAD version yesterday, >>> including : >>> 02/02/2012 Howard Chu ITS#7146 fix prev commit >> >> Can you include a "bt full" gdb backtrace on this? >> >>> Le 02/02/2012 20:25, Michael Ströder a écrit : >>>> dcoutadeur(a)linagora.com wrote: >>>>> I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 (ie git >>>>> version) >>>> >>>> Which exact git version? Did you build RE24 from git already containing >>>> the fix for ITS#7113 (dup of ITS#6928)? -- -- 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#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by david.coutadeur＠linagora.com 03 Feb '12

03 Feb '12

Here it is. Program terminated with signal 11, Segmentation fault. #0 0x0818d9c2 in syncprov_op_mod (op=0x89b2fe0, rs=0x8c9b1108) at syncprov.c:2118 2118 for ( m2 = mt->mt_mods; m2->mi_next != mi; (gdb) bt full #0 0x0818d9c2 in syncprov_op_mod (op=0x89b2fe0, rs=0x8c9b1108) at syncprov.c:2118 m2 = 0x0 mt = 0x89cd028 mtdummy = {mt_mods = 0x889e468, mt_tail = 0x89b2fe0, mt_op = 0x89b2fe0, mt_mutex = {__data = {__lock = 48, __count = 2358971544, __owner = 135135137, __kind = 144388064, __nusers = 2358972680, {__spins = 16843008, __list = {__next = 0x1010100}}}, __size = "0\000\000\000\230\f\233\214\241\377\r\b\340/\233\b\b\021\233\214\000\001\001\001", __align = 48}} mi = 0x8bcae2a0 on = <value optimized out> si = 0x87cbfa0 cb = 0x8bcae258 opc = 0x8bcae268 have_psearches = 1 #1 0x080dff34 in overlay_op_walk (op=0x89b2fe0, rs=0x8c9b1108, which=op_add, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 rc = 144388064 #2 0x080e049a in over_op_func (op=0x89b2fe0, rs=0x8c9b1108, which=op_add) at backover.c:723 oi = 0x87c98a8 on = 0x87cbe98 be = 0x8793c48 db = {bd_info = 0x87cbe98, bd_self = 0x8793c48, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\000\001\001", '\000' <repeats 12 times>, "\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 = 0x87c93f8, be_nsuffix = 0x8796f70, be_schemadn = { bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 24, bv_val = 0x87c8b30 "cn=Manager,dc=afp,dc=com"}, be_rootndn = {bv_len = 24, bv_val = 0x87c8d40 "cn=manager,dc=afp,dc=com"}, be_rootpw = {bv_len = 38, bv_val = 0x87961f8 "{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 = 0x87cbe40, 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 = 0x889b1a0, 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 = 0x87cc1c8, be_pb = 0x0, be_cf_ocs = 0x8212020, be_private = 0x8793d48, be_next = { stqe_next = 0x87cc050}} cb = {sc_next = 0x0, sc_response = 0x80dfce0 <over_back_response>, sc_cleanup = 0, sc_private = 0x87c98a8} sc = <value optimized out> rc = <value optimized out> __PRETTY_FUNCTION__ = "over_op_func" #3 0x0807eeb9 in fe_op_add (op=0x89b2fe0, rs=0x8c9b1108) at add.c:334 repl_user = 0 rc = <value optimized out> bd = 0x8215ca0 textbuf = "\000\000\000\000\210\032\234\b0\033\233\214@q(\000\030\000\000\000\000\000\000\000\"\203%\000\b\241%\000\270\255\234\b\030lv\b\002\000\000\000\250\016\233\214-[\v\b\270\255\234\b\224\016\233\214\001\000\000\000\000\000\000\000\340i\234\b\000\000\000\000\n\000\000\000\001\000\000\000\270\027v\b\n\000\000\000\310\f\234\b\320\032\234\b\030lv\b\270\255\234\b\370\016\233\214O>\t\b\002\000\000\000\030Vt\b\370\016\233\214\261:\t\b@et\bpu\234\b'<\202\000\000\000\000\000\f\000\000\000\227V\235\b\207~\000\000\224\225d\000\300rv\b\300rv\b\370\016\233\214\335Pa\000\000V!\b,I\337\215\030\017\233\214\325\020\b\b\000V!\bpu\234\b\000\000\000\000\270\255\234\b\200H\337\215\000\000\000\000H\017\233\214G\353\a\b\300rv\b\300rv\b\001\000\000\---Type <return> to continue, or q <return> to quit--- 000H\017\233\214\020\000\000\000@I\337\215\377\377\377\377" __PRETTY_FUNCTION__ = "fe_op_add" #4 0x0807f7a3 in do_add (op=0x89b2fe0, rs=0x8c9b1108) at add.c:194 ber = <value optimized out> last = 0x89d56b1 "" dn = {bv_len = 38, bv_val = 0x89d55d8 "uid=dcoutadeur,ou=People,dc=afp,dc=com"} len = 28 tag = <value optimized out> modlist = 0x89ce650 modtail = 0x89becbc tmp = {sml_mod = {sm_desc = 0x80cb2aa, sm_values = 0x89c7570, sm_nvalues = 0x0, sm_numvals = 2358972600, sm_op = 0, sm_flags = 0, sm_type = {bv_len = 12, bv_val = 0x89d5697 "userPassword"}}, sml_next = 0x823c27} textbuf = "\000\000\000\000\000\000\000\000X\360\233\b\006\240\031\000\240\261\211\b\000\000\000\000\000\000\000\000@q(\000\000\000\000\000\000\000\000\000\060X\234\b\310\301|\b\000\000\000\000Te\031\000\000\000\000\000@q(\000\364_(\000\220\033\233\214\000\000\000\000\313؛\b\240\375\233\b\370\017\233\214T\213\202\000b\213\202\000;\334\022\000/\000\000\000\313؛\b\b\000\000\000\201\254\031\000\f\020\233\214<\004\023\000\270\020\233\214\312\315\022\000\260 \233\b\313؛\b\b\000\000\000\001\200\255\373\340\060\233\b\340\060\233\b\340\060\233\b\340\060\233\b\356\060\233\b\337\061\233\b\340\060\233\b\337\061\233\b,\000\000\000@q(", '\000' <repeats 13 times>, "\001\000\000\000\000\000\000\000\060\000\000\000\000\000\000\b", '\000' <repeats 16 times>, "\030X\234\b\000\000\000\000\001\000\000\000\004\000\020\000\350\021\233\214\310\020\233\214" rc = <value optimized out> freevals = <value optimized out> oex = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x807f0c0}, oe_db = 0x0} #5 0x0807759d in connection_operation (ctx=0x8c9b11e8, arg_v=0x89b2fe0) at connection.c:1138 rc = <value optimized out> cancel = <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_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 = 0xb7efd014 memctx = 0x89b3358 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #6 0x08077f6d in connection_read_thread (ctx=0x8c9b11e8, argv=0x2f) at connection.c:1274 s = <value optimized out> #7 0x006145e4 in ldap_int_thread_pool_wrapper (xpool=0x87687a8) at tpool.c:685 task = 0x89b2970 work_list = <value optimized out> ctx = {ltu_id = 2358975376, ltu_key = {{ltk_key = 0x8076270, ltk_data = 0x89b3268, ltk_free = 0x8076340 <conn_counter_destroy>}, {ltk_key = 0x80cb0e0, ltk_data = 0x89b3358, ltk_free = 0x80cb110 <slap_sl_mem_destroy>}, {ltk_key = 0x889b1b0, ltk_data = 0x89b78b0, ltk_free = 0x8125cf0 <bdb_reader_free>}, {ltk_key = 0x808b900, ltk_data = 0x0, ltk_free = 0x808b710 <slap_op_q_destroy>}, {ltk_key = 0x889ebe0, ltk_data = 0x89b9f78, ltk_free = 0x8125cf0 <bdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 27 times>}} kctx = <value optimized out> keyslot = 242 hash = 5209330 ---Type <return> to continue, or q <return> to quit--- __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #8 0x00821832 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #9 0x0020346e in clone () from /lib/libc.so.6 No symbol table info available. Le 03/02/2012 18:15, Howard Chu a écrit : > david.coutadeur(a)linagora.com wrote: >> I have reproduced the bug with a fresh new HEAD version yesterday, >> including : >> 02/02/2012 Howard Chu ITS#7146 fix prev commit > > Can you include a "bt full" gdb backtrace on this? > >> Le 02/02/2012 20:25, Michael Ströder a écrit : >>> dcoutadeur(a)linagora.com wrote: >>>> I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 (ie git >>>> version) >>> >>> Which exact git version? Did you build RE24 from git already containing >>> the fix for ITS#7113 (dup of ITS#6928)? >

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by hyc＠symas.com 03 Feb '12

03 Feb '12

david.coutadeur(a)linagora.com wrote: > I have reproduced the bug with a fresh new HEAD version yesterday, > including : > 02/02/2012 Howard Chu ITS#7146 fix prev commit Can you include a "bt full" gdb backtrace on this? > Le 02/02/2012 20:25, Michael Ströder a écrit : >> dcoutadeur(a)linagora.com wrote: >>> I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 (ie git >>> version) >> >> Which exact git version? Did you build RE24 from git already containing >> the fix for ITS#7113 (dup of ITS#6928)? -- -- 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#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by david.coutadeur＠linagora.com 03 Feb '12

03 Feb '12

I have reproduced the bug with a fresh new HEAD version yesterday, including : 02/02/2012 Howard Chu ITS#7146 fix prev commit Le 02/02/2012 20:25, Michael Ströder a écrit : > dcoutadeur(a)linagora.com wrote: >> I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 (ie git >> version) > > Which exact git version? Did you build RE24 from git already containing > the fix for ITS#7113 (dup of ITS#6928)? > > Ciao, Michael.

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by david.coutadeur＠linagora.com 03 Feb '12

03 Feb '12

That was my first try. I have used the option --enable-debug in the configure command, which seems to produce AC_CFLAGS = -g -O2, itself reinjected in CFLAGS = $(AC_CFLAGS) $(DEFS) in the Makefile. However this has lead to an unusable stacktrace. Thus I preferred using the binary file (with debug symbols) pointed by openldap-src/servers/slapd : /opt/openldap-src/servers/slapd/.libs/lt-slapd This gave me the stacktrace I first sent. I have used /opt/openldap-src/servers/slapd/.libs/slapd instead, and it seems to give a better stacktrace. (joined in this mail) Thank you for your help. Thread 10 (Thread 0xb7f66710 (LWP 32314)): #0 0x006b3402 in __kernel_vsyscall () #1 0x00822a77 in pthread_join () from /lib/libpthread.so.0 #2 0x00615314 in ldap_pvt_thread_join (thread=2623220624, thread_return=0x0) at thr_posix.c:197 #3 0x08071407 in slapd_daemon () at daemon.c:2930 #4 0x0805d421 in main (argc=9, argv=0xbffb3c04) at main.c:1012 Thread 9 (Thread 32325): #0 0x006b3402 in __kernel_vsyscall () #1 0x00203ae6 in epoll_wait () from /lib/libc.so.6 #2 0x0807426c in slapd_daemon_task (ptr=0xbffb3ac8) at daemon.c:2539 #3 0x00821832 in start_thread () from /lib/libpthread.so.0 #4 0x0020346e in clone () from /lib/libc.so.6 Thread 8 (Thread 32326): #0 0x006b3402 in __kernel_vsyscall () #1 0x001e790c in sched_yield () from /lib/libc.so.6 #2 0x006152b7 in ldap_pvt_thread_yield () at thr_posix.c:232 #3 0x0818d941 in syncprov_op_mod (op=0x89b2390, rs=0x8ddb9108) at syncprov.c:2112 #4 0x080dff34 in overlay_op_walk (op=0x89b2390, rs=0x8ddb9108, which=op_modify, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 #5 0x080e049a in over_op_func (op=0x89b2390, rs=0x8ddb9108, which=op_modify) at backover.c:723 #6 0x08090926 in fe_op_modify (op=0x89b2390, rs=0x8ddb9108) at modify.c:303 #7 0x080912a7 in do_modify (op=0x89b2390, rs=0x8ddb9108) at modify.c:177 #8 0x0807759d in connection_operation (ctx=0x8ddb91e8, arg_v=0x89b2390) at connection.c:1138 ---Type <return> to continue, or q <return> to quit--- #9 0x08077f6d in connection_read_thread (ctx=0x8ddb91e8, argv=0x23) at connection.c:1274 #10 0x006145e4 in ldap_int_thread_pool_wrapper (xpool=0x87687a8) at tpool.c:685 #11 0x00821832 in start_thread () from /lib/libpthread.so.0 #12 0x0020346e in clone () from /lib/libc.so.6 Thread 7 (Thread 32327): #0 0x006b3402 in __kernel_vsyscall () #1 0x001e790c in sched_yield () from /lib/libc.so.6 #2 0x006152b7 in ldap_pvt_thread_yield () at thr_posix.c:232 #3 0x0818d941 in syncprov_op_mod (op=0x89b6930, rs=0x8d9b8108) at syncprov.c:2112 #4 0x080dff34 in overlay_op_walk (op=0x89b6930, rs=0x8d9b8108, which=op_delete, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 #5 0x080e049a in over_op_func (op=0x89b6930, rs=0x8d9b8108, which=op_delete) at backover.c:723 #6 0x080916ae in fe_op_delete (op=0x89b6930, rs=0x8d9b8108) at delete.c:174 #7 0x08091c4f in do_delete (op=0x89b6930, rs=0x8d9b8108) at delete.c:95 #8 0x0807759d in connection_operation (ctx=0x8d9b81e8, arg_v=0x89b6930) at connection.c:1138 #9 0x08077f6d in connection_read_thread (ctx=0x8d9b81e8, argv=0x20) at connection.c:1274 #10 0x006145e4 in ldap_int_thread_pool_wrapper (xpool=0x87687a8) at tpool.c:685 #11 0x00821832 in start_thread () from /lib/libpthread.so.0 #12 0x0020346e in clone () from /lib/libc.so.6 Thread 6 (Thread 32328): #0 0x006b3402 in __kernel_vsyscall () #1 0x001e790c in sched_yield () from /lib/libc.so.6 #2 0x006152b7 in ldap_pvt_thread_yield () at thr_posix.c:232 #3 0x0818d941 in syncprov_op_mod (op=0x89b1d50, rs=0x8d5b7108) at syncprov.c:2112 ---Type <return> to continue, or q <return> to quit--- #4 0x080dff34 in overlay_op_walk (op=0x89b1d50, rs=0x8d5b7108, which=op_delete, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 #5 0x080e049a in over_op_func (op=0x89b1d50, rs=0x8d5b7108, which=op_delete) at backover.c:723 #6 0x080916ae in fe_op_delete (op=0x89b1d50, rs=0x8d5b7108) at delete.c:174 #7 0x08091c4f in do_delete (op=0x89b1d50, rs=0x8d5b7108) at delete.c:95 #8 0x0807759d in connection_operation (ctx=0x8d5b71e8, arg_v=0x89b1d50) at connection.c:1138 #9 0x08077f6d in connection_read_thread (ctx=0x8d5b71e8, argv=0x2c) at connection.c:1274 #10 0x006145e4 in ldap_int_thread_pool_wrapper (xpool=0x87687a8) at tpool.c:685 #11 0x00821832 in start_thread () from /lib/libpthread.so.0 #12 0x0020346e in clone () from /lib/libc.so.6 Thread 5 (Thread 32329): #0 0x0019673c in _IO_default_xsputn_internal () from /lib/libc.so.6 #1 0x0016d391 in vfprintf () from /lib/libc.so.6 #2 0x00191514 in vsnprintf () from /lib/libc.so.6 #3 0x0012b79f in lutil_debug (debug=256, level=256, fmt=0x81b2678 "%s BIND dn=\"%s\" mech=%s ssf=0\n") at debug.c:67 #4 0x0809552b in fe_op_bind_success (op=0x89a7320, rs=0x8d1b6108) at bind.c:429 #5 0x08095d04 in fe_op_bind (op=0x89a7320, rs=0x8d1b6108) at bind.c:386 #6 0x0809651c in do_bind (op=0x89a7320, rs=0x8d1b6108) at bind.c:205 #7 0x0807759d in connection_operation (ctx=0x8d1b61e8, arg_v=0x89a7320) at connection.c:1138 #8 0x08077f6d in connection_read_thread (ctx=0x8d1b61e8, argv=0x1b) at connection.c:1274 #9 0x006145e4 in ldap_int_thread_pool_wrapper (xpool=0x87687a8) at tpool.c:685 #10 0x00821832 in start_thread () from /lib/libpthread.so.0 #11 0x0020346e in clone () from /lib/libc.so.6 Thread 4 (Thread 32392): ---Type <return> to continue, or q <return> to quit--- #0 0x006b3402 in __kernel_vsyscall () #1 0x001e790c in sched_yield () from /lib/libc.so.6 #2 0x006152b7 in ldap_pvt_thread_yield () at thr_posix.c:232 #3 0x0818d941 in syncprov_op_mod (op=0x89b70d8, rs=0x8c5b0108) at syncprov.c:2112 #4 0x080dff34 in overlay_op_walk (op=0x89b70d8, rs=0x8c5b0108, which=op_add, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 #5 0x080e049a in over_op_func (op=0x89b70d8, rs=0x8c5b0108, which=op_add) at backover.c:723 #6 0x0807eeb9 in fe_op_add (op=0x89b70d8, rs=0x8c5b0108) at add.c:334 #7 0x0807f7a3 in do_add (op=0x89b70d8, rs=0x8c5b0108) at add.c:194 #8 0x0807759d in connection_operation (ctx=0x8c5b01e8, arg_v=0x89b70d8) at connection.c:1138 #9 0x08077f6d in connection_read_thread (ctx=0x8c5b01e8, argv=0x28) at connection.c:1274 #10 0x006145e4 in ldap_int_thread_pool_wrapper (xpool=0x87687a8) at tpool.c:685 #11 0x00821832 in start_thread () from /lib/libpthread.so.0 #12 0x0020346e in clone () from /lib/libc.so.6 Thread 3 (Thread 32393): #0 0x006b3402 in __kernel_vsyscall () #1 0x001e790c in sched_yield () from /lib/libc.so.6 #2 0x006152b7 in ldap_pvt_thread_yield () at thr_posix.c:232 #3 0x0818d941 in syncprov_op_mod (op=0x89b3998, rs=0x8c1af108) at syncprov.c:2112 #4 0x080dff34 in overlay_op_walk (op=0x89b3998, rs=0x8c1af108, which=op_modify, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 #5 0x080e049a in over_op_func (op=0x89b3998, rs=0x8c1af108, which=op_modify) at backover.c:723 #6 0x08090926 in fe_op_modify (op=0x89b3998, rs=0x8c1af108) at modify.c:303 #7 0x080912a7 in do_modify (op=0x89b3998, rs=0x8c1af108) at modify.c:177 #8 0x0807759d in connection_operation (ctx=0x8c1af1e8, arg_v=0x89b3998) at connection.c:1138 #9 0x08077f6d in connection_read_thread (ctx=0x8c1af1e8, argv=0x2d) at connection.c:1274 ---Type <return> to continue, or q <return> to quit--- #10 0x006145e4 in ldap_int_thread_pool_wrapper (xpool=0x87687a8) at tpool.c:685 #11 0x00821832 in start_thread () from /lib/libpthread.so.0 #12 0x0020346e in clone () from /lib/libc.so.6 Thread 2 (Thread 32394): #0 0x006b3402 in __kernel_vsyscall () #1 0x001e790c in sched_yield () from /lib/libc.so.6 #2 0x006152b7 in ldap_pvt_thread_yield () at thr_posix.c:232 #3 0x0818d941 in syncprov_op_mod (op=0x89b2b78, rs=0x8bcad108) at syncprov.c:2112 #4 0x080dff34 in overlay_op_walk (op=0x89b2b78, rs=0x8bcad108, which=op_delete, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 #5 0x080e049a in over_op_func (op=0x89b2b78, rs=0x8bcad108, which=op_delete) at backover.c:723 #6 0x080916ae in fe_op_delete (op=0x89b2b78, rs=0x8bcad108) at delete.c:174 #7 0x08091c4f in do_delete (op=0x89b2b78, rs=0x8bcad108) at delete.c:95 #8 0x0807759d in connection_operation (ctx=0x8bcad1e8, arg_v=0x89b2b78) at connection.c:1138 #9 0x08077f6d in connection_read_thread (ctx=0x8bcad1e8, argv=0x21) at connection.c:1274 #10 0x006145e4 in ldap_int_thread_pool_wrapper (xpool=0x87687a8) at tpool.c:685 #11 0x00821832 in start_thread () from /lib/libpthread.so.0 #12 0x0020346e in clone () from /lib/libc.so.6 Thread 1 (Thread 0x8c9b1b90 (LWP 32391)): #0 0x0818d9c2 in syncprov_op_mod (op=0x89b2fe0, rs=0x8c9b1108) at syncprov.c:2118 #1 0x080dff34 in overlay_op_walk (op=0x89b2fe0, rs=0x8c9b1108, which=op_add, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 #2 0x080e049a in over_op_func (op=0x89b2fe0, rs=0x8c9b1108, which=op_add) at backover.c:723 #3 0x0807eeb9 in fe_op_add (op=0x89b2fe0, rs=0x8c9b1108) at add.c:334 #4 0x0807f7a3 in do_add (op=0x89b2fe0, rs=0x8c9b1108) at add.c:194 ---Type <return> to continue, or q <return> to quit--- #5 0x0807759d in connection_operation (ctx=0x8c9b11e8, arg_v=0x89b2fe0) at connection.c:1138 #6 0x08077f6d in connection_read_thread (ctx=0x8c9b11e8, argv=0x2f) at connection.c:1274 #7 0x006145e4 in ldap_int_thread_pool_wrapper (xpool=0x87687a8) at tpool.c:685 #8 0x00821832 in start_thread () from /lib/libpthread.so.0 #9 0x0020346e in clone () from /lib/libc.so.6 Le 02/02/2012 20:09, Quanah Gibson-Mount a écrit : > --On Thursday, February 02, 2012 4:58 PM +0000 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) >> > > Please rebuild with debugging symbols (CFLAGS=-g) and update with a > usable stack trace. Thank you. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2012