openldap-bugs October 2020

openldap-bugs@openldap.org

8 participants
425 discussions

[Issue 9366] New: (async)meta does not check ldap_install_tls() return code
by openldap-its＠openldap.org 26 Oct '20

26 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9366 Issue ID: 9366 Summary: (async)meta does not check ldap_install_tls() return code Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When SLAP_STARTTLS_ASYNCHRONOUS is defined, meta and asyncmeta backends do not make sure to save the ldap_install_tls() return code so a StartTLS set up error might not be detected properly and the connection might not be closed for a while. Patch coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9376] New: Repeated deletes with DUPSORT cursor breaks
by openldap-its＠openldap.org 26 Oct '20

26 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9376 Issue ID: 9376 Summary: Repeated deletes with DUPSORT cursor breaks Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- As discussed and fixed in https://git.openldap.org/openldap/openldap/-/merge_requests/194 -- You are receiving this mail because: You are on the CC list for the issue.

1 2

best ndis service provider in melbourne
by thebpogroup344＠gmail.com 25 Oct '20

25 Oct '20

I am a Medical Doctor in Australia and I am at this time specializing in Pediatrics. I am very loving about the work that I do. Our mission is to provide centered services with un-matched quality that support empowers permanent disable persons to make their own journey of life. As a support provider we help people with significant and permanent disability to achieve goals in their life by assisting in Community Participation, Household Tasks and many more. At Authentic Life Care, we provide home care support services to families, to assist them through challenging times in their lives. Here at Authentic Life Care, we set out our current arrangements for meeting the needs of customers who have significant and permanent disability. We maintain and improve current standards of accessibility to services for people with disabilities or those whose mobility is impaired. We will support independent travel as far as possible, with the principles of information and access elevated across the board so that clienteles with agility complications have more self-assurance in traveling. Get To Know More about us at https://authenticlifecare.com.au/

1 0

Loading freelist with large fragmented free space in LMDB
by Kris Zyp 24 Oct '20

24 Oct '20

I have noticed a performance issue with mdb_page_alloc loading the freelist while trying to find a large block when there is a significant amount of free-space that is fragmented/non-contiguous. In our application, we often have a database environment that may have a sub-database with large blocks (thousands of records around a MB), and another sub-database with many small blocks (10 of millions < 1KB). We frequently drop/delete the latter sub-database since it is an index of the former, to reindex it. However, this can leave multiple GBs of highly fragmented free space, and if we attempt to add/insert/put a record that is several MBs, mdb_page_alloc may attempt to load millions of free-page ids without finding a contiguous block. Loading large freelist seems to be an O(N^2) operation (N being size of free-list to load), since it repeatedly loads a constant size of new pages and rescans the whole cumulate IDL to search for blocks and merge new page ids (in mdb_midl_xmerge), and with very large free spaces, I've seen mdb_page_alloc take multiple minutes to complete. I think I have seen this with performing the database drop/delete as well. It seems like MDB_PARANOID may have been created to help deal with this type of issue. However, the Max_retries doesn't seem to be implemented/used by MDB_PARANOID. By adding a check to limit the retry variable to Max_retries (as seems intended), and compiling with MDB_PARANOID, I think this seems to mitigate this issue for us, and limits the free-space search so mdb_page_alloc always seems to return within a reasonable time. I was just curious if this was the intended way to deal with large free-spaces. And would it be helpful to (re?) implement the Max_retries (be glad to provide a patch) for when MDB_PARANOID is defined? Or is retry = num * 60 possibly a little bit high for a default retry setting? Or would it be preferable to improve the freelist loading to use a O(N*log N) algorithm (by possibly exponentially increasing size of blocks to load with binary tree merging) to load? Or is it better to consider this to be a pretty pathological case, and that that much free space (and record size variance) should be avoided, and that dropping/deleting such a large fragmented database should really be immediately followed by a copying the whole database environment with compaction to eliminate the excess (or all) free space? Anyway, I may be misunderstanding this issue, but my local use of MDB_PARANOID with the Max_retries fix seems like it is working fine for me (and I can certainly copy with compaction if I need to as well). Just curious if there are any suggestions otherwise, or any improvements that would be helpful to LMDB. Thanks, Kris

3 3

END
by Daniel Drinnon 23 Oct '20

23 Oct '20

END

3 2

[Issue 9373] New: Segmentation fault on ldap_simple_bind_s
by openldap-its＠openldap.org 22 Oct '20

22 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9373 Issue ID: 9373 Summary: Segmentation fault on ldap_simple_bind_s Product: OpenLDAP Version: 2.4.10 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ljin(a)microstrategy.com Target Milestone: --- Hit Faulting Signal: signal 11, Segmentation fault. when calling ldap_simple_bind_s. #0 0x00007f3e7cddec2d in poll () from /lib64/libc.so.6 #1 0x00007f3e468417d5 in ldap_result () from /usr/lib64/libldap_r-2.4.so.2 #2 0x00007f3e4684a808 in ldap_sasl_bind_s () from /usr/lib64/libldap_r-2.4.so.2 #3 0x00007f3e4684b055 in ldap_simple_bind_s () from /usr/lib64/libldap_r-2.4.so.2 This happened when there were multi-thread ldap_simple_bind_s calls. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9375] New: Segmentation fault on ldap_search_ext_s
by openldap-its＠openldap.org 22 Oct '20

22 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9375 Issue ID: 9375 Summary: Segmentation fault on ldap_search_ext_s Product: OpenLDAP Version: 2.4.44 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ljin(a)microstrategy.com Target Milestone: --- Hit Faulting Signal: signal 11, Segmentation fault in multi-threads environment. One crash call stack. #0 0x00007f08af05392b in ber_int_sb_write () from /lib64/liblber-2.4.so.2 #1 0x00007f08af04fc0b in ber_flush2 () from /lib64/liblber-2.4.so.2 #2 0x00007f08af281f71 in ldap_int_flush_request () from /lib64/libldap_r-2.4.so.2 #3 0x00007f08af282352 in ldap_send_server_request () from /lib64/libldap_r-2.4.so.2 #4 0x00007f08af2826da in ldap_send_initial_request () from /lib64/libldap_r-2.4.so.2 #5 0x00007f08af27153a in ldap_pvt_search () from /lib64/libldap_r-2.4.so.2 #6 0x00007f08af2716aa in ldap_pvt_search_s () from /lib64/libldap_r-2.4.so.2 #7 0x00007f08af271780 in ldap_search_ext_s () from /lib64/libldap_r-2.4.so.2 Another one: [0] /usr/lib64/liblber-2.4.so.2.10.7!ber_sockbuf_ctrl + 0x1ac [1] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_mark_select_clear + 0x2f [2] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_free_connection + 0x2b3 [3] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_int_bisect_insert + 0x4a5 [4] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_int_bisect_insert + 0x1bd [5] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_abandon_ext + 0x5a [6] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_abandon + 0x26 [7] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_pvt_search_s + 0xec [8] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_search_ext_s + 0x40 -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9374] New: Segmentation fault on ldap_ld_free
by openldap-its＠openldap.org 22 Oct '20

22 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9374 Issue ID: 9374 Summary: Segmentation fault on ldap_ld_free Product: OpenLDAP Version: 2.4.44 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ljin(a)microstrategy.com Target Milestone: --- Hit Faulting Signal: signal 11, Segmentation fault when multiple threads environment. #0 0x00007f13daa9b92b in ber_int_sb_write () from /lib64/liblber-2.4.so.2 #1 0x00007f13daa97c0b in ber_flush2 () from /lib64/liblber-2.4.so.2 #2 0x00007f13dacee6c7 in ldap_send_unbind () from /usr/lib64/libldap_r-2.4.so.2 #3 0x00007f13dacf700e in ldap_free_connection () from /usr/lib64/libldap_r-2.4.so.2 #4 0x00007f13dacee1bf in ldap_ld_free () from /usr/lib64/libldap_r-2.4.so.2 -- You are receiving this mail because: You are on the CC list for the issue.

1 2

Exhausting Locked SEM_UNDO Semaphores on MacOS
by Kris Zyp 20 Oct '20

20 Oct '20

In LMDB, if you attempt to open more than 10 transactions (on different environments) on one process on MacOS, then mdb_txn_begin will fail. This can be reproduced by opening 11 different database environments in one process, and calling mdb_txn_begin (as write transactions) on each one. The 11th one will return EINVAL. I believe this is because (on this OS, MacOS 10.13.6) the System V semaphores have a limit of 10 SEM_UNDO locked semaphores on one process. So when mdb_txn_begin attempts to open an 11th transaction, the mdb_sem_wait/semop call fails, returning EINVAL. I was testing with latest LMDB from mdb.master. Once I finally debugged this and figured out the issue, I have been able to work around it by compiling with MDB_USE_POSIX_SEM which seems to resolve the issue. But this still leaves a few questions: Is there any issue with compiling with MDB_USE_POSIX_SEM on MacOS? Would it be better if LMDB defaulted to this shared lock implementation for this OS? And/or would there be value in LMDB providing a more specific error message in this situation? The documentation doesn't indicate EINVAL as a possible return value for mdb_txn_begin, and this is a very generic error with little indication of the root problem, that was rather confusing to me, at least. Or is there an expectation that processes can only open a limited number of database environments (and have open transactions on them)? (Our server typically has about 30 environments open with about 2-16 dbs/env, with many concurrent transactions, without issue on other OSes.) I would be happy to put together a patch for this, but I am not sure of the reasons for the selection of the different shared lock implementations on different OSes. Anyway, I'd be glad to help contribute a patch if there is a specific way this should work. Thank you!

2 6

[Issue 9369] New: Logging based on severity
by openldap-its＠openldap.org 15 Oct '20

15 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9369 Issue ID: 9369 Summary: Logging based on severity Product: OpenLDAP Version: 2.4.46 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gdb91(a)protonmail.com Target Milestone: --- Currently OpenLDAP logging can be controller per area (subsystem) for example "trace function calls" or "debug packet handling". It would be good to have logging based on severity levels such as INFO, DEBUG, ERROR, WARNING, CRITICAL, etc., something that could be set up at run time. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
43
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2020