openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#6691) error 4 in slapd: segfault with back-sql in debian amd64
by andresmarenco＠gmail.com 01 Nov '10

01 Nov '10

--20cf3054961990a416049404fd5f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok. Here is the full backtrace: #0 0x0000000000491ac5 in slap_sl_free (ptr=3D0xffffffde01373fc0, ctx=3D0x1367120) at sl_malloc.c:490 490 if ( tmpp[-1] & 1 ) { (gdb) thr apply all bt full Thread 3 (process 30526): #0 0x00007f6cc93b4c18 in epoll_wait () from /lib/libc.so.6 No symbol table info available. #1 0x0000000000422e03 in slapd_daemon_task (ptr=3D0x0) at daemon.c:2467 ns =3D 1 at =3D 0 nfds =3D 4 revents =3D (struct epoll_event *) 0x11996b0 tvp =3D (struct timeval *) 0x0 cat =3D {tv_sec =3D 0, tv_usec =3D 0} i =3D 1 nwriters =3D 0 now =3D 1288647213 tv =3D {tv_sec =3D 0, tv_usec =3D 0} tdelta =3D 1 rtask =3D (struct re_s *) 0x0 l =3D 2 last_idle_check =3D 0 ebadf =3D 0 #2 0x00007f6cc963efc7 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #3 0x00007f6cc93b464d in clone () from /lib/libc.so.6 No symbol table info available. #4 0x0000000000000000 in ?? () No symbol table info available. Thread 2 (process 30523): #0 0x00007f6cc963f715 in pthread_join () from /lib/libpthread.so.0 No symbol table info available. #1 0x000000000050f74f in ldap_pvt_thread_join (thread=3D1103399248, thread_return=3D0x0) at thr_posix.c:197 No locals. #2 0x0000000000423b52 in slapd_daemon () at daemon.c:2842 listener_tid =3D 1103399248 rc =3D 0 #3 0x0000000000406093 in main (argc=3D3, argv=3D0x7fff6175c7a8) at main.c:= 961 i =3D 3 no_detach =3D 1 rc =3D 0 urls =3D 0x0 username =3D 0x0 groupname =3D 0x0 sandbox =3D 0x0 syslogUser =3D 160 g_argc =3D 3 g_argv =3D (char **) 0x7fff6175c7a8 configfile =3D 0x0 configdir =3D 0x0 serverName =3D 0x7fff6175d7da "slapd" serverMode =3D 1 scp =3D (struct sync_cookie *) 0x0 scp_entry =3D (struct sync_cookie *) 0x0 debug_unknowns =3D (char **) 0x0 syslog_unknowns =3D (char **) 0x0 serverNamePrefix =3D 0x53fb6b "" l =3D 4209819 slapd_pid_file_unlink =3D 1 slapd_args_file_unlink =3D 1 firstopt =3D 0 __PRETTY_FUNCTION__ =3D "main" Thread 1 (process 30527): #0 0x0000000000491ac5 in slap_sl_free (ptr=3D0xffffffde01373fc0, ctx=3D0x1367120) at sl_malloc.c:490 sh =3D (struct slab_heap *) 0x1367120 size =3D 146028888064 p =3D (ber_len_t *) 0xffffffde01373fb8 tmpp =3D (ber_len_t *) 0xffffffde01373fb8 __PRETTY_FUNCTION__ =3D "slap_sl_free" #1 0x00000000004d562e in backsql_entry_clean (op=3D0x136db10, e=3D0x42447a= 40) at search.c:2680 ctx =3D (void *) 0x42448df0 #2 0x00000000004d4e8f in backsql_search (op=3D0x136db10, rs=3D0x42448ca0) at search.c:2517 bi =3D (backsql_info *) 0x11de090 dbh =3D (SQLHDBC) 0x1343bf0 sres =3D 0 user_entry =3D {e_id =3D 0, e_name =3D {bv_len =3D 0, bv_val =3D 0x0}, e_nname =3D {bv_len =3D 0, bv_val =3D 0x0}, e_attrs =3D 0x0, e_ocflags = =3D 0, e_bv =3D { bv_len =3D 0, bv_val =3D 0x0}, e_private =3D 0x0} base_entry =3D {e_id =3D 2743, e_name =3D {bv_len =3D 0, bv_val =3D 0x0= }, e_nname =3D {bv_len =3D 34, bv_val =3D 0x1380620 "dc=3Dtec-digital,dc=3Ditcr,dc=3Dac,dc=3Dcr"}, e_attrs =3D 0x1212858, e_ocflags =3D 256, e_bv =3D {bv_len =3D 0, bv_val = =3D 0x0}, e_private =3D 0x0} manageDSAit =3D 0 stoptime =3D 1288647212 bsi =3D {bsi_op =3D 0x136db10, bsi_rs =3D 0x42448ca0, bsi_flags =3D 1, bsi_base_ndn =3D 0x136db48, bsi_use_subtree_shortcut =3D 0, bsi_base_id = =3D { eid_id =3D 2743, eid_keyval =3D 2743, eid_oc_id =3D 1, eid_oc =3D 0x136= 93b0, eid_dn =3D {bv_len =3D 0, bv_val =3D 0x0}, eid_ndn =3D {bv_len =3D 0, b= v_val =3D 0x0}, eid_next =3D 0x0}, bsi_scope =3D 0, bsi_filter =3D 0x1373e98, bsi_stoptime =3D 1288647212, bsi_id_list =3D 0x42447938, bsi_id_listtail =3D 0x42447978, bsi_c_eid =3D 0x42447938, bsi_n_candidate= s =3D -2, bsi_status =3D 0, bsi_oc =3D 0x13693b0, bsi_sel =3D {bb_val =3D {bv_len = =3D 0, bv_val =3D 0x0}, bb_len =3D 0}, bsi_from =3D {bb_val =3D {bv_len =3D = 0, bv_val =3D 0x0}, bb_len =3D 0}, bsi_join_where =3D {bb_val =3D {bv_le= n =3D 0, bv_val =3D 0x0}, bb_len =3D 0}, bsi_flt_where =3D {bb_val =3D {bv_len= =3D 0, bv_val =3D 0x0}, bb_len =3D 0}, bsi_filter_oc =3D 0x0, bsi_dbh =3D 0x= 1343bf0, bsi_attrs =3D 0x0, bsi_e =3D 0x0} eid =3D (backsql_entryID *) 0x0 nbase =3D {bv_len =3D 0, bv_val =3D 0x0} lastid =3D 0 #3 0x0000000000429f5c in fe_op_search (op=3D0x136db10, rs=3D0x42448ca0) at search.c:366 bd =3D (BackendDB *) 0x7c28a0 #4 0x00000000004298c7 in do_search (op=3D0x136db10, rs=3D0x42448ca0) at search.c:217 base =3D {bv_len =3D 34, bv_val =3D 0x136d867 "dc=3Dtec-digital,dc=3Ditcr,dc=3Dac,dc=3Dcr"} siz =3D 0 off =3D 0 i =3D 0 #5 0x0000000000426952 in connection_operation (ctx=3D0x42448df0, arg_v=3D0x136db10) at connection.c:1109 rc =3D 80 cancel =3D 32620 op =3D (Operation *) 0x136db10 rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 101, sr_msgid =3D 3, sr_err = =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls =3D 0x0, sr= _un =3D { sru_search =3D {r_entry =3D 0x0, r_attr_flags =3D 0, r_operational_attr= s =3D 0x0, r_attrs =3D 0x0, r_nentries =3D 1, r_v2ref =3D 0x0}, sru_sasl =3D { r_sasldata =3D 0x0}, sru_extended =3D {r_rspoid =3D 0x0, r_rspdata = =3D 0x0}}, sr_flags =3D 0} tag =3D 99 opidx =3D SLAP_OP_SEARCH conn =3D (Connection *) 0x7f6cca0568d0 memctx =3D (void *) 0x1367120 memctx_null =3D (void *) 0x0 memsiz =3D 1048576 __PRETTY_FUNCTION__ =3D "connection_operation" #6 0x0000000000426ede in connection_read_thread (ctx=3D0x42448df0, argv=3D= 0x9) at connection.c:1245 rc =3D 0 cri =3D {op =3D 0x136db10, func =3D 0, arg =3D 0x0, ctx =3D 0x42448df0, nullop =3D 0} s =3D 9 #7 0x000000000050e33b in ldap_int_thread_pool_wrapper (xpool=3D0x11baea0) at tpool.c:685 pool =3D (struct ldap_int_thread_pool_s *) 0x11baea0 task =3D (ldap_int_thread_task_t *) 0x136d610 work_list =3D (ldap_int_tpool_plist_t *) 0x11baf38 ctx =3D {ltu_id =3D 1111791952, ltu_key =3D {{ltk_key =3D 0x4264ab, ltk_data =3D 0x136df60, ltk_free =3D 0x4262fb <conn_counter_destroy>}= , { ltk_key =3D 0x490802, ltk_data =3D 0x1367120, ltk_free =3D 0x4905fc <slap_sl_mem_destroy>}, {ltk_key =3D 0x440888, ltk_data =3D 0x0, ltk_free =3D 0x4407e4 <slap_op_q_destroy>}, { ltk_key =3D 0x806ca0, ltk_data =3D 0x1343bf0, ltk_free =3D 0x4d6aea <backsql_db_conn_keyfree>}, {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D 0} <repeats 28 times>}} kctx =3D (ldap_int_thread_userctx_t *) 0x0 i =3D 32 keyslot =3D 431 hash =3D 2036986287 __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper" #8 0x00007f6cc963efc7 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #9 0x00007f6cc93b464d in clone () from /lib/libc.so.6 No symbol table info available. #10 0x0000000000000000 in ?? () No symbol table info available. (gdb) --=20 Andr=E9s Marenco Z=FA=F1iga Equipo de Desarrollo TEC_Digital --20cf3054961990a416049404fd5f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok. Here is the full backtrace: #0=A0 0x0000000000491ac5 in slap_sl_= free (ptr=3D0xffffffde01373fc0, ctx=3D0x1367120) =A0=A0=A0 at sl_malloc.= c:490 490=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 if ( tmpp[-1] & 1 )= { (gdb) thr apply all bt full Thread 3 (process 30526): #0=A0 0x00007f6cc93b4c18 in epoll_wait () = from /lib/libc.so.6 No symbol table info available. #1=A0 0x000000000= 0422e03 in slapd_daemon_task (ptr=3D0x0) at daemon.c:2467 =A0=A0=A0 ns = =3D 1 =A0=A0=A0 at =3D 0 =A0=A0=A0 nfds =3D 4 =A0=A0=A0 revents =3D (struct epoll_event *) 0x1199= 6b0 =A0=A0=A0 tvp =3D (struct timeval *) 0x0 =A0=A0=A0 cat =3D {tv_se= c =3D 0, tv_usec =3D 0} =A0=A0=A0 i =3D 1 =A0=A0=A0 nwriters =3D 0<br= >=A0=A0=A0 now =3D 1288647213 =A0=A0=A0 tv =3D {tv_sec =3D 0, tv_usec = =3D 0} =A0=A0=A0 tdelta =3D 1 =A0=A0=A0 rtask =3D (struct re_s *) 0x0 =A0=A0= =A0 l =3D 2 =A0=A0=A0 last_idle_check =3D 0 =A0=A0=A0 ebadf =3D 0 = #2=A0 0x00007f6cc963efc7 in start_thread () from /lib/libpthread.so.0 No= symbol table info available. #3=A0 0x00007f6cc93b464d in clone () from = /lib/libc.so.6 No symbol table info available. #4=A0 0x0000000000000000 in ?? () No = symbol table info available. Thread 2 (process 30523): #0=A0 0x00= 007f6cc963f715 in pthread_join () from /lib/libpthread.so.0 No symbol ta= ble info available. #1=A0 0x000000000050f74f in ldap_pvt_thread_join (thread=3D1103399248, = =A0=A0=A0 thread_return=3D0x0) at thr_posix.c:197 No locals. #2=A0 0x= 0000000000423b52 in slapd_daemon () at daemon.c:2842 =A0=A0=A0 listener_= tid =3D 1103399248 =A0=A0=A0 rc =3D 0 #3=A0 0x0000000000406093 in main (argc=3D3, argv=3D0x= 7fff6175c7a8) at main.c:961 =A0=A0=A0 i =3D 3 =A0=A0=A0 no_detach =3D= 1 =A0=A0=A0 rc =3D 0 =A0=A0=A0 urls =3D 0x0 =A0=A0=A0 username = =3D 0x0 =A0=A0=A0 groupname =3D 0x0 =A0=A0=A0 sandbox =3D 0x0 =A0=A0=A0 syslogUser =3D 160 =A0=A0=A0 g_argc =3D 3 =A0=A0=A0 g_argv = =3D (char **) 0x7fff6175c7a8 =A0=A0=A0 configfile =3D 0x0 =A0=A0=A0 c= onfigdir =3D 0x0 =A0=A0=A0 serverName =3D 0x7fff6175d7da "slapd&quo= t; =A0=A0=A0 serverMode =3D 1 =A0=A0=A0 scp =3D (struct sync_cookie *= ) 0x0 =A0=A0=A0 scp_entry =3D (struct sync_cookie *) 0x0 =A0=A0=A0 debug_unkno= wns =3D (char **) 0x0 =A0=A0=A0 syslog_unknowns =3D (char **) 0x0 =A0= =A0=A0 serverNamePrefix =3D 0x53fb6b "" =A0=A0=A0 l =3D 420981= 9 =A0=A0=A0 slapd_pid_file_unlink =3D 1 =A0=A0=A0 slapd_args_file_unlink =3D 1 =A0=A0=A0 firstopt =3D 0 =A0= =A0=A0 __PRETTY_FUNCTION__ =3D "main" Thread 1 (process 30= 527): #0=A0 0x0000000000491ac5 in slap_sl_free (ptr=3D0xffffffde01373fc0= , ctx=3D0x1367120) =A0=A0=A0 at sl_malloc.c:490 =A0=A0=A0 sh =3D (struct slab_heap *) 0x1367120 =A0=A0=A0 size =3D 14602= 8888064 =A0=A0=A0 p =3D (ber_len_t *) 0xffffffde01373fb8 =A0=A0=A0 tm= pp =3D (ber_len_t *) 0xffffffde01373fb8 =A0=A0=A0 __PRETTY_FUNCTION__ = =3D "slap_sl_free" #1=A0 0x00000000004d562e in backsql_entry_c= lean (op=3D0x136db10, e=3D0x42447a40) =A0=A0=A0 at search.c:2680 =A0=A0=A0 ctx =3D (void *) 0x42448df0 #2= =A0 0x00000000004d4e8f in backsql_search (op=3D0x136db10, rs=3D0x42448ca0)<= br>=A0=A0=A0 at search.c:2517 =A0=A0=A0 bi =3D (backsql_info *) 0x11de09= 0 =A0=A0=A0 dbh =3D (SQLHDBC) 0x1343bf0 =A0=A0=A0 sres =3D 0 =A0=A0=A0 user_entry =3D {e_id =3D 0, e_name =3D {b= v_len =3D 0, bv_val =3D 0x0}, =A0 e_nname =3D {bv_len =3D 0, bv_val =3D= 0x0}, e_attrs =3D 0x0, e_ocflags =3D 0, e_bv =3D { =A0=A0=A0 bv_len =3D= 0, bv_val =3D 0x0}, e_private =3D 0x0} =A0=A0=A0 base_entry =3D {e_id = =3D 2743, e_name =3D {bv_len =3D 0, bv_val =3D 0x0}, =A0 e_nname =3D {bv_len =3D 34, =A0=A0=A0 bv_val =3D 0x1380620 "dc= =3Dtec-digital,dc=3Ditcr,dc=3Dac,dc=3Dcr"}, =A0 e_attrs =3D 0x1212= 858, e_ocflags =3D 256, e_bv =3D {bv_len =3D 0, bv_val =3D 0x0}, =A0 e_= private =3D 0x0} =A0=A0=A0 manageDSAit =3D 0 =A0=A0=A0 stoptime =3D 1288647212 =A0=A0=A0 bsi =3D {bsi_op =3D 0x136db1= 0, bsi_rs =3D 0x42448ca0, bsi_flags =3D 1, =A0 bsi_base_ndn =3D 0x136db= 48, bsi_use_subtree_shortcut =3D 0, bsi_base_id =3D { =A0=A0=A0 eid_id = =3D 2743, eid_keyval =3D 2743, eid_oc_id =3D 1, eid_oc =3D 0x13693b0, =A0=A0=A0 eid_dn =3D {bv_len =3D 0, bv_val =3D 0x0}, eid_ndn =3D {bv_len = =3D 0, bv_val =3D 0x0}, =A0=A0=A0 eid_next =3D 0x0}, bsi_scope =3D 0, b= si_filter =3D 0x1373e98, =A0 bsi_stoptime =3D 1288647212, bsi_id_list = =3D 0x42447938, =A0 bsi_id_listtail =3D 0x42447978, bsi_c_eid =3D 0x424= 47938, bsi_n_candidates =3D -2, =A0 bsi_status =3D 0, bsi_oc =3D 0x13693b0, bsi_sel =3D {bb_val =3D {bv_len= =3D 0, =A0=A0=A0=A0=A0 bv_val =3D 0x0}, bb_len =3D 0}, bsi_from =3D {b= b_val =3D {bv_len =3D 0, =A0=A0=A0=A0=A0 bv_val =3D 0x0}, bb_len =3D 0}= , bsi_join_where =3D {bb_val =3D {bv_len =3D 0, =A0=A0=A0=A0=A0 bv_val =3D 0x0}, bb_len =3D 0}, bsi_flt_where =3D {bb_val = =3D {bv_len =3D 0, =A0=A0=A0=A0=A0 bv_val =3D 0x0}, bb_len =3D 0}, bsi_= filter_oc =3D 0x0, bsi_dbh =3D 0x1343bf0, =A0 bsi_attrs =3D 0x0, bsi_e = =3D 0x0} =A0=A0=A0 eid =3D (backsql_entryID *) 0x0 =A0=A0=A0 nbase =3D {bv_len =3D 0, bv_val =3D 0x0} =A0=A0=A0 lastid =3D = 0 #3=A0 0x0000000000429f5c in fe_op_search (op=3D0x136db10, rs=3D0x42448= ca0) =A0=A0=A0 at search.c:366 =A0=A0=A0 bd =3D (BackendDB *) 0x7c28a= 0 #4=A0 0x00000000004298c7 in do_search (op=3D0x136db10, rs=3D0x42448ca0= ) =A0=A0=A0 at search.c:217 =A0=A0=A0 base =3D {bv_len =3D 34, =A0 bv_= val =3D 0x136d867 "dc=3Dtec-digital,dc=3Ditcr,dc=3Dac,dc=3Dcr"}<b= r>=A0=A0=A0 siz =3D 0 =A0=A0=A0 off =3D 0 =A0=A0=A0 i =3D 0 #5=A0 = 0x0000000000426952 in connection_operation (ctx=3D0x42448df0, =A0=A0=A0 arg_v=3D0x136db10) at connection.c:1109 =A0=A0=A0 rc =3D 80<br= >=A0=A0=A0 cancel =3D 32620 =A0=A0=A0 op =3D (Operation *) 0x136db10 = =A0=A0=A0 rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 101, sr_msgid =3D 3, s= r_err =3D 0, =A0 sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, s= r_ctrls =3D 0x0, sr_un =3D { =A0=A0=A0 sru_search =3D {r_entry =3D 0x0, r_attr_flags =3D 0, r_operationa= l_attrs =3D 0x0, =A0=A0=A0=A0=A0 r_attrs =3D 0x0, r_nentries =3D 1, r_v= 2ref =3D 0x0}, sru_sasl =3D { =A0=A0=A0=A0=A0 r_sasldata =3D 0x0}, sru_e= xtended =3D {r_rspoid =3D 0x0, r_rspdata =3D 0x0}}, =A0 sr_flags =3D 0} =A0=A0=A0 tag =3D 99 =A0=A0=A0 opidx =3D SLAP_OP_= SEARCH =A0=A0=A0 conn =3D (Connection *) 0x7f6cca0568d0 =A0=A0=A0 mem= ctx =3D (void *) 0x1367120 =A0=A0=A0 memctx_null =3D (void *) 0x0 =A0= =A0=A0 memsiz =3D 1048576 =A0=A0=A0 __PRETTY_FUNCTION__ =3D "connec= tion_operation" #6=A0 0x0000000000426ede in connection_read_thread (ctx=3D0x42448df0, argv= =3D0x9) =A0=A0=A0 at connection.c:1245 =A0=A0=A0 rc =3D 0 =A0=A0= =A0 cri =3D {op =3D 0x136db10, func =3D 0, arg =3D 0x0, ctx =3D 0x42448df0,= =A0 nullop =3D 0} =A0=A0=A0 s =3D 9 #7=A0 0x000000000050e33b in ldap_int_thread_pool_wrapper (xpool=3D0x11baea0= ) =A0=A0=A0 at tpool.c:685 =A0=A0=A0 pool =3D (struct ldap_int_thread= _pool_s *) 0x11baea0 =A0=A0=A0 task =3D (ldap_int_thread_task_t *) 0x136= d610 =A0=A0=A0 work_list =3D (ldap_int_tpool_plist_t *) 0x11baf38 =A0=A0=A0 ctx =3D {ltu_id =3D 1111791952, ltu_key =3D {{ltk_key =3D 0x4264a= b, =A0=A0=A0=A0=A0 ltk_data =3D 0x136df60, ltk_free =3D 0x4262fb <co= nn_counter_destroy>}, { =A0=A0=A0=A0=A0 ltk_key =3D 0x490802, ltk_dat= a =3D 0x1367120, =A0=A0=A0=A0=A0 ltk_free =3D 0x4905fc <slap_sl_mem_= destroy>}, {ltk_key =3D 0x440888, =A0=A0=A0=A0=A0 ltk_data =3D 0x0, ltk_free =3D 0x4407e4 <slap_op_q_destr= oy>}, { =A0=A0=A0=A0=A0 ltk_key =3D 0x806ca0, ltk_data =3D 0x1343bf0,= =A0=A0=A0=A0=A0 ltk_free =3D 0x4d6aea <backsql_db_conn_keyfree>}= , {ltk_key =3D 0x0, =A0=A0=A0=A0=A0 ltk_data =3D 0x0, ltk_free =3D 0} &= lt;repeats 28 times>}} =A0=A0=A0 kctx =3D (ldap_int_thread_userctx_t *) 0x0 =A0=A0=A0 i =3D 32<= br>=A0=A0=A0 keyslot =3D 431 =A0=A0=A0 hash =3D 2036986287 =A0=A0=A0 = __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper" #8=A0 0= x00007f6cc963efc7 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #9=A0 0x00007f6cc93b464d in clone () fro= m /lib/libc.so.6 No symbol table info available. #10 0x00000000000000= 00 in ?? () No symbol table info available. (gdb) -- Andr=E9s Marenco Z=FA=F1iga Equipo de Desarrollo TEC_Digital --20cf3054961990a416049404fd5f--

1 0

Re: (ITS#6691) error 4 in slapd: segfault with back-sql in debian amd64
by quanah＠zimbra.com 01 Nov '10

01 Nov '10

--On Monday, November 01, 2010 9:04 PM +0000 andresmarenco(a)gmail.com wrote: > --20cf301d43804e8b0304940425e5 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > Ok, thanks for the answer I suggest running: thr apply all bt full inside gdb to get a full backtrace of all threads, and then submit that to the ITS. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6691) error 4 in slapd: segfault with back-sql in debian amd64
by andresmarenco＠gmail.com 01 Nov '10

01 Nov '10

--20cf301d43804e8b0304940425e5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok, thanks for the answer This is the new backtrace: Core was generated by `./slapd -d -1'. Program terminated with signal 11, Segmentation fault. [New process 1656] [New process 1570] [New process 1573] #0 0x0000000000491ac5 in slap_sl_free (ptr=3D0xffffffd2028b00d0, ctx=3D0x28a3120) at sl_malloc.c:490 490 if ( tmpp[-1] & 1 ) { (gdb) bt #0 0x0000000000491ac5 in slap_sl_free (ptr=3D0xffffffd2028b00d0, ctx=3D0x28a3120) at sl_malloc.c:490 #1 0x00000000004d562e in backsql_entry_clean (op=3D0x28a9b10, e=3D0x42e98a= 40) at search.c:2680 #2 0x00000000004d4e8f in backsql_search (op=3D0x28a9b10, rs=3D0x42e99ca0) at search.c:2517 #3 0x0000000000429f5c in fe_op_search (op=3D0x28a9b10, rs=3D0x42e99ca0) at search.c:366 #4 0x00000000004298c7 in do_search (op=3D0x28a9b10, rs=3D0x42e99ca0) at search.c:217 #5 0x0000000000426952 in connection_operation (ctx=3D0x42e99df0, arg_v=3D0x28a9b10) at connection.c:1109 #6 0x0000000000426ede in connection_read_thread (ctx=3D0x42e99df0, argv=3D= 0x9) at connection.c:1245 #7 0x000000000050e33b in ldap_int_thread_pool_wrapper (xpool=3D0x26f6ea0) at tpool.c:685 #8 0x00007fddda10cfc7 in start_thread () from /lib/libpthread.so.0 #9 0x00007fddd9e8264d in clone () from /lib/libc.so.6 #10 0x0000000000000000 in ?? () 2010/11/1 <masarati(a)aero.polimi.it> > > Full_Name: Andr=E9s Marenco Z=FA=F1iga > > Version: 2.4.23 (20100719) > > OS: Debian 5.06 amd64 > > URL: > > Submission from: (NULL) (201.198.99.66) > > > > > > I'm getting a segfault while doing any search in openldap. This is my > > configuration: > > > > Debian 5.06 amd64 (kernel 2.6.26-2-amd64) > > OpenLDAP 2.4.23 (20100719) > > UnixODBC 2.3.0 > > PostgreSQL 8.2.10 > > psqlodbc 09.00.0101 > > > > > > > #########################################################################= #### > > slapd.conf (the relevant parts) > > > #########################################################################= #### > > include /var/lib/openldap/etc/openldap/schema/core.schema > > include /var/lib/openldap/etc/openldap/schema/cosine.sche= ma > > include > /var/lib/openldap/etc/openldap/schema/inetorgperson.schema > > > > pidfile /var/lib/openldap/var/slapd.pid > > argsfile /var/lib/openldap/slapd.args > > > > database sql > > suffix "dc=3Dexample,dc=3Dcom" > > rootdn "cn=3Droot,dc=3Dexample,dc=3Dcom" > > rootpw secret > > dbname PgSQL > > dbuser "" > > dbpasswd "" > > insentry_stmt "insert into ldap_entries (id,dn,oc_map_id,parent,keyval) > > values > > ((select max(id)+1 from ldap_entries),?,?,?,?)" > > upper_func "upper" > > strcast_func "text" > > concat_pattern "?||?" > > has_ldapinfo_dn_ru no > > > > lastmod off > > > > > > > > > #########################################################################= #### > > odbcinst.ini > > > #########################################################################= #### > > [PostgreSQL] > > Description=3DODBC for PostgreSQL > > Driver=3D/usr/local/lib/psqlodbcw.so > > > > > > > #########################################################################= #### > > odbc.ini > > > #########################################################################= #### > > [PgSQL] > > Driver=3D/usr/local/lib/psqlodbcw.so > > Description=3DConnection to LDAP/POSTGRESQL > > Server=3Dxxx.xxx.xxx.xxx > > Port=3D5432 > > Protocol=3D6.4 > > FetchBufferSize=3D99 > > Database=3Ddb > > Username=3Duser > > ReadOnly=3Dno > > CommLog=3D1 > > > > > > > > > > > > > > slapd starts fine, but when I make any search this is what I'm getting: > > > > <=3D send_search_entry: conn 1000 exit. > > send_ldap_result: conn=3D1000 op=3D2 p=3D3 > > send_ldap_result: err=3D0 matched=3D"" text=3D"" > > send_ldap_response: msgid=3D3 tag=3D101 err=3D0 > > ber_flush2: 14 bytes to sd 11 > > 0000: 30 0c 02 01 03 65 07 0a 01 00 04 00 04 00 > 0....e........ > > ldap_write: want=3D14, written=3D14 > > 0000: 30 0c 02 01 03 65 07 0a 01 00 04 00 04 00 > 0....e........ > > conn=3D1000 op=3D2 SEARCH RESULT tag=3D101 err=3D0 nentries=3D1 text=3D > > Segmentation Fault (Core Dumped) > > > > > > > > in the syslog this is what I have: > > > > Oct 29 17:53:17 td-server slapd[32026]: conn=3D1000 op=3D2 SEARCH RESUL= T > > tag=3D101 > > err=3D0 nentries=3D1 text=3D > > Oct 29 17:53:17 td-server kernel: [10058.462325] slapd[32029]: segfault > at > > ffffffde0274e4a0 ip 46c23b sp 425d7570 error 4 in slapd[400000+161000] > > > > > > > > and the gdb backtrace shows this: > > > > Core was generated by `/var/lib/openldap/libexec/slapd -d -1'. > > Program terminated with signal 11, Segmentation fault. > > [New process 31991] > > [New process 31987] > > [New process 31990] > > #0 0x000000000046c23b in ?? () > > #1 0x0000000000499903 in ?? () > > #2 0x000000000049e01b in ?? () > > #3 0x000000000041ed51 in ?? () > > #4 0x000000000041f54c in ?? () > > #5 0x000000000041cb5f in ?? () > > #6 0x000000000041d7dc in ?? () > > #7 0x00000000004c8760 in ?? () > > #8 0x00007fe1a4861fc7 in start_thread () from /lib/libpthread.so.0 > > #9 0x00007fe1a45d764d in clone () from /lib/libc.so.6 > > #10 0x0000000000000000 in ?? () > > This trace is useless; since the issue appears to be repeatable, you > should retry with slapd built with debugging symbols and unstripped. > > > > > > > > > > > Everything works fine in 32bits (Debian 5.0 i386), but it fails with > > 64bits. > > > > Any idea? > > > Moreover, you may want to try with HEAD code, where some modifications to > deal with 64 bit (long int) key values. Should be unrelated, but just in > case... > > p. > > > > --=20 Andr=E9s Marenco Z=FA=F1iga Equipo de Desarrollo TEC_Digital --20cf301d43804e8b0304940425e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok, thanks for the answer This is the new backtrace: Core was= generated by `./slapd -d -1'. Program terminated with signal 11, Se= gmentation fault. [New process 1656] [New process 1570] [New proce= ss 1573] #0=A0 0x0000000000491ac5 in slap_sl_free (ptr=3D0xffffffd2028b00d0, ctx=3D0= x28a3120) =A0=A0=A0 at sl_malloc.c:490 490=A0=A0=A0 =A0=A0=A0 =A0=A0= =A0 =A0=A0=A0 if ( tmpp[-1] & 1 ) { (gdb) bt #0=A0 0x000000000049= 1ac5 in slap_sl_free (ptr=3D0xffffffd2028b00d0, ctx=3D0x28a3120) =A0=A0=A0 at sl_malloc.c:490 #1=A0 0x00000000004d562e in backsql_entry_c= lean (op=3D0x28a9b10, e=3D0x42e98a40) =A0=A0=A0 at search.c:2680 #2= =A0 0x00000000004d4e8f in backsql_search (op=3D0x28a9b10, rs=3D0x42e99ca0)<= br>=A0=A0=A0 at search.c:2517 #3=A0 0x0000000000429f5c in fe_op_search (op=3D0x28a9b10, rs=3D0x42e99ca0)<= br>=A0=A0=A0 at search.c:366 #4=A0 0x00000000004298c7 in do_search (op= =3D0x28a9b10, rs=3D0x42e99ca0) =A0=A0=A0 at search.c:217 #5=A0 0x0000= 000000426952 in connection_operation (ctx=3D0x42e99df0, =A0=A0=A0 arg_v=3D0x28a9b10) at connection.c:1109 #6=A0 0x0000000000426e= de in connection_read_thread (ctx=3D0x42e99df0, argv=3D0x9) =A0=A0=A0 at= connection.c:1245 #7=A0 0x000000000050e33b in ldap_int_thread_pool_wrap= per (xpool=3D0x26f6ea0) =A0=A0=A0 at tpool.c:685 #8=A0 0x00007fddda10cfc7 in start_thread () fro= m /lib/libpthread.so.0 #9=A0 0x00007fddd9e8264d in clone () from /lib/li= bc.so.6 #10 0x0000000000000000 in ?? () <div = class=3D"gmail_quote"> 2010/11/1 <<a href=3D"mailto:masarati@aero.polimi.it"= >masarati(a)aero.polimi.it</a>> <blockquote class=3D"gmail_quote= " style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, = 204); padding-left: 1ex;"> > Full_Name: Andr=E9s Marenco Z=FA=F1iga > Version: 2.4.23 (20100719) > OS: Debian 5.06 amd64 > URL: > Submission from: (NULL) (201.198.99.66) > > > I'm getting a segfault while doing any search in openldap. This is= my > configuration: > > Debian 5.06 amd64 (kernel 2.6.26-2-amd64) > OpenLDAP 2.4.23 (20100719) > UnixODBC 2.3.0 > PostgreSQL 8.2.10 > psqlodbc 09.00.0101 > > > ######################################################################= ####### > slapd.conf (the relevant parts) > ######################################################################= ####### > include =A0 =A0 =A0 =A0 =A0 =A0 =A0 /var/lib/openldap/etc/openldap/sch= ema/core.schema > include =A0 =A0 =A0 =A0 =A0 =A0 =A0 /var/lib/openldap/etc/openldap/sch= ema/cosine.schema > include =A0 =A0 =A0 =A0 =A0 =A0 =A0 /var/lib/openldap/etc/openldap/sch= ema/inetorgperson.schema > > pidfile =A0 =A0 =A0 =A0 =A0 =A0 =A0 /var/lib/openldap/var/slapd.pid<br= > > argsfile =A0 =A0 =A0/var/lib/openldap/slapd.args > > database =A0 =A0 =A0sql > suffix =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"dc=3Dexample,dc=3Dcom&quot= ; > rootdn =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"cn=3Droot,dc=3Dexample,dc= =3Dcom" > rootpw =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0secret > dbname =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PgSQL > dbuser =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"" > dbpasswd =A0 =A0 =A0"" > insentry_stmt "insert into ldap_entries (id,dn,oc_map_id,parent,k= eyval) > values > ((select max(id)+1 from ldap_entries),?,?,?,?)" > upper_func =A0 =A0"upper" > strcast_func =A0"text" > concat_pattern =A0 =A0 =A0 =A0"?||?" > has_ldapinfo_dn_ru =A0 =A0no > > lastmod =A0 =A0 =A0 =A0 =A0 =A0 =A0 off > > > > ######################################################################= ####### > odbcinst.ini > ######################################################################= ####### > [PostgreSQL] > Description=3DODBC for PostgreSQL > Driver=3D/usr/local/lib/psqlodbcw.so > > > ######################################################################= ####### > odbc.ini > ######################################################################= ####### > [PgSQL] > Driver=3D/usr/local/lib/psqlodbcw.so > Description=3DConnection to LDAP/POSTGRESQL > Server=3Dxxx.xxx.xxx.xxx > Port=3D5432 > Protocol=3D6.4 > FetchBufferSize=3D99 > Database=3Ddb > Username=3Duser > ReadOnly=3Dno > CommLog=3D1 > > > > > > > slapd starts fine, but when I make any search this is what I'm get= ting: > > <=3D send_search_entry: conn 1000 exit. > send_ldap_result: conn=3D1000 op=3D2 p=3D3 > send_ldap_result: err=3D0 matched=3D"" text=3D""<b= r> > send_ldap_response: msgid=3D3 tag=3D101 err=3D0 > ber_flush2: 14 bytes to sd 11 > =A0 0000: =A030 0c 02 01 03 65 07 0a =A001 00 04 00 04 00 =A0 =A0 =A0 = =A0 0....e........ > ldap_write: want=3D14, written=3D14 > =A0 0000: =A030 0c 02 01 03 65 07 0a =A001 00 04 00 04 00 =A0 =A0 =A0 = =A0 0....e........ > conn=3D1000 op=3D2 SEARCH RESULT tag=3D101 err=3D0 nentries=3D1 text= =3D > Segmentation Fault (Core Dumped) > > > > in the syslog this is what I have: > > Oct 29 17:53:17 td-server slapd[32026]: conn=3D1000 op=3D2 SEARCH RESU= LT > tag=3D101 > err=3D0 nentries=3D1 text=3D > Oct 29 17:53:17 td-server kernel: [10058.462325] slapd[32029]: segfaul= t at > ffffffde0274e4a0 ip 46c23b sp 425d7570 error 4 in slapd[400000+161000]= > > > > and the gdb backtrace shows this: > > Core was generated by `/var/lib/openldap/libexec/slapd -d -1'. > Program terminated with signal 11, Segmentation fault. > [New process 31991] > [New process 31987] > [New process 31990] > #0 =A00x000000000046c23b in ?? () > #1 =A00x0000000000499903 in ?? () > #2 =A00x000000000049e01b in ?? () > #3 =A00x000000000041ed51 in ?? () > #4 =A00x000000000041f54c in ?? () > #5 =A00x000000000041cb5f in ?? () > #6 =A00x000000000041d7dc in ?? () > #7 =A00x00000000004c8760 in ?? () > #8 =A00x00007fe1a4861fc7 in start_thread () from /lib/libpthread.so.0<= br> > #9 =A00x00007fe1a45d764d in clone () from /lib/libc.so.6 > #10 0x0000000000000000 in ?? () This trace is useless; since the issue appears to be repeatable, you should retry with slapd built with debugging symbols and unstripped. > > > > > Everything works fine in 32bits (Debian 5.0 i386), but it fails with<b= r> > 64bits. > > Any idea? > Moreover, you may want to try with HEAD code, where some modifications to<b= r> deal with 64 bit (long int) key values. =A0Should be unrelated, but just in= case... p. </blockquote></div> -- Andr=E9s Marenco Z=FA= =F1iga Equipo de Desarrollo TEC_Digital --20cf301d43804e8b0304940425e5--

