openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#8781) "connection_read(248): no connection!" on 2.4.44
by quanah＠symas.com 17 Apr '19

17 Apr '19

--On Thursday, November 30, 2017 10:11 PM +0000 mramitsingh85(a)gmail.com wrote: > Full_Name: Amit kumar singh > Version: 2.4.44 > OS: CentOS release 6.9 (Final) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (14.141.104.38) > > > Issue on replication and get below error. > > Nov 30 17:03:55 host slapd[709]: connection_read(346): no connection! > Nov 30 17:03:55 host slapd[709]: connection_read(346): no connection! > Nov 30 17:03:55 host[709]: connection_read(362): no connection! > > I was searching issue and found that fixed ref: ITS#6548 on 2.4.27. But > strange thing is that it comes up again in 2.4.44. Not sure If I am > correct but need your help to look into it. Hello, This is not a bug. This commonly occurs when a client ends the connection without properly ending an unbind request first. The solution would be to fix the client involved. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8780) Plug a socket leak in ldap_new_connection made by unsuccessful connection attempts
by quanah＠symas.com 17 Apr '19

17 Apr '19

--On Thursday, November 30, 2017 2:02 PM +0000 hguo(a)suse.com wrote: > Full_Name: Houzuo Guo > Version: master > OS: > URL: ftp://ftp.openldap.org/incoming/houzuo-guo-171130.patch > Submission from: (NULL) (195.135.221.2) > > > In case that ldap connection is attempted on failed URLs prior to > establishing a successful connection, the failed connection sockets are > never freed. This patch plugs the socket descriptor leak. Hello, Thank you for the report! Please reply with an IPR statement as documented at <https://www.openldap.org/devel/contributing.html#notice> if you wish your patch to be reviewed for inclusion in the OpenLDAP software. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8764) A small typo in README
by quanah＠symas.com 17 Apr '19

17 Apr '19

--On Monday, October 30, 2017 4:36 AM +0000 believelinan(a)aliyun.com wrote: > Full_Name: Nan Li > Version: 2.4.45 > OS: > URL: > Submission from: (NULL) (137.69.117.201) > > > I download source code of version 2.4.45, found a small typo in README at > line 32: > > 32 detailed instructions can be found in the OpenLDAP > Admnistrator's > > where "Admnistrator" should be "Administrator". Thanks for the report! This has been fixed in RE24. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8761) Comment for SLAPD_OVER_RETCODE define in portable.h is incorrect
by quanah＠symas.com 17 Apr '19

17 Apr '19

--On Monday, October 23, 2017 6:04 PM +0000 metzen(a)gmail.com wrote: > Full_Name: Matt McDonald > Version: > OS: > URL: > Submission from: (NULL) (2601:282:b01:175b:359:7f8e:53e6:7341) > > > The comment for the SLAPD_OVER_RETCODE entry in include/portable.hin > incorrectly describes it as the "Referential Integrity" overlay, when it > should indicate the "return code" overlay. Thanks for the report, this has been fixed in git master. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8426) unable to get group names of user
by quanah＠symas.com 17 Apr '19

17 Apr '19

--On Monday, May 16, 2016 3:00 PM +0000 pradeepagrawal8184(a)gmail.com wrote: > Full_Name: Pradeep Agrawal > Version: 2.4.40-7 > OS: centos > URL: > Submission from: (NULL) (114.143.121.177) > > > is there any way to get groups of users by providing username. i am using > java code to fetch list of groups of given users but it seems its not > possible as user don't have 'memberof' attribute. > Hello, The ITS system is for reporting bugs with the OpenLDAP software. It is not for general purpose help requests. Please use the openldap-technical email list for usage questions. <https://www.openldap.org/lists/mm/listinfo/openldap-technical> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9008) module rpath incorrect
by ondra＠openldap.org 17 Apr '19

17 Apr '19

Full_Name: Ondrej Kuznik Version: re24/master OS: Linux URL: https://github.com/mistotebe/openldap/tree/its9008 Submission from: (NULL) (82.10.24.68) Modules that link against libraries not already present in slapd will only try to look in the rpaths encoded in the module, not in slapd. And there is no point encoding $(moduledir) there, since we never install anything of substance there. All the while the libraries we need probably live in $(libdir). The linked patch fixes this and makes it possible for $(moduledir) (the path modules will be installed into) to be set at configure time. IPR notice: The linked files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patches were developed Symas corp. Symas corp. has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Symas corp. to release this work under the following terms. Symas corp. 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#9007) In writemap mode, a loose page can end up in me_dpages, causing a segfault on mdb_env_close.
by hyc＠symas.com 16 Apr '19

16 Apr '19

kriszyp(a)gmail.com wrote: > Full_Name: Kristopher William Zyp > Version: LMDB 0.9.23 > OS: Windows > URL: fhttps://github.com/kriszyp/node-lmdb/commit/dc290553acb57fa3f2d6d88a0d5e02… > Submission from: (NULL) (71.199.6.148) > > > In writemap mode in LMDB, it seems that a loose page can end up in me_dpages, > causing a segfault on mdb_env_close or on writes after mdb_env_set_mapsize. Thanks for the report, fix applied to mdb.master > > If I understand correctly, in MDB_WRITEMAP mode, dirty pages should never enter > into me_dpages, since dirty pages directly refer to the mapped memory, and > me_dpages are allocated from the heap (for reuse). However, I think a dirty page > that has become a loose page can end up in me_dpages; it seems that when > mdb_freelist_save() is called, it iterates through the loose pages and can end > up calling mdb_dpage_free at > https://github.com/LMDB/lmdb/blob/mdb.RE/0.9/libraries/liblmdb/mdb.c#L3114, > allowing the loose page to end up in me_dpages. This means that me_dpages ends > up with a reference to data in the memory map. And this becomes apparent if you > call mdb_env_close or do a mdb_env_set_mapsize triggering a segfault when it > attempts to free a memory map'ed page or access previously unmapped page. > > Everywhere else in the code, the MDB_WRITEMAP flag prevents any calls to > mdb_dpage_free (or mdb_dlist_free) in writemap mode (which I assume is > intentional), except in mdb_freelist_save. It seems like the mdb_dpage_free call > just needs to be moved up a few lines to the else block of the MDB_TXN_WRITEMAP > conditional, so that it also won't be called in writemap mode. > > I apologize I can't provide a more isolated test case. This combination actually > seems to be pretty rare occurrence, and very difficult to reproduce, I only > occasionally observe it happening with large amounts of operations with frequent > closing/resizing of the env. And I don't understand the internals to be 100% > confident of this, and perhaps I am misunderstanding this code path. But, it > does seems like this fix prevents these crashes for us, and seems like ensuring > there are no mdb_dpage_free calls in writemap mode (only mdb_page_free calls) is > the legitimate intention of the code. > > The attached URL contains the fix as a patch (against the node-lmdb project). > > -- -- 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#9007) In writemap mode, a loose page can end up in me_dpages, causing a segfault on mdb_env_close.
by kriszyp＠gmail.com 15 Apr '19

15 Apr '19

Full_Name: Kristopher William Zyp Version: LMDB 0.9.23 OS: Windows URL: fhttps://github.com/kriszyp/node-lmdb/commit/dc290553acb57fa3f2d6d88a0d5e02… Submission from: (NULL) (71.199.6.148) In writemap mode in LMDB, it seems that a loose page can end up in me_dpages, causing a segfault on mdb_env_close or on writes after mdb_env_set_mapsize. If I understand correctly, in MDB_WRITEMAP mode, dirty pages should never enter into me_dpages, since dirty pages directly refer to the mapped memory, and me_dpages are allocated from the heap (for reuse). However, I think a dirty page that has become a loose page can end up in me_dpages; it seems that when mdb_freelist_save() is called, it iterates through the loose pages and can end up calling mdb_dpage_free at https://github.com/LMDB/lmdb/blob/mdb.RE/0.9/libraries/liblmdb/mdb.c#L3114, allowing the loose page to end up in me_dpages. This means that me_dpages ends up with a reference to data in the memory map. And this becomes apparent if you call mdb_env_close or do a mdb_env_set_mapsize triggering a segfault when it attempts to free a memory map'ed page or access previously unmapped page. Everywhere else in the code, the MDB_WRITEMAP flag prevents any calls to mdb_dpage_free (or mdb_dlist_free) in writemap mode (which I assume is intentional), except in mdb_freelist_save. It seems like the mdb_dpage_free call just needs to be moved up a few lines to the else block of the MDB_TXN_WRITEMAP conditional, so that it also won't be called in writemap mode. I apologize I can't provide a more isolated test case. This combination actually seems to be pretty rare occurrence, and very difficult to reproduce, I only occasionally observe it happening with large amounts of operations with frequent closing/resizing of the env. And I don't understand the internals to be 100% confident of this, and perhaps I am misunderstanding this code path. But, it does seems like this fix prevents these crashes for us, and seems like ensuring there are no mdb_dpage_free calls in writemap mode (only mdb_page_free calls) is the legitimate intention of the code. The attached URL contains the fix as a patch (against the node-lmdb project).

1 0

(ITS#9006) sha2 module is not usable
by aditya1606＠gmail.com 10 Apr '19

10 Apr '19

Full_Name: Aditya Version: 2.4.43 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.228.66.13) I am not able to load the module due to this undefined symbol. $ nm pw-sha2.so | grep -i "lutil_passwd_add" U lutil_passwd_add

1 0

Re: (ITS#9004) LDAP_VENDOR_VERSION shall not be 0
by hyc＠symas.com 10 Apr '19

10 Apr '19

dpa-openldap(a)aegee.org wrote: > Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; &amp= ;#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1086;= &#1074; > Version: git/master > OS: Linux > URL:=20 > Submission from: (NULL) (141.12.129.132) >=20 >=20 > Per https://gitlab.gnome.org/GNOME/evolution-data-server/issues/99: >=20 > =E2=80=A2 Please do not set LDAP_VENDOR_VERSION to 0, when compiling fr= om git/master, > but use reasonable default: a number bigger or equal to 20000. Like 20= 500 for > LDAP 2.5. >=20 >=20 git master is a development branch and not intended for production use. Use a tagged release or the release engineering branch. Closing this ITS. --=20 -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs