Full_Name: Arran Cudbard-Bell Version: 2.4.40 OS: OSX 10.10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.196.165.104) Issue is fully documented here: https://github.com/arr2036/ldapperf/issues/2 As libldap lacks a global initialisation function, the global config struct and other global resources are initialised on the first call to either ldap_create, ldap_get_option or ldap_set_option via a call to ldap_int_initialize. Where multiple threads are spawned and each allocate a new handle using a function that calls ldap_create, the lack of concurrent access protection in ldap_int_initialize causes memory corruption. There are a few ways this could be fixed. One is documented in the issue tracker link above. There are likely better ones. An alternative of fixing this would be to have public functions that can be used to initialise any global resources before creating handles, and to free them explicitly (instead of relying on atexit or a similar mechanism). In terms of writing dynamically loadable/unloadable modules around libldap, the second approach is preferred as any memory allocated on the heap could be cleaned up prior to the module being unloaded.
moved from Incoming to Software Bugs
changed notes
--On Tuesday, December 09, 2014 6:14 PM +0000 a.cudbardb@freeradius.org wrote: > Full_Name: Arran Cudbard-Bell > Version: 2.4.40 > OS: OSX 10.10.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.196.165.104) Hi Arran, Thanks for the report and sorry for the delay on getting to this issue. I would note that for the fix to be included in the OpenLDAP project, we need an IPR statement, as noted at <https://www.openldap.org/devel/contributing.html>. If you can provide that, and (if possible) submit the patch as git format-patch via the project FTP server (include the URL in your email), then I can pull it in. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Hi Quanah, > Thanks for the report and sorry for the delay on getting to this issue. I would note that for the fix to be included in the OpenLDAP project, we need an IPR statement, as noted at <https://www.openldap.org/devel/contributing.html>. If you can provide that, and (if possible) submit the patch as git format-patch via the project FTP server (include the URL in your email), then I can pull it in. IPR statement is not a problem, but I don't have the original diff to work from. If you can send me a copy of the FTP submission I can reformat it and resubmit it. Many Thanks, -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
--On Friday, September 08, 2017 1:02 PM +0000 a.cudbardb@freeradius.org wrote: >> Thanks for the report and sorry for the delay on getting to this = > issue. I would note that for the fix to be included in the OpenLDAP = > project, we need an IPR statement, as noted at = > <https://www.openldap.org/devel/contributing.html>. If you can provide = > that, and (if possible) submit the patch as git format-patch via the = > project FTP server (include the URL in your email), then I can pull it = > in. > > IPR statement is not a problem, but I don't have the original diff to = > work from. If you can send me a copy of the FTP submission I can = > reformat it and resubmit it. Hi Arran, The diff is in your github issues tracker. ;) <https://github.com/arr2036/ldapperf/issues/2#issuecomment-66242732> Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
changed notes changed state Open to Release
On Fri, Sep 08, 2017 at 02:07:19PM +0000, quanah@symas.com wrote: > --On Friday, September 08, 2017 1:02 PM +0000 a.cudbardb@freeradius.org > wrote: >>> Thanks for the report and sorry for the delay on getting to this >>> issue. I would note that for the fix to be included in the OpenLDAP >>> project, we need an IPR statement, as noted at >>> <https://www.openldap.org/devel/contributing.html>. If you can >>> provide that, and (if possible) submit the patch as git format-patch >>> via the project FTP server (include the URL in your email), then I >>> can pull it in. >> >> IPR statement is not a problem, but I don't have the original diff to = >> work from. If you can send me a copy of the FTP submission I can = >> reformat it and resubmit it. > > Hi Arran, > > The diff is in your github issues tracker. ;) > > <https://github.com/arr2036/ldapperf/issues/2#issuecomment-66242732> Hi Arran, thank you for your work, a patch addressing this has been pushed to master (db40120a276c3b7968552e253aea24860fad5f60) and will also be part (cde56fad154fcd25e351c3cd84d8173d263b0a01) of the upcoming 2.4.48 release. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
--On Sunday, June 16, 2019 4:06 PM +0200 Armin Tüting <Armin.Tueting@tueting-online.com> wrote: > Hello Quanah, > > I'm following OPENLDAP_REL_ENG_2_4. The commit > 'cde56fad154fcd25e351c3cd84d8173d263b0a01' breaks starting slapd. It > won't start at all... > > I'm using a fairly up-to-date CentOS 7 version... > 3.10.0-957.21.2.el7.x86_64 #1 SMP Wed Jun 5 14:26:44 UTC 2019 x86_64 Hi, Thanks for the report. When reporting issues, please keep them on the OpenLDAP bug tracking list, rather than directly emailing individuals. I'm unable to reproduce this with Ubuntu18 (all tests in the test suite pass via make test, and I can start slapd just fine w/o debug mode). I'll test on centos7 and see if I can reproduce. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
--On Sunday, June 16, 2019 7:54 PM +0000 quanah@symas.com wrote: > --On Sunday, June 16, 2019 4:06 PM +0200 Armin T=C3=BCting=20 > <Armin.Tueting@tueting-online.com> wrote: > >> Hello Quanah, >> >> I'm following OPENLDAP_REL_ENG_2_4. The commit >> 'cde56fad154fcd25e351c3cd84d8173d263b0a01' breaks starting slapd. It >> won't start at all... >> >> I'm using a fairly up-to-date CentOS 7 version... >> 3.10.0-957.21.2.el7.x86_64 #1 SMP Wed Jun 5 14:26:44 UTC 2019 x86_64 > > Hi, > > Thanks for the report. When reporting issues, please keep them on the=20 > OpenLDAP bug tracking list, rather than directly emailing individuals. > > I'm unable to reproduce this with Ubuntu18 (all tests in the test suite=20 > pass via make test, and I can start slapd just fine w/o debug mode). > I'll=20 test on centos7 and see if I can reproduce. I'm also unable to reproduce any issues with current RE24 (0c44b22d3e347f2f05f913e7e3ffa907816574ed) under fully updated Centos7: CentOS Linux release 7.6.1810 (Core) kernel-headers.x86_64 3.10.0-957.21.2.el7 @updates You will need to provide substantially more information about what you're seeing. I would start with starting slapd in full debug mode (add -d -1 to the startup flags to slapd) and see what issue(s) it reports. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
--On Monday, June 17, 2019 9:59 AM +0200 Armin Tüting <Armin.Tueting@tueting-online.com> wrote: >> > Hi, >> > >> > Thanks for the report. When reporting issues, please keep them on >> > the=20 OpenLDAP bug tracking list, rather than directly emailing >> > individuals. >> You will need to provide substantially more information about what >> you're seeing. I would start with starting slapd in full debug mode >> (add -d -1 to the startup flags to slapd) and see what issue(s) it >> reports. > Slapd won't even start at all! No log! > I'm attaching the redirected output from 'make test'. In addition the > 'config.log' and 'slapd_start.txt'. Hi Armin, Again, I will please ask you CC replies to the OpenLDAP ITS list (openldap-its@openldap.org) so they properly get entered into the issue tracker. Your slapd_start.txt attachment clearly shows slapd starting: time /opt/openldap/libexec/slapd -F /opt/openldap/etc/openldap/slapd.d -u ldap -h "ldapi:/// ldap:/// ldaps:///" -d -1 ldap_url_parse_ext(ldap://localhost/) ldap_init: trying /opt/openldap/etc/openldap/ldap.conf ldap_init: using /opt/openldap/etc/openldap/ldap.conf ^C I.e., it started and then got as far as reading your ldap.conf file. What is the contents of ldap.conf? Have you run the test suite (make test)? Does it pass? fail? Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Am Montag, den 17.06.2019, 07:41 -0700 schrieb Quanah Gibson-Mount: > --On Monday, June 17, 2019 9:59 AM +0200 Armin Tüting > <Armin.Tueting@tueting-online.com> wrote: > > > > > Hi, > > > > > > > > Thanks for the report. When reporting issues, please keep them on > > > > the=20 OpenLDAP bug tracking list, rather than directly emailing > > > > individuals. > > > You will need to provide substantially more information about what > > > you're seeing. I would start with starting slapd in full debug mode > > > (add -d -1 to the startup flags to slapd) and see what issue(s) it > > > reports. > > Slapd won't even start at all! No log! > > I'm attaching the redirected output from 'make test'. In addition the > > 'config.log' and 'slapd_start.txt'. > > Hi Armin, > > Again, I will please ask you CC replies to the OpenLDAP ITS list > (openldap-its@openldap.org) so they properly get entered into the issue > tracker. > > Your slapd_start.txt attachment clearly shows slapd starting: > > time /opt/openldap/libexec/slapd -F /opt/openldap/etc/openldap/slapd.d -u > ldap -h "ldapi:/// ldap:/// ldaps:///" -d -1 > > ldap_url_parse_ext(ldap://localhost/) > ldap_init: trying /opt/openldap/etc/openldap/ldap.conf > ldap_init: using /opt/openldap/etc/openldap/ldap.conf > ^C > > > I.e., it started and then got as far as reading your ldap.conf file. What > is the contents of ldap.conf? Attached 'ldap.conf'. Nothing unusual... > Have you run the test suite (make test)? Does it pass? fail? Attached 'make_test.txt'. As far as I can see - it has been passed. > Thanks, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >
--On Monday, June 17, 2019 7:16 PM +0200 Armin Tüting <Armin.Tueting@tueting-online.com> wrote: >> I.e., it started and then got as far as reading your ldap.conf file. >> What is the contents of ldap.conf? > Attached 'ldap.conf'. Nothing unusual... > >> Have you run the test suite (make test)? Does it pass? fail? > Attached 'make_test.txt'. As far as I can see - it has been passed. Ok, so make test passes without issue, so it would appear there's something specific with your configuration that is triggering the problem. Would you be able to provide your slapd configuration (minus any passwords and the like)? Additionally, if you could get a full gdb backtrace of the hung slapd process that would be useful as well. I.e.: start up slapd gdb /path/to/slapd <pid #> at the gdb prompt: thr apply all bt full Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Am Montag, den 17.06.2019, 15:40 -0700 schrieb Quanah Gibson-Mount: > --On Monday, June 17, 2019 7:16 PM +0200 Armin Tüting > <Armin.Tueting@tueting-online.com> wrote: > > > > I.e., it started and then got as far as reading your ldap.conf file. > > > What is the contents of ldap.conf? > > Attached 'ldap.conf'. Nothing unusual... > > > > > Have you run the test suite (make test)? Does it pass? fail? > > Attached 'make_test.txt'. As far as I can see - it has been passed. > > Ok, so make test passes without issue, so it would appear there's something > specific with your configuration that is triggering the problem. Would you > be able to provide your slapd configuration (minus any passwords and the > like)? I'll privately send it to you in a seperate email. > > Additionally, if you could get a full gdb backtrace of the hung slapd > process that would be useful as well. I.e.: > > start up slapd > gdb /path/to/slapd <pid #> (gdb) thr apply all bt full Thread 1 (Thread 0x7ffa4ad71880 (LWP 9207)): #0 0x00007ffa4918c4ed in __lll_lock_wait () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007ffa49187dcb in _L_lock_883 () from /lib64/libpthread.so.0 No symbol table info available. #2 0x00007ffa49187c98 in pthread_mutex_lock () from /lib64/libpthread.so.0 No symbol table info available. #3 0x00007ffa4a92a135 in ldap_pvt_thread_mutex_lock (mutex=<optimized out>) at thr_posix.c:296 No locals. #4 0x00007ffa4a944e6e in ldap_set_option (ld=ld@entry=0x0, option=option@entry=20486, invalue=invalue@entry=0x7ffdceb7aeb4) at options.c:465 lo = 0x7176c0 <ldap_int_global_options> dbglvl = 0x0 rc = -1 __PRETTY_FUNCTION__ = "ldap_set_option" #5 0x00007ffa4a943ed3 in openldap_ldap_init_w_conf (file=file@entry=0x 7ffa4a95a750 "/opt/openldap/etc/openldap/ldap.conf", userconf=userconf@entry=0) at init.c:270 p = <optimized out> linebuf = "URI\000ldap://localhost/\000\000tions\n\000ware/man.cgi?query=ldap.con f\n\000ldapusingtlswithsshapasswords\n\000\000\377\377\000\000\177\003" , '\000' <repeats 22 times>, "\200\037\000\000\377\377", '\000' <repeats 152 times>... fp = 0x8177b0 i = <optimized out> opt = 0x7ffdceb7aeb4 "ldap://localhost/" start = 0x7ffdceb7aeb4 "ldap://localhost/" end = <optimized out> gopts = 0x7ffa4ab67120 <ldap_int_global_options> #6 0x00007ffa4a944318 in openldap_ldap_init_w_sysconf (file=0x7ffa4a95a750 "/opt/openldap/etc/openldap/ldap.conf") at init.c:316 No locals. #7 ldap_int_initialize (gopts=gopts@entry=0x7176c0 <ldap_int_global_options>, dbglvl=dbglvl@entry=0x719050 <slap_debug>) at init.c:684 No locals. #8 0x00007ffa4a944e38 in ldap_set_option (ld=0x0, option=20481, invalue=0x719050 <slap_debug>) at options.c:450 lo = <optimized out> dbglvl = 0x719050 <slap_debug> rc = -1 __PRETTY_FUNCTION__ = "ldap_set_option" #9 0x0000000000413cd6 in main () No symbol table info available. > at the gdb prompt: > > thr apply all bt full > > Thanks! > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >
On Tue, Jun 18, 2019 at 07:33:48AM +0000, Armin.Tueting@tueting-online.com wrote: > Am Montag, den 17.06.2019, 15:40 -0700 schrieb Quanah Gibson-Mount: >> --On Monday, June 17, 2019 7:16 PM +0200 Armin T=C3=BCting=20 >> <Armin.Tueting@tueting-online.com> wrote: >>>> I.e., it started and then got as far as reading your ldap.conf file. >>>> What is the contents of ldap.conf? >>> Attached 'ldap.conf'. Nothing unusual... >>> >>>> Have you run the test suite (make test)? Does it pass? fail? >>> Attached 'make_test.txt'. As far as I can see - it has been passed. >> >> Ok, so make test passes without issue, so it would appear there's something >> specific with your configuration that is triggering the problem. Would you >> be able to provide your slapd configuration (minus any passwords and the >> like)? > I'll privately send it to you in a seperate email. > >> >> Additionally, if you could get a full gdb backtrace of the hung slapd=20 >> process that would be useful as well. I.e.: >> >> start up slapd >> gdb /path/to/slapd <pid #> > (gdb) thr apply all bt full > #3 0x00007ffa4a92a135 in ldap_pvt_thread_mutex_lock > #4 0x00007ffa4a944e6e in ldap_set_option > #5 0x00007ffa4a943ed3 in openldap_ldap_init_w_conf > #6 0x00007ffa4a944318 in openldap_ldap_init_w_sysconf > #8 0x00007ffa4a944e38 in ldap_set_option > #9 0x0000000000413cd6 in main () Hi Armin, thank you very much for your report, this should now be fixed in master with commit b2f4cacd4783cfe49370accc712863f9537f9924. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Am Freitag, den 21.06.2019, 13:31 +0200 schrieb Ondřej Kuzník: [...] > Hi Armin, Hi Ondrej, > thank you very much for your report, this should now be fixed in master > with commit b2f4cacd4783cfe49370accc712863f9537f9924. I'm not following 'master' - I'm afraid! But, the commit has been merged into 'OPENLDAP_REL_ENG_2_4' and slapd is now serving our requests! So far, so good! Thanks for your effort! > > Regards, Regards, Armin.
Fixed in master Fixed in RE24 (2.4.48)
changed notes changed state Release to Closed