1 0

Re: (ITS#6691) error 4 in slapd: segfault with back-sql in debian amd64
by masarati＠aero.polimi.it 01 Nov '10

01 Nov '10

> Full_Name: Andrés Marenco Zúñiga > Version: 2.4.23 (20100719) > OS: Debian 5.06 amd64 > URL: > Submission from: (NULL) (201.198.99.66) > > > I'm getting a segfault while doing any search in openldap. This is my > configuration: > > Debian 5.06 amd64 (kernel 2.6.26-2-amd64) > OpenLDAP 2.4.23 (20100719) > UnixODBC 2.3.0 > PostgreSQL 8.2.10 > psqlodbc 09.00.0101 > > > ############################################################################# > slapd.conf (the relevant parts) > ############################################################################# > include /var/lib/openldap/etc/openldap/schema/core.schema > include /var/lib/openldap/etc/openldap/schema/cosine.schema > include /var/lib/openldap/etc/openldap/schema/inetorgperson.schema > > pidfile /var/lib/openldap/var/slapd.pid > argsfile /var/lib/openldap/slapd.args > > database sql > suffix "dc=example,dc=com" > rootdn "cn=root,dc=example,dc=com" > rootpw secret > dbname PgSQL > dbuser "" > dbpasswd "" > insentry_stmt "insert into ldap_entries (id,dn,oc_map_id,parent,keyval) > values > ((select max(id)+1 from ldap_entries),?,?,?,?)" > upper_func "upper" > strcast_func "text" > concat_pattern "?||?" > has_ldapinfo_dn_ru no > > lastmod off > > > > ############################################################################# > odbcinst.ini > ############################################################################# > [PostgreSQL] > Description=ODBC for PostgreSQL > Driver=/usr/local/lib/psqlodbcw.so > > > ############################################################################# > odbc.ini > ############################################################################# > [PgSQL] > Driver=/usr/local/lib/psqlodbcw.so > Description=Connection to LDAP/POSTGRESQL > Server=xxx.xxx.xxx.xxx > Port=5432 > Protocol=6.4 > FetchBufferSize=99 > Database=db > Username=user > ReadOnly=no > CommLog=1 > > > > > > > slapd starts fine, but when I make any search this is what I'm getting: > > <= send_search_entry: conn 1000 exit. > send_ldap_result: conn=1000 op=2 p=3 > send_ldap_result: err=0 matched="" text="" > send_ldap_response: msgid=3 tag=101 err=0 > ber_flush2: 14 bytes to sd 11 > 0000: 30 0c 02 01 03 65 07 0a 01 00 04 00 04 00 0....e........ > ldap_write: want=14, written=14 > 0000: 30 0c 02 01 03 65 07 0a 01 00 04 00 04 00 0....e........ > conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= > Segmentation Fault (Core Dumped) > > > > in the syslog this is what I have: > > Oct 29 17:53:17 td-server slapd[32026]: conn=1000 op=2 SEARCH RESULT > tag=101 > err=0 nentries=1 text= > Oct 29 17:53:17 td-server kernel: [10058.462325] slapd[32029]: segfault at > ffffffde0274e4a0 ip 46c23b sp 425d7570 error 4 in slapd[400000+161000] > > > > and the gdb backtrace shows this: > > Core was generated by `/var/lib/openldap/libexec/slapd -d -1'. > Program terminated with signal 11, Segmentation fault. > [New process 31991] > [New process 31987] > [New process 31990] > #0 0x000000000046c23b in ?? () > #1 0x0000000000499903 in ?? () > #2 0x000000000049e01b in ?? () > #3 0x000000000041ed51 in ?? () > #4 0x000000000041f54c in ?? () > #5 0x000000000041cb5f in ?? () > #6 0x000000000041d7dc in ?? () > #7 0x00000000004c8760 in ?? () > #8 0x00007fe1a4861fc7 in start_thread () from /lib/libpthread.so.0 > #9 0x00007fe1a45d764d in clone () from /lib/libc.so.6 > #10 0x0000000000000000 in ?? () This trace is useless; since the issue appears to be repeatable, you should retry with slapd built with debugging symbols and unstripped. > > > > > Everything works fine in 32bits (Debian 5.0 i386), but it fails with > 64bits. > > Any idea? > Moreover, you may want to try with HEAD code, where some modifications to deal with 64 bit (long int) key values. Should be unrelated, but just in case... p.

1 0

(ITS#6691) error 4 in slapd: segfault with back-sql in debian amd64
by andresmarenco＠gmail.com 29 Oct '10

29 Oct '10

Full_Name: Andrés Marenco Zúñiga Version: 2.4.23 (20100719) OS: Debian 5.06 amd64 URL: Submission from: (NULL) (201.198.99.66) I'm getting a segfault while doing any search in openldap. This is my configuration: Debian 5.06 amd64 (kernel 2.6.26-2-amd64) OpenLDAP 2.4.23 (20100719) UnixODBC 2.3.0 PostgreSQL 8.2.10 psqlodbc 09.00.0101 ############################################################################# slapd.conf (the relevant parts) ############################################################################# include /var/lib/openldap/etc/openldap/schema/core.schema include /var/lib/openldap/etc/openldap/schema/cosine.schema include /var/lib/openldap/etc/openldap/schema/inetorgperson.schema pidfile /var/lib/openldap/var/slapd.pid argsfile /var/lib/openldap/slapd.args database sql suffix "dc=example,dc=com" rootdn "cn=root,dc=example,dc=com" rootpw secret dbname PgSQL dbuser "" dbpasswd "" insentry_stmt "insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values ((select max(id)+1 from ldap_entries),?,?,?,?)" upper_func "upper" strcast_func "text" concat_pattern "?||?" has_ldapinfo_dn_ru no lastmod off ############################################################################# odbcinst.ini ############################################################################# [PostgreSQL] Description=ODBC for PostgreSQL Driver=/usr/local/lib/psqlodbcw.so ############################################################################# odbc.ini ############################################################################# [PgSQL] Driver=/usr/local/lib/psqlodbcw.so Description=Connection to LDAP/POSTGRESQL Server=xxx.xxx.xxx.xxx Port=5432 Protocol=6.4 FetchBufferSize=99 Database=db Username=user ReadOnly=no CommLog=1 slapd starts fine, but when I make any search this is what I'm getting: <= send_search_entry: conn 1000 exit. send_ldap_result: conn=1000 op=2 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=3 tag=101 err=0 ber_flush2: 14 bytes to sd 11 0000: 30 0c 02 01 03 65 07 0a 01 00 04 00 04 00 0....e........ ldap_write: want=14, written=14 0000: 30 0c 02 01 03 65 07 0a 01 00 04 00 04 00 0....e........ conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Segmentation Fault (Core Dumped) in the syslog this is what I have: Oct 29 17:53:17 td-server slapd[32026]: conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 29 17:53:17 td-server kernel: [10058.462325] slapd[32029]: segfault at ffffffde0274e4a0 ip 46c23b sp 425d7570 error 4 in slapd[400000+161000] and the gdb backtrace shows this: Core was generated by `/var/lib/openldap/libexec/slapd -d -1'. Program terminated with signal 11, Segmentation fault. [New process 31991] [New process 31987] [New process 31990] #0 0x000000000046c23b in ?? () #1 0x0000000000499903 in ?? () #2 0x000000000049e01b in ?? () #3 0x000000000041ed51 in ?? () #4 0x000000000041f54c in ?? () #5 0x000000000041cb5f in ?? () #6 0x000000000041d7dc in ?? () #7 0x00000000004c8760 in ?? () #8 0x00007fe1a4861fc7 in start_thread () from /lib/libpthread.so.0 #9 0x00007fe1a45d764d in clone () from /lib/libc.so.6 #10 0x0000000000000000 in ?? () Everything works fine in 32bits (Debian 5.0 i386), but it fails with 64bits. Any idea?

1 0

(ITS#6690) ldap_result & LDAP_TIMEOUT
by greg.silverman＠webex.com 29 Oct '10

29 Oct '10

Full_Name: Greg Silverman Version: 2.4.23 OS: CentOS 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.69.115.12) At result.c, line 438, ldap_result will return 0==LDAP_SUCCESS even though there was a timeout error, ld_errno==LDAP_TIMEOUT

1 0

Re: (ITS#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database
by mark.cave-ayland＠siriusit.co.uk 29 Oct '10

29 Oct '10

Hi all, An update on this bug report: with a modified slapd.conf and a small patch to the back-perl module, I can use the ACL mask to ensure that the perl search function doesn't get invoked if disallowed by the ACLs. The patch works by creating a "fake" empty entry whose DN is the base of the search, and then passing this entry into access_allowed() using code borrowed from one of the other backends to either deny or allow access. http://pastebin.siriusit.co.uk/perlacl/slapd2.conf http://pastebin.siriusit.co.uk/perlacl/openldap-backperl-acls.patch Is this something that could be considered for inclusion upstream or does it require more work? ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

Re: (ITS#6686) VLV overlay fails to handle multiple search operations per LDAP connection
by hyc＠symas.com 29 Oct '10

29 Oct '10

Sebastien Bahloul wrote: > Hi Howard, > > Le mercredi 27 octobre 2010 15:03:36, Howard Chu a écrit : >> sebastien.bahloul(a)gmail.com wrote: >>> Full_Name: Sebastien Bahloul >>> Version: HEAD >>> OS: Linux RHEL 5 >>> URL: >>> Submission from: (NULL) (109.197.176.10) >>> >>> >>> Hi, >>> >>> I think there is a bug / limitation inside VLV implementation : it can >>> not handle multiple search operation on a single connection. The first >>> operation succeeds and next operations fail with the following message : >>> >>> LDAP: error code 51 - Other sort requests already in progress >>> >>> But I think this issue is more global. This implementation seems to be >>> able to only handle a single VLV context per connection. >> >> Correct, that is by design. >> >>> If I am right, this is related with the indexing method of sort_conns >>> structure which seems to be based only on the connection id. I suggest >>> to implement a double indexing array by connection id / VLV context id. >> >> I have no interest in extending this. It would require much more overhead >> to protect the slapd from getting overloaded by too many such requests. > > In fact my suggestion was a question : I would like to contribute a patch to > add support for this way of using VLV. Is this feature extension as a double > indexed array an acceptable implementation from your point of vue ? To avoid > encountering such performance issues, I would add a new sssvlv parameter that > would authorize by default only a single VLV search request per connection. I guess as long as you observe the svi_max config parameter, there's no reason not to adopt your suggestion. Feel free to followup here with your patch for review. -- -- 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#6689) Patch - Mozilla NSS - support cert database prefix
by hyc＠symas.com 29 Oct '10

29 Oct '10

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.23 (current CVS HEAD) > OS: RHEL5 > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-moznssdbprefix-20101028.pat… > Submission from: (NULL) (76.113.111.209) Thanks for the patch, committed to HEAD. > > Mozilla NSS supports having multiple cert/key databases in the same directory, > each one having a unique string prefix e.g. > slapd-01-cert8.db - the prefix here is "slapd-01-" > This patch allows the user to pass in the prefix as the last part of the > cacertdir. If the given cacertdir does not exist (neither a file nor a > directory), and contains the platform's path separator character (e.g. '/'), > look at the last occurance of the path separator in the string - if it exists > and there is something after that, assume that is the prefix. > > This patch also cleans up some compiler warnings about unused variables and > signedness differences, and removes a very annoying debug message. > > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat. Red Hat has not assigned rights > and/or interest in this work to any party. I, Rich Megginson am > authorized by Red Hat, my employer, to release this work under the > following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose > with or without attribution and/or other notice. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6689) Patch - Mozilla NSS - support cert database prefix
by rmeggins＠redhat.com 28 Oct '10

28 Oct '10

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL5 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-moznssdbprefix-20101028.pat… Submission from: (NULL) (76.113.111.209) Mozilla NSS supports having multiple cert/key databases in the same directory, each one having a unique string prefix e.g. slapd-01-cert8.db - the prefix here is "slapd-01-" This patch allows the user to pass in the prefix as the last part of the cacertdir. If the given cacertdir does not exist (neither a file nor a directory), and contains the platform's path separator character (e.g. '/'), look at the last occurance of the path separator in the string - if it exists and there is something after that, assume that is the prefix. This patch also cleans up some compiler warnings about unused variables and signedness differences, and removes a very annoying debug message. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

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