openldap-bugs July 2015

openldap-bugs@openldap.org

24 participants
75 discussions

Re: (ITS#8202) openldap assumes printf has %z
by h.b.furuseth＠usit.uio.no 21 Jul '15

21 Jul '15

If we require C99 library features like this, then I think we should add a configure test for them. Strange breakage at runtime is rather worse than a failed build. (That's not the same as testing for a C99 compiler, since one can have a C99 compiler like gcc with a C90 library.)

1 0

Re: (ITS#8202) openldap assumes printf has %z
by hyc＠symas.com 21 Jul '15

21 Jul '15

Howard Chu wrote: > iand(a)ekit-inc.com wrote: >> Full_Name: Ian Donaldson >> Version: 2.4.41 >> OS: Solaris 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (60.241.85.68) >> >> >> Built 2.4.41 on Solaris 9; ran 'make check' which failed to start slapd with >> the following errors: > > Thanks for the report. Not sure that it's worth our taking any action though. > The last release of Solaris 9 was 10 years ago, and it has been end-of-life'd > by Oracle. For reference: Solaris 9 EOL http://www.oracle.com/technetwork/server-storage/solaris10/overview/index-1… In short it means Solaris 9 is no longer eligible for any Oracle updates including security updates, fixes, patches or any other changes. Solaris 9 went into sustaining support in October 2014. Since Oracle is no longer providing any patches for this OS, I don't see much reason for us to either. Fortunately you are free to patch and build OpenLDAP for yourself for as long as you wish. -- -- 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#8199) Crash when modifying the first olcAttributeTypes element in olcSchemaConfig objectClass
by luca.bruno＠rocket-internet.de 19 Jul '15

19 Jul '15

On Friday 17 July 2015 16:19:16 Ryan Tandy wrote: > On Tue, Jul 14, 2015 at 11:13:56AM +0000, luca.bruno(a)rocket-internet.de wrote: > >slapd 2.4.40 realiably crashes when modifying the 0th olcAttributeTypes > >element in a olcSchemaConfig object. > > This doesn't match my experience exactly, but if you were editing the > config with some tool, it might reflect how that tool implements > modifications. For a more specific background, this was Apache Directory Studio (pre-)2 doing schema changes on the debian backports 2.4.40 on wheezy (amd64). IIRC it does in fact synthesize a batch-modify of schema entries. > This was already fixed for olcObjectClasses in ITS#5388. I've pushed a > patch doing the same for at_next, can you please verify it? > > http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=patch;h=b48d0169d0 > 4824f83c0e0855eea4d6429740cf08 I'll try to apply that patch on top of my current setup and see if it stops crashing without any other regression. Thanks, Luca -- Luca Bruno (kaeso) Security Engineer Rocket Internet SE -> GPG: 0xBB1A3A854F3BBEBF

1 0

Re: (ITS#8202) openldap assumes printf has %z
by hyc＠symas.com 19 Jul '15

19 Jul '15

iand(a)ekit-inc.com wrote: > Full_Name: Ian Donaldson > Version: 2.4.41 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (60.241.85.68) > > > Built 2.4.41 on Solaris 9; ran 'make check' which failed to start slapd with > the following errors: Thanks for the report. Not sure that it's worth our taking any action though. The last release of Solaris 9 was 10 years ago, and it has been end-of-life'd by Oracle. > 55ab70f0 config_build_entry: "olcDatabase={-1}frontend" > 55ab70f0 config_build_entry: "olcDatabase={0}config" > 55ab70f0 config_build_entry: "olcDatabase={1}bdb" > 55ab70f0 config_build_attrs: error 21 on olcDbCacheSize value #0 > 55ab70f0 config_build_entry: build "zu" failed: "" > > Eventually found this to be due to the assumption that %z format > works in printf; this is not the case on Solaris 9. (Solaris 10 has %z) > > Found the following code that makes this assumption (there may be others): > > ./libraries/liblmdb/mdb_load.c > ./libraries/liblmdb/mdb_dump.c > ./libraries/liblmdb/mdb_stat.c > ./libraries/liblmdb/mdb.c > ./servers/slapd/overlays/constraint.c > ./servers/slapd/config.c > > My workaround was to use %l instead of %z which works for me; may not > be 100% fix though. > > See http://stackoverflow.com/questions/2524611/how-to-print-size-t-variable-por… > > > I previously built 2.4.33 which has some %z'isms too but not in places > that cause 'make check' to fail. > > -- -- 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#8202) openldap assumes printf has %z
by iand＠ekit-inc.com 19 Jul '15

19 Jul '15

Full_Name: Ian Donaldson Version: 2.4.41 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (60.241.85.68) Built 2.4.41 on Solaris 9; ran 'make check' which failed to start slapd with the following errors: 55ab70f0 config_build_entry: "olcDatabase={-1}frontend" 55ab70f0 config_build_entry: "olcDatabase={0}config" 55ab70f0 config_build_entry: "olcDatabase={1}bdb" 55ab70f0 config_build_attrs: error 21 on olcDbCacheSize value #0 55ab70f0 config_build_entry: build "zu" failed: "" Eventually found this to be due to the assumption that %z format works in printf; this is not the case on Solaris 9. (Solaris 10 has %z) Found the following code that makes this assumption (there may be others): ./libraries/liblmdb/mdb_load.c ./libraries/liblmdb/mdb_dump.c ./libraries/liblmdb/mdb_stat.c ./libraries/liblmdb/mdb.c ./servers/slapd/overlays/constraint.c ./servers/slapd/config.c My workaround was to use %l instead of %z which works for me; may not be 100% fix though. See http://stackoverflow.com/questions/2524611/how-to-print-size-t-variable-por… I previously built 2.4.33 which has some %z'isms too but not in places that cause 'make check' to fail.

1 0

Re: (ITS#8111) Re-ordering schema attributeTypes crashes slapd
by ryan＠nardis.ca 17 Jul '15

17 Jul '15

Hi Zach, I just pushed a patch for another ITS that reminded me of this one. Assuming you can still reproduce this, would you please try the patch mentioned at the end of http://www.openldap.org/its/?findid=8199 and let us know whether it resolves your crash?

1 0

Re: (ITS#8199) Crash when modifying the first olcAttributeTypes element in olcSchemaConfig objectClass
by ryan＠nardis.ca 17 Jul '15

17 Jul '15

On Tue, Jul 14, 2015 at 11:13:56AM +0000, luca.bruno(a)rocket-internet.de wrote: >slapd 2.4.40 realiably crashes when modifying the 0th olcAttributeTypes element >in a olcSchemaConfig object. This doesn't match my experience exactly, but if you were editing the config with some tool, it might reflect how that tool implements modifications. I reproduced the crash with the following changeset: dn: cn={2}nis,cn=schema,cn=config changetype: modify replace: olcAttributeTypes olcAttributeTypes: {1}( 1.3.6.1.1.1.1.3 NAME 'homeDirectory' DESC 'The absolute path to the home directory' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) Deleting all values clears c_at_head and c_at_tail (bconfig.c:1541). Adding a specific non-zero index assumes the head is already valid. This was already fixed for olcObjectClasses in ITS#5388. I've pushed a patch doing the same for at_next, can you please verify it? http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=patch;h=b48d0169d…

1 0

(ITS#8173)
by Adrian.Raemy＠vtg.admin.ch 17 Jul '15

17 Jul '15

Dear Howard, We didn't use back-ldap as proxy backend in the past, we had a very old ope= nldap and did use syncrepl.=20 Then we changed our IT Infrastructures and had to use ldap proxy. That was = around 3 months ago. So we tried with 2.4.26 coming from sles and there we had the problem..so w= e tried then with the latest release and with both it was the same. Thanks a lot for your FIX. Actually it looks like working fine, the slapd of the ldap proxy didn't cra= sh anymore since 24 hours. No segfaults at the moment. We will monitor it next few days and weeks and if you like we can give you = again a feedback. ITS#8173 fix SEGV after failed retry [openldap.git] / servers / slapd / back-ldap / bind.c diff --git a/servers/slapd/back-ldap/bind.c b/servers/slapd/back-ldap/bind.= c index 598dae3..20197f3 100644 (file) --- a/servers/slapd/back-ldap/bind.c +++ b/servers/slapd/back-ldap/bind.c @@ -271,6 +271,8 @@ retry:; =20 if ( ldap_back_retry( &lc, op, rs, LDAP_BACK_BIND_SERR ) ) { = =20 goto retry; } + if ( !lc ) + return( rc ); =20 } ldap_pvt_thread_mutex_lock( &li->li_counter_mutex );

1 0

(ITS#8201) Enhancement: thread stack overrun detection
by hyc＠openldap.org 16 Jul '15

16 Jul '15

Full_Name: Howard Chu Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.231.135) Submitted by: hyc Have been looking at some puzzling SEGVs where none of the addresses in the core dump backtrace appear to be invalid. Suspecting a thread stack overrun. Normally pthreads allocates a 1-page guard at the end of the requested thread stack. (This is a page of memory mprotect'd to deny any access, so spilling into it should cause a SEGV.) It's possible for some overruns to skip over this guard page, e.g. if they occur in a function that has a local variable larger than 1 page in size. Adding a feature to set the guard region size to be equal to the original thread stack size. (E.g., 8MB on 64 bit builds.) This should help catch the more elusive overrun cases. The feature will be enabled by setting the LDAPSTACKGUARD environment variable (to anything, the value is ignored).

1 0

Re: (ITS#8173)
by hyc＠symas.com 15 Jul '15

15 Jul '15

Adrian.Raemy(a)vtg.admin.ch wrote: > --_000_BE8E19527611BA409D68FF6EA186AF9002A2A6AABEREXMBX19ifc1i_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Dear Howard, > > Below the bt full with Openldap 2.4.40 built with "-g" flag. > Let me know if you need more...hope you have a solution for the problem bec= > ause it is really a Problem for us.. If it was such a big problem, why did you not report it when you first encountered it in 2.4.26, which was released over 4 years ago? You waited this long, clearly it's not that high a priority. That makes it even less of a priority for an open source project comprised of volunteers who have their own interests to pursue. Your repeating how big a problem you perceive it to be only comes across as whining, which makes folks even less interested in helping. > slapd of backend ldap crashes 4-5 times per day. Fixed now in git master. Please test and reply back with your results. > Regards > Adrian > > warning: Could not load shared library symbols for stics. > Do you need "set solib-search-path" or "set sysroot"? > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > Core was generated by `/usr/lib/openldap/slapd -h ldap://0.0.0.0:389 ldap= > s://0.0.0.0:636 -f /etc/op'. > Program terminated with signal 11, Segmentation fault. > #0 0x00007fcbb60572c6 in ldap_back_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcba= > d881a30) at bind.c:319 > 319 bind.c: No such file or directory. > (gdb) bt full > #0 0x00007fcbb60572c6 in ldap_back_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcba= > d881a30) at bind.c:319 > li =3D 0x7fcbb6443e40 > lc =3D 0x0 > ctrls =3D 0x0 > save_o_dn =3D {bv_len =3D 0, bv_val =3D 0x0} > save_o_do_not_cache =3D 0 > rc =3D 52 > msgid =3D 2 > retrying =3D LDAP_BACK_DONTSEND > __PRETTY_FUNCTION__ =3D "ldap_back_bind" > #1 0x00007fcbb5f47fcb in fe_op_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcbad881= > a30) at bind.c:383 > bd =3D 0x7fcbad881750 > #2 0x00007fcbb5fb66fd in overlay_op_walk (op=3D0x7fcbb6c0dc00, rs=3D0x7fcb= > ad881a30, which=3Dop_bind, oi=3D0x7fcbb6443430, on=3D0x0) at backover.c:671 > func =3D 0x7fcbb6343ad8 <slap_frontendInfo+88> > rc =3D 32768 > #3 0x00007fcbb5fb6956 in over_op_func (op=3D0x7fcbb6c0dc00, rs=3D0x7fcbad8= > 81a30, which=3Dop_bind) at backover.c:723 > oi =3D 0x7fcbb6443430 > on =3D 0x7fcbb6443610 > be =3D 0x7fcbb6343c40 <slap_frontendDB> > db =3D {bd_info =3D 0x7fcbb6343a80 <slap_frontendInfo>, bd_self =3D= > 0x7fcbb6343c40 <slap_frontendDB>, be_ctrls =3D "\000", '\001' <repeats 18 = > times>, '\000' <repeats 13 times>, > be_flags =3D 768, be_restrictops =3D 0, be_requires =3D 0, be_ssf= > _set =3D {sss_ssf =3D 112, sss_transport =3D 0, sss_tls =3D 56, sss_sasl = > =3D 0, sss_update_ssf =3D 112, sss_update_transport =3D 0, > sss_update_tls =3D 0, sss_update_sasl =3D 0, sss_simple_bind = > =3D 0}, be_suffix =3D 0x7fcbb643bd50, be_nsuffix =3D 0x7fcbb643bda0, be_sch= > emadn =3D {bv_len =3D 12, > bv_val =3D 0x7fcbb6474530 "cn=3DSubschema"}, be_schemandn =3D {= > bv_len =3D 12, bv_val =3D 0x7fcbb6474670 "cn=3Dsubschema"}, be_rootdn =3D {= > bv_len =3D 0, bv_val =3D 0x0}, be_rootndn =3D {bv_len =3D 0, > bv_val =3D 0x0}, be_rootpw =3D {bv_len =3D 0, bv_val =3D 0x0}, = > be_max_deref_depth =3D 0, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard= > =3D 0, lms_s_soft =3D -1, lms_s_hard =3D 0, > lms_s_unchecked =3D -1, lms_s_pr =3D 0, lms_s_pr_hide =3D 0, lms= > _s_pr_total =3D 0}, be_limits =3D 0x0, be_acl =3D 0x0, be_dfltaccess =3D AC= > L_READ, be_extra_anlist =3D 0x0, be_update_ndn =3D { > bv_len =3D 0, bv_val =3D 0x0}, be_update_refs =3D 0x0, be_pendi= > ng_csn_list =3D 0x0, be_pcl_mutex =3D {__data =3D {__lock =3D 0, __count = > =3D 0, __owner =3D 0, __nusers =3D 0, __kind =3D 0, > __spins =3D 0, __list =3D {__prev =3D 0x0, __next =3D 0x0}}, = > __size =3D '\000' <repeats 39 times>, __align =3D 0}, be_syncinfo =3D 0x0, = > be_pb =3D 0x0, > be_cf_ocs =3D 0x7fcbb63355a0 <cf_ocs+448>, be_private =3D 0x0, be= > _next =3D {stqe_next =3D 0x7fcbb643fa00}} > cb =3D {sc_next =3D 0x0, sc_response =3D 0x7fcbb5fb5629 <over_back_= > response>, sc_cleanup =3D 0x0, sc_writewait =3D 0x0, sc_private =3D 0x7fcbb= > 6443430} > sc =3D 0x7fcbb6c0dc38 > rc =3D 32768 > __PRETTY_FUNCTION__ =3D "over_op_func" > #4 0x00007fcbb5fb69de in over_op_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcbad8= > 81a30) at backover.c:738 > No locals. > #5 0x00007fcbb5f47697 in do_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcbad881a30= > ) at bind.c:205 > ber =3D 0x7fcb8c1a9510 > version =3D 3 > method =3D 128 > mech =3D {bv_len =3D 0, bv_val =3D 0x0} > dn =3D {bv_len =3D 41, bv_val =3D 0x7fcb88344a3a "cn=3Dxxxxbnd,ou= > =3Dbind,dc=3Dxxxx,dc=3Dxxxx.xx"} > tag =3D 128 > be =3D 0x0 > #6 0x00007fcbb5f1df19 in connection_operation (ctx=3D0x7fcbad881b80, arg_v= > =3D0x7fcbb6c0dc00) at connection.c:1155 > rc =3D 80 > cancel =3D 0 > op =3D 0x7fcbb6c0dc00 > rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 97, sr_msgid =3D 2, sr_e= > rr =3D 52, sr_matched =3D 0x0, sr_text =3D 0x7fcbb60e698a "Start TLS failed= > ", sr_ref =3D 0x0, sr_ctrls =3D 0x0, sr_un =3D { > sru_search =3D {r_entry =3D 0x0, r_attr_flags =3D 0, r_operatio= > nal_attrs =3D 0x0, r_attrs =3D 0x0, r_nentries =3D 0, 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 96 > opidx =3D SLAP_OP_BIND > conn =3D 0x7fcbae0f22d0 > memctx =3D 0x7fcbb64fada0 > memctx_null =3D 0x0 > memsiz =3D 1048576 > __PRETTY_FUNCTION__ =3D "connection_operation" > #7 0x00007fcbb5f1e4e1 in connection_read_thread (ctx=3D0x7fcbad881b80, arg= > v=3D0x281) at connection.c:1291 > rc =3D 0 > cri =3D {op =3D 0x7fcbb6c0dc00, func =3D 0x0, arg =3D 0x0, ctx =3D = > 0x7fcbad881b80, nullop =3D 0} > s =3D 641 > #8 0x00007fcbb5a53c3c in ldap_int_thread_pool_wrapper (xpool=3D0x7fcbb640a= > f70) at tpool.c:688 > pool =3D 0x7fcbb640af70 > task =3D 0x7fcba8787f80 > work_list =3D 0x7fcbb640b008 > ctx =3D {ltu_id =3D 140512766469888, ltu_key =3D {{ltk_key =3D 0x7f= > cbb5f1da15 <conn_counter_init>, ltk_data =3D 0x7fcbb64fac90, ltk_free =3D 0= > x7fcbb5f1d817 <conn_counter_destroy>}, { > ltk_key =3D 0x7fcbb5f95b15 <slap_sl_mem_init>, ltk_data =3D 0= > x7fcbb64fada0, ltk_free =3D 0x7fcbb5f95944 <slap_sl_mem_destroy>}, {ltk_key= > =3D 0x7fcbb5f3991c <slap_op_free>, > ltk_data =3D 0x7fcbb6c0ce30, ltk_free =3D 0x7fcbb5f39874 <sla= > p_op_q_destroy>}, {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D 0x0} <re= > peats 29 times>}} > kctx =3D 0x0 > i =3D 32 > keyslot =3D 838 > hash =3D 2545024838 > __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper" > #9 0x00007fcbb4e6c806 in start_thread (arg=3D<optimized out>) at pthread_c= > reate.c:301 > __res =3D <optimized out> > pd =3D 0x7fcbad882700 > unwind_buf =3D {cancel_jmp_buf =3D {{jmp_buf =3D {140512766469888, = > -3966806835471793915, 140512774851584, 140512766468096, 0, 8388608, 3991395= > 584477806853, 3991451503570501893}, > mask_was_saved =3D 0}}, priv =3D {pad =3D {0x0, 0x0, 0x0, 0x0= > }, data =3D {prev =3D 0x0, cleanup =3D 0x0, canceltype =3D 0}}} > not_first_call =3D <optimized out> > robust =3D <optimized out> > freesize =3D <optimized out> > __PRETTY_FUNCTION__ =3D "start_thread" > #10 0x00007fcbb36b702d in gnu_dev_makedev (major=3D3066092544, minor=3D<opt= > imized out>) at ../sysdeps/unix/sysv/linux/makedev.c:37 > No locals. > #11 0x0000000000000000 in ?? () > No symbol table info available. -- -- 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 July 2015