- openldap-bugs - openldap.org

(ITS#6694) poor "unchecked" sizelimit doc
by h.b.furuseth＠usit.uio.no 03 Nov '10

03 Nov '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Both the admin guide and man slapd.conf(5) could use improved "unchecked"/"pr" sizelimit documentation. That is, they could mention a few more places that a statement like "sizelimit unlimited" does not set the unchecked limit, so if you override limits set elsewhere, you need to explicitly override your unchecked setting. Admin guide: 9.3. Global Limits. 9.4.3. Specifying size limits which does not mention that the default sets soft,hard. Also the 9.4.3 syntax is wrong - doesn't mention .pr - as the very next paragraph says. Same thing applies to the manpage. Man page: 'sizelimit': does not mention that default is soft,hard. 'limits': says this at the very end - could move it up. And split into several paragraphs.

1 0

(ITS#6693) Value dependent ACL issues
by ralf＠OpenLDAP.org 03 Nov '10

03 Nov '10

Full_Name: Ralf Haferkamp Version: 2.4.23, HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.54.248) Submitted by: ralf It seems that if the first ACL on a server is a value dependend ACL it is not evaluated correctly. Steps to reproduce: 1. Set this global ACL on the server: access to dn.base="" attrs=supportedControl val/objectIdentifierMatch=1.3.6.1.4.1.4203.666.5.14 by * none access to dn.base="" by * read Now, when "1.3.6.1.4.1.4203.666.5.14" would be the first value of the supportedControl Attribute that the server would return, slapd will return no value of that attribute at all. OTOH when "1.3.6.1.4.1.4203.666.5.14" is not the first value, slapd will return all values of the "supportedControl" Attribute, including "1.3.6.1.4.1.4203.666.5.14". The expected result would be to return all values but "1.3.6.1.4.1.4203.666.5.14". This problem only seems to be present if there are no other ACLs present before the first value dependent ACL. This patch seems to fix the problem, it would be nice however if somebody with more insight into the acl code could review it before we commit it to HEAD. ------------------------------------------------------------- --- a/servers/slapd/acl.c +++ b/servers/slapd/acl.c @@ -405,7 +405,8 @@ access_allowed_mask( if ( state->as_desc == desc && state->as_access == access && state->as_result != -1 && - state->as_vd_acl == NULL ) + state->as_vd_acl == NULL && + state->as_vd_acl_count > 0 ) { Debug( LDAP_DEBUG_ACL, "=> access_allowed: result was in cache (%s)\n", ------------------------------------------------------------- thanks, Ralf

1 0

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

(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

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 28 Oct '10

28 Oct '10

--On Wednesday, October 27, 2010 4:54 PM +0000 quanah(a)zimbra.com wrote: > > If anyone else has some thoughts on why the entry cache is growing > unbounded, much appreciated. Just a further note -- To reproduce this, you have to have more than 2 cores. My system has 6, I don't know what the lower limit is (3,4, or 5) for reproduction. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6687) slaptest: bad configuration file!
by quanah＠zimbra.com 28 Oct '10

28 Oct '10

--On Wednesday, October 27, 2010 3:22 PM +0000 rakesh.rai(a)alico.com wrote: If you need help using and configuring OpenLDAP, then email openldap-technical(a)openldap.org. The ITS system is not the appropriate place for these types of questions. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

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

28 Oct '10

Full_Name: Mark Cave-Ayland Version: 2.4.23 OS: Linux/Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.187.123.11) Hi all, We have an issue on one of our production systems whereby openldap is not enforcing the ACLs on a back-perl subordinate database. In this particular system, the membership of certain groups stored within LDAP is determined by some customised logic in a Perl module which dynamically generates LDAP objects with posixGroup/groupOfNames entries conditionally based upon the values of existing LDAP attributes within the tree. However, since these internal LDAP attribute lookups can be quite slow, we wish to hide them from all but a small minority of bind DNs. Unfortunately what we are finding is that the back-perl module is not respecting the ACLs in slapd.conf. The following files can be used to reproduce this issue with openldap 2.4.23: http://pastebin.siriusit.co.uk/perlacl/slapd.conf http://pastebin.siriusit.co.uk/perlacl/perlacl.ldif http://pastebin.siriusit.co.uk/perlacl/PerlACL.pm The password for both the "cn=admin,dc=my-domain,dc=com" and the "cn=restricted,dc=my-domain,dc=com" DNs is secret. The ACLs in the above slapd.conf look like this: access to dn.subtree="ou=perl,dc=my-domain,dc=com" by dn="cn=admin,dc=my-domain,dc=com" read by dn="cn=restricted,dc=my-domain,dc=com" none access to dn.subtree="ou=hidden,dc=my-domain,dc=com" by dn="cn=admin,dc=my-domain,dc=com" read by dn="cn=restricted,dc=my-domain,dc=com" none access to * by dn="cn=admin,dc=my-domain,dc=com" write by dn="cn=restricted,dc=my-domain,dc=com" read by * auth Using these ACLs, I would expect that cn=admin should be able to read the whole directory, whereas cn=restricted should not be able to see either the "ou=hidden,dc=my-domain,dc=com" DN subtree nor the "ou=perl,dc=my-domain,dc=com" DN subtree. However, performing an LDAP search binding as cn=restricted gives the following output: build@zeno:~$ ldapsearch -LLL -H ldap://localhost:10389 -D 'cn=restricted,dc=my-domain,dc=com' -b 'dc=my-domain,dc=com' -xW Enter LDAP Password: dn: dc=my-domain,dc=com objectClass: top objectClass: dcObject objectClass: organization o:: bXlkb21haW4uY29tIA== dc: my-domain dn: ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: real dn: ou=realtest1,ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: realtest1 dn: ou=realtest2,ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: realtest2 dn: ou=realtest3,ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: realtest3 dn: ou=realtest4,ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: realtest4 dn: ou=realtest5,ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: realtest5 dn: cn=restricted,dc=my-domain,dc=com objectClass: simpleSecurityObject objectClass: organizationalRole cn: restricted description: restricted user userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9 dn: cn=admin,dc=my-domain,dc=com objectClass: simpleSecurityObject objectClass: organizationalRole cn:: YWRtaW4g description: admin user userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9 dn: ou=perltest5,ou=perl,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: perltest5 dn: ou=perltest4,ou=perl,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: perltest4 dn: ou=perltest3,ou=perl,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: perltest3 dn: ou=perltest2,ou=perl,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: perltest2 dn: ou=perltest1,ou=perl,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: perltest1 In other words, the "ou=hidden,dc=my-domain,dc=com" subtree is correctly hidden from the cn=restricted user, whereas the "ou=perl,dc=my-domain,dc=com" subtree is not.

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 27 Oct '10

27 Oct '10

--On Thursday, September 30, 2010 4:59 PM +0000 quanah(a)zimbra.com wrote: > --On Thursday, September 30, 2010 11:14 AM +0000 masarati(a)aero.polimi.it > wrote: > >> There's no mention of overlays; I was wondering whether or not it could >> be related to some adverse interaction, e.g. with sssvlv, which has some >> paged-results specific code. Can you also post on overlays either global >> or specific to "olcDatabase={2}hdb"? > > There are no overlays being used. ;) As I said, a very vanilla config. Howard and I continue to examine this problem, but as yet, have found no solution nor insight into why the problem exists. It has nothing to do with paged results, and you can see the behavior relatively easily with a smaller DB than I was working with. Right now, I'm using a 1 million entry DB. If I execute two concurrent searches of the database with a 25,000 entry cache limit, that frees 1,000 entries on purge, at the end of those searches, we end up with: counted 1000087 entryInfos and 114476 entries, 0 notcached What this shows is that after the search completed, there are 114,476 entries in the entry cache, even though it only reports between 24,000 and 25,000. Repeated additional searches will continue to increase the number of cached entries until all memory is exhausted. The following code is used to count up the cached entries, and it is called from inside gdb via: call bdb_lru_count(&bdb->bi_cache) --- openldap-2.4.23/servers/slapd/back-bdb/cache.c.orig 2010-10-05 16:20:27.085259568 -0700 +++ openldap-2.4.23/servers/slapd/back-bdb/cache.c 2010-10-05 16:21:03.655255057 -0700 @@ -1530,6 +1530,35 @@ } #ifdef LDAP_DEBUG +static void +bdb_lru_count( Cache *cache ) +{ + EntryInfo *e; + int ei = 0, ent = 0, nc = 0; + + for ( e = cache->c_lrutail; ; ) { + ei++; + if ( e->bei_e ) { + ent++; + if ( e->bei_state & CACHE_ENTRY_NOT_CACHED ) + nc++; + } + e = e->bei_lrunext; + if ( e == cache->c_lrutail ) + break; + } + fprintf( stderr, "counted %d entryInfos and %d entries, %d notcached\n", + ei, ent, nc ); + ei = 0; + for ( e = cache->c_lrutail; ; ) { + ei++; + e = e->bei_lruprev; + if ( e == cache->c_lrutail ) + break; + } + fprintf( stderr, "counted %d entryInfos (on lruprev)\n", ei ); +} + #ifdef SLAPD_UNUSED static void bdb_lru_print( Cache *cache ) If anyone else has some thoughts on why the entry cache is growing unbounded, much appreciated. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6684)
by norbert＠pueschel.net 27 Oct '10

27 Oct '10

Updated TAR-file with (hopefully) sufficient copyright notice... http://www.pueschel.net/openldap/norbert-pueschel-autogroup-27102010.tar

1 0

(ITS#6687) slaptest: bad configuration file!
by rakesh.rai＠alico.com 27 Oct '10

27 Oct '10

Full_Name: Rakesh Version: 2.4.23 OS: Microsoft windows XP 2002 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (167.230.38.120) When I try to test OpenLdap it gives me an error as shown below. Have setup SYSCONFDIR in path and still I get this issue. C:\OpenLDAP>slaptest could not stat config file "%SYSCONFDIR%\slapd.conf": No such file or directory (2) slaptest: bad configuration file!

1 0

Re: (ITS#6686) VLV overlay fails to handle multiple search operations per LDAP connection
by sebastien.bahloul＠gmail.com 27 Oct '10

27 Oct '10

Hi Howard, Le mercredi 27 octobre 2010 15:03:36, Howard Chu a =E9crit : > sebastien.bahloul(a)gmail.com wrote: > > Full_Name: Sebastien Bahloul > > Version: HEAD > > OS: Linux RHEL 5 > > URL: > > Submission from: (NULL) (109.197.176.10) > >=20 > >=20 > > Hi, > >=20 > > 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 : > >=20 > > LDAP: error code 51 - Other sort requests already in progress > >=20 > > But I think this issue is more global. This implementation seems to be > > able to only handle a single VLV context per connection. >=20 > Correct, that is by design. >=20 > > 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. >=20 > 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 t= o=20 add support for this way of using VLV. Is this feature extension as a doubl= e=20 indexed array an acceptable implementation from your point of vue ? To avoi= d=20 encountering such performance issues, I would add a new sssvlv parameter th= at=20 would authorize by default only a single VLV search request per connection. Regards, =2D-=20 Sebastien Bahloul @: sebastien.bahloul(a)gmail.com

1 0

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

27 Oct '10

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs