openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

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

Re: (ITS#7149) Back-perl, Back-shell and Binary Data
by hyc＠symas.com 02 Feb '12

02 Feb '12

llg(a)portaildulibre.fr wrote: > Le 02/02/2012 20:32, hyc(a)symas.com a écrit : >> jiashun.qian(a)atos.net wrote: >>> Full_Name: Jiashun QIAN >>> Version: 2.4.28 >>> OS: CentOS 6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (85.115.60.180) >>> >>> >>> The backend shell and the backend perl can't handle some binary data. >>> >>> This occurs only with MODIFY because when ADD the binary data is encoded in >>> base64 but not MODIFY. >>> >>> The binary data is truncated when if it contains \0. In fact, data is stored in >>> a linked list of char * and treated as characters. >>> >>> --- >>> servers/slapd/back-perl/modify.c >>> XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); >>> --- >>> >>> The type of mods->sm_values[i].bv_val is char*. >>> >>> To handle the binary data, for back-perl, just change another function mXPUSHp, >>> which we can put the exacte length of mod->sm_values[i].bv_val as parameter, >>> it's mod->sm_values[i].bv_len. So it will push the total data. >> That is obviously the wrong approach. Since these backends communicate using >> LDIF, binary values should be base64 encoded according to the LDIF rules. > The input LDIF file for ldap_modify contains base64 encoded > usercertificate, but back-perl receives binary data. > This behaviour only occured with modification action : with add action, > certificate is received base64 encoded. Yes, I already understood that. You're still not understanding what I said. Your patch should do the appropriate checks for binary data and do the proper base64 encoding for the modify values that back-perl (or back-shell) sends to the perl module (or shell script). This has nothing to do with the input LDIF file, this is about how slapd transmits internal data from a backend to the external perl or shell scripts. >> Thanks for the patch, but we can't merge it since the provided solution is wrong. -- -- 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#7149) Back-perl, Back-shell and Binary Data
by llg＠portaildulibre.fr 02 Feb '12

02 Feb '12

Le 02/02/2012 20:32, hyc(a)symas.com a écrit : > jiashun.qian(a)atos.net wrote: >> Full_Name: Jiashun QIAN >> Version: 2.4.28 >> OS: CentOS 6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (85.115.60.180) >> >> >> The backend shell and the backend perl can't handle some binary data. >> >> This occurs only with MODIFY because when ADD the binary data is encoded in >> base64 but not MODIFY. >> >> The binary data is truncated when if it contains \0. In fact, data is stored in >> a linked list of char * and treated as characters. >> >> --- >> servers/slapd/back-perl/modify.c >> XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); >> --- >> >> The type of mods->sm_values[i].bv_val is char*. >> >> To handle the binary data, for back-perl, just change another function mXPUSHp, >> which we can put the exacte length of mod->sm_values[i].bv_val as parameter, >> it's mod->sm_values[i].bv_len. So it will push the total data. > That is obviously the wrong approach. Since these backends communicate using > LDIF, binary values should be base64 encoded according to the LDIF rules. The input LDIF file for ldap_modify contains base64 encoded usercertificate, but back-perl receives binary data. This behaviour only occured with modification action : with add action, certificate is received base64 encoded. Llg > > Thanks for the patch, but we can't merge it since the provided solution is wrong. >

1 0

Re: (ITS#7149) Back-perl, Back-shell and Binary Data
by hyc＠symas.com 02 Feb '12

02 Feb '12

jiashun.qian(a)atos.net wrote: > Full_Name: Jiashun QIAN > Version: 2.4.28 > OS: CentOS 6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.115.60.180) > > > The backend shell and the backend perl can't handle some binary data. > > This occurs only with MODIFY because when ADD the binary data is encoded in > base64 but not MODIFY. > > The binary data is truncated when if it contains \0. In fact, data is stored in > a linked list of char * and treated as characters. > > --- > servers/slapd/back-perl/modify.c > XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); > --- > > The type of mods->sm_values[i].bv_val is char*. > > To handle the binary data, for back-perl, just change another function mXPUSHp, > which we can put the exacte length of mod->sm_values[i].bv_val as parameter, > it's mod->sm_values[i].bv_len. So it will push the total data. That is obviously the wrong approach. Since these backends communicate using LDIF, binary values should be base64 encoded according to the LDIF rules. Thanks for the patch, but we can't merge it since the provided solution is wrong. -- -- 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 michael＠stroeder.com 02 Feb '12

02 Feb '12

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 quanah＠zimbra.com 02 Feb '12

02 Feb '12

--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:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs