https://bugs.openldap.org/show_bug.cgi?id=8958
--- Comment #43 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
ldap_pvt_thread_pool_pausequery does not exist in RE25, which is why this is a
2.6 or later only fix. (for future reference and why the fix was reverted from
RE25)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10043
Issue ID: 10043
Summary: LMDB Wont Run in MacOS Sandbox
Product: LMDB
Version: 0.9.30
Hardware: All
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: t(a)tannersilva.com
Target Milestone: ---
Howdy from Texas.
I am the developer of QuickLMDB, the high performance wrapper for Swift.
I have been building an lmdb-based nostr client for the CakeWallet team using
my wrapper. I initially began writing this app with a wide deployment target
(iOS and MacOS with Sandboxing enabled). To my surprise, I was unable to get
QuickLMDB running on MacOS with its sandboxing mode enabled. It simply wouldn't
run.
I didn't allow myself to get too caught up in that particular issue on my
project (we have dropped MacOS from our initial targets for other reasons
anyways), however, I've since had a user raise an issue on my GitHub describing
the exact issue I dealt with in breaking ground on the nostr client with its
"new project defaults" build settings in Xcode.
https://github.com/tannerdsilva/QuickLMDB/issues/1https://github.com/agisboye/SwiftLMDB/issues/23
Admittedly, I haven't been able to thoroughly investigate this issue beyond my
own brief experiences with it in my mostly blank project.
Between the two links above, the users of the Swift wrappers seem to have
tested this issue in a more diverse way than I would do initially anyways.
In search of duplicate issues, I was unable to find anything that clearly draws
a line around sandboxing on MacOS, which is the primary concern here.
Confirmed by my own experiences: the issue here is simply that LMDB seems to be
impossible to run in a MacOS sandbox. When sandboxing is disabled, LMDB behaves
exactly as I would expect.
Apple Silicon - macOS 13.1
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9832
Issue ID: 9832
Summary: back-monitor crash when sizelimit in operation
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If a back-monitor search gets a failure in send_search_entry(), e.g. due to
sizelimit being reached, a pending server pause, etc., it will try to call
monitor_cache_release( mi, e ) where e == NULL instead of the correct entry to
release.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10034
Issue ID: 10034
Summary: Assertion 'i < NUMKEYS(mp)' failed in
mdb_page_search_root()"
Product: LMDB
Version: 0.9.23
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: 763280032(a)qq.com
Target Milestone: ---
We found that when lmdb is opened after OS startup and data is written to it,
lmdb will trigger abort probabilistically(Restart the OS 600 times will trigger
once);
We want to know what situation triggers this issue(Assertion 'i < NUMKEYS(mp)'
failed in mdb_page_search_root()); we want to know if there is a problem with
our usage;
Please Help Us
(gdb) x/8s 0x8baee988
0x8baee988: "8\373Ô²\b\371Ô²mdb.c:5542: Assertion 'i < NUMKEYS(mp)' failed in
mdb_page_search_root()"
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10038
Issue ID: 10038
Summary: connections_destroy: nothing to destroy
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: rasagollaravi(a)gmail.com
Target Milestone: ---
Hello Team,
I have installed openldap 2.5.13 version and trying to start ldap getting below
message.
log message:
connections_destroy: nothing to destroy
Thanks,
Ravi kumar
97171585372
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9460
Issue ID: 9460
Summary: Drop support for OpenSSL older than 1.1.1
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
OpenSSL no longer supports the 1.0.2 series and specifically notes it should
not be used:
"All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) are now out of
support and should not be used."
Currently configure checks for 1.0.2 or higher.
OpenSSL 1.1.1 is supported through 11 Sep 2023.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10040
Issue ID: 10040
Summary: ENGLISH-SPEAKING WITH OXFORD SCHOOL OF ENGLISH IN
DELHI
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: oxfordschoolofenglishdelhi(a)gmail.com
Target Milestone: ---
Created attachment 959
--> https://bugs.openldap.org/attachment.cgi?id=959&action=edit
Best English Speaking Institute Delhi
LEARN ENGLISH-SPEAKING WITH OXFORD SCHOOL OF ENGLISH IN DELHI
Oxford School of English- the Best Spoken English Institute in Delhi - is the
flagship offshoot of Hindustan Soft Education Ltd which is an NSDC Grade-A
partner company, and Certified Silver training partner of Cambridge University
Press. In the last 25 years, through our spoken English classes, we have
successfully trained more than 90,000 students. With Cambridge Interchange
Courses from Cambridge University Press combined with audio-video Ed-tech, and
scores of classroom activities like Role Plays and skits, our experienced
trainers deliver an indelible learning experience at our centres located within
easy reach of metro stations.
Our Specialties ------------------------------- ----------
Best English-Speaking Institute in Delhi since 1997
Six own centres with best of class infrastructure
Certified Silver Partner of Cambridge University Press
Insightfully crafted Cambridge English courses - English speaking course for
beginners, Intermediate English course, Advanced English-speaking course,
Personal English Coaching classes, English classes for competitive exams, IELTS
Audio-video, PDF worksheets, Blog, Forum on Cambridge Learning Management
System (CLMS)
In-house online Learning Management System (LMS)
Experienced and friendly trainers
Activity-oriented training sessions
For More Details:--
Whatsapp: +911145680574
Mobile: 91+ 9667462832
https://www.oxfordschoolofenglish.in/
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8977
OndÅ™ej KuznÃk <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=10031
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10027
Issue ID: 10027
Summary: MDB_TXN_FULL on large write transactions
Product: LMDB
Version: unspecified
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: renault.cle(a)gmail.com
Target Milestone: ---
Hello,
Our users ([1], [2]) encountered MDB_TXN_FULL errors when our Meilisearch
engine processed a large write transaction. We did read the documentation about
this error in the codebase of LMDB:
Spill pages from the dirty list back to disk.
This is intended to prevent running into #MDB_TXN_FULL situations,
but note that they may still occur in a few cases:
1) our estimate of the txn size could be too small. Currently this
seems unlikely, except with a large number of #MDB_MULTIPLE items.
2) child txns may run out of space if their parents dirtied a
lot of pages and never spilled them. TODO: we probably should do
a preemptive spill during #mdb_txn_begin() of a child txn, if
the parent's dirty_room is below a given threshold.
Otherwise, if not using nested txns, it is expected that apps will
not run into #MDB_TXN_FULL any more. The pages are flushed to disk
the same way as for a txn commit, e.g. their P_DIRTY flag is cleared.
If the txn never references them again, they can be left alone.
If the txn only reads them, they can be used without any fuss.
If the txn writes them again, they can be dirtied immediately without
going thru all of the work of #mdb_page_touch(). Such references are
handled by #mdb_page_unspill().
However, It looks like we are not in those scenarios, we are not using
MDB_DUPFIXED, and we are not using sub-transactions. We don't use the MDB_VL32
flag either, so this is not related to [3].
Thank you for your time,
Have a nice day 💡
[1]: https://github.com/meilisearch/meilisearch/issues/3603
[2]: https://github.com/meilisearch/meilisearch/issues/3349
[3]: https://bugs.openldap.org/show_bug.cgi?id=8813
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10029
Issue ID: 10029
Summary: slapd crashes when run with unlimited open files
Product: OpenLDAP
Version: 2.6.4
Hardware: All
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: gray(a)nxg.name
Target Milestone: ---
To reproduce:
% ulimit -n
unlimited
% $T/openldap-2.6.4/libexec/slapd -d-1
641ee8bc.32f05820 0x1dc760140 @(#) $OpenLDAP: slapd 2.6.4 (Mar 25 2023
12:25:49) $
openldap
641ee8bc.32f39ff8 0x1dc760140 daemon_init: <null>
641ee8bc.32f40588 0x1dc760140 daemon: SLAP_SOCK_INIT: dtblsize=-1
641ee8bc.32f43080 0x1dc760140 ch_calloc of 1 elems of 18446744073709551615
bytes failed
Assertion failed: (0), function ch_calloc, file ch_malloc.c, line 107.
zsh: abort $T/openldap-2.6.4/libexec/slapd -d-1
This is because `daemon.c` (line 1867) uses the maximum number of open files to
set `dtblsize`, which is subsequently used to size an array:
1867 #ifdef HAVE_SYSCONF
1868 dtblsize = sysconf( _SC_OPEN_MAX );
1869 #elif defined(HAVE_GETDTABLESIZE)
1870 dtblsize = getdtablesize();
1871 #else /* ! HAVE_SYSCONF && ! HAVE_GETDTABLESIZE */
1872 dtblsize = FD_SETSIZE;
1873 #endif /* ! HAVE_SYSCONF && ! HAVE_GETDTABLESIZE */
If the maximum number of FDs is unlimited, then sysconf(_SC_OPEN_MAX) returns
-1, and the program crashes when it tries to malloc that much memory.
I've marked this as OS=macOS because that's what I'm illustrating this on, but
the same thing would happen on any OS where the sysconf call returns a negative
number for the 'unlimited' case.
--
You are receiving this mail because:
You are on the CC list for the issue.