openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

Re: (ITS#6692) LDAP_INAPPROPRIATE_MATCHING not returned when faced with an unsupported extensible match
by doug.leavitt＠oracle.com 02 Nov '10

02 Nov '10

Thanks Kurt. I missed seeing that part of the spec. Doug. On 11/ 2/10 01:33 PM, Kurt Zeilenga wrote: > On Nov 2, 2010, at 10:59 AM, doug.leavitt(a)oracle.com wrote: > >> Full_Name: Doug Leavitt >> Version: HEAD >> OS: Solaris >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (192.18.43.225) >> >> >> It seems that slapd is returning success if an unsupported extensible match >> is given. Probably LDAP_INAPPROPRIATE_MATCHING or maybe >> LDAP_UNAVAILABLE_CRITICAL_EXTENSION chould be returned. Instead. > Per RFC 4511, Section 4.5.1.7, no. > > -- Kurt >

1 0

Re: (ITS#6692) LDAP_INAPPROPRIATE_MATCHING not returned when faced with an unsupported extensible match
by Kurt＠OpenLDAP.org 02 Nov '10

02 Nov '10

On Nov 2, 2010, at 10:59 AM, doug.leavitt(a)oracle.com wrote: > Full_Name: Doug Leavitt > Version: HEAD > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.18.43.225) > > > It seems that slapd is returning success if an unsupported extensible match > is given. Probably LDAP_INAPPROPRIATE_MATCHING or maybe > LDAP_UNAVAILABLE_CRITICAL_EXTENSION chould be returned. Instead. Per RFC 4511, Section 4.5.1.7, no. -- Kurt

1 0

(ITS#6692) LDAP_INAPPROPRIATE_MATCHING not returned when faced with an unsupported extensible match
by doug.leavitt＠oracle.com 02 Nov '10

02 Nov '10

Full_Name: Doug Leavitt Version: HEAD OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.18.43.225) It seems that slapd is returning success if an unsupported extensible match is given. Probably LDAP_INAPPROPRIATE_MATCHING or maybe LDAP_UNAVAILABLE_CRITICAL_EXTENSION chould be returned. Instead. Example: Attempting a search using the MS LDAP_MATCHING_RULE_IN_CHAIN extensible match rule: http://msdn.microsoft.com/en-us/library/aa746475%28VS.85%29.aspx OID: 1.2.840.113556.1.4.194 Should fail since it is currently unsupported by OpenLDAP. Something like: ldapsearch -v -h <server> -D <admin dn> -w <admin pw> -b <base> "memberof:1.2.840.113556.1.4.1941:=cn=ldap_many1,dc=mc,dc=sun,dc=com" Should return error, but instead returns success with 0 matches. I believe that the root of the problem is that in servers/slapd/filter.c: case LDAP_FILTER_EXT: Debug( LDAP_DEBUG_FILTER, "EXTENSIBLE\n", 0, 0, 0 ); err = get_mra( op, ber, &f, text ); if ( err != LDAP_SUCCESS ) { break; >>> err is returned with the value LDAP_INAPPROPRIATE_MATCHING } assert( f.f_mra != NULL ); break; default: (void) ber_scanf( ber, "x" ); /* skip the element */ Debug( LDAP_DEBUG_ANY, "get_filter: unknown filter type=%lu\n", f.f_choice, 0, 0 ); f.f_choice = SLAPD_FILTER_COMPUTED; f.f_result = SLAPD_COMPARE_UNDEFINED; break; } >>> and will return LDAP_SUCCESS with the following: if( err != LDAP_SUCCESS && err != SLAPD_DISCONNECT ) { /* ignore error */ *text = NULL; f.f_choice = SLAPD_FILTER_COMPUTED; f.f_result = SLAPD_COMPARE_UNDEFINED; err = LDAP_SUCCESS; } which will allow the filter to proceed, loosing the error. It seems like the search should fail given an illegal/unsupported extensible filter.

1 0

Re: (ITS#6690) ldap_result & LDAP_TIMEOUT
by hyc＠symas.com 02 Nov '10

02 Nov '10

greg.silverman(a)webex.com wrote: > 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 > The return code from ldap_result is not return an LDAP success code. There is no bug here, this ITS will be closed. -- -- 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#6691) error 4 in slapd: segfault with back-sql in debian amd64
by masarati＠aero.polimi.it 02 Nov '10

02 Nov '10

Looks like a duplicate of ITS#6657; I have already investigated that bug to no avail. Apparently, a pointer to stack-residing data is erroneously freed. You may be able to find out more info by checking where this happens from the core. I can't take care of this issue right now as I'd need to give it incredibly low priority. p. > 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=0xffffffd2028b00d0, > ctx=0x28a3120) > at sl_malloc.c:490 > 490 if ( tmpp[-1] & 1 ) { > (gdb) bt > #0 0x0000000000491ac5 in slap_sl_free (ptr=0xffffffd2028b00d0, > ctx=0x28a3120) > at sl_malloc.c:490 > #1 0x00000000004d562e in backsql_entry_clean (op=0x28a9b10, e=0x42e98a40) > at search.c:2680 > #2 0x00000000004d4e8f in backsql_search (op=0x28a9b10, rs=0x42e99ca0) > at search.c:2517 > #3 0x0000000000429f5c in fe_op_search (op=0x28a9b10, rs=0x42e99ca0) > at search.c:366 > #4 0x00000000004298c7 in do_search (op=0x28a9b10, rs=0x42e99ca0) > at search.c:217 > #5 0x0000000000426952 in connection_operation (ctx=0x42e99df0, > arg_v=0x28a9b10) at connection.c:1109 > #6 0x0000000000426ede in connection_read_thread (ctx=0x42e99df0, > argv=0x9) > at connection.c:1245 > #7 0x000000000050e33b in ldap_int_thread_pool_wrapper (xpool=0x26f6ea0) > 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é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. >> >> >> >> > > > -- > Andrés Marenco Zúñiga > Equipo de Desarrollo > TEC_Digital >

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

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

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