On Wed, Mar 27, 2019 at 04:39:14PM +0000, clement.oudot(a)worteks.com wrote:
> Seems it is because memberof try to add the new value before deleting the old
> one. As the values are the same when ignoring the case, the modification is
> rejected.
>
> I would say that doing the LDAP_SLIST_REMOVE before the LDAP_SLIST_INSERT_HEAD
> in memberof.c should be enough but I don't know if this is safe.
Alternatively checking that the new DN is not equivalent to the old and
if so, noop it? That's just been uploaded to
https://github.com/mistotebe/openldap/tree/its9000
Regards,
--
OndÅ™ej KuznÃk
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
quanah(a)symas.com wrote:
> --On Tuesday, May 28, 2019 10:12 PM +0000 adubovkin(a)linkedin.com wrote:
>
>> Full_Name: Alex
>> Version: LMDB 0.9.23
>> OS: iOS
>> URL: https://hastebin.com/raw/arexecefew
>> Submission from: (NULL) (2620:119:5001:3000:242c:3bea:acec:6a7d)
>
> ITS#8969 perhaps?
>
> <https://www.openldap.org/its/index.cgi/?findid=8969>
No. MAP_FULL is a user error, PAGE_FULL is an internal bug. ITS#8969 has nothing to do with this.
As the doc says, use a large enough mapsize when you create the environment. You can also
use mdb_env_set_mapsize() to change the size of an existing env.
This is not a bug in LMDB, this ITS will be closed.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--On Tuesday, May 03, 2016 12:48 PM +0000 eriixblaike+git(a)gmail.com wrote:
> I, Eric Monson, 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.
>
> https://eriix.org/download_file/eric-monson-16-05-03.patch
This URL is not accessible (requires a login?). I suggest uploading it to
our FTP server as documented for contributed patches.
Thanks!
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
On Mon, Jun 03, 2019 at 09:43:11AM +0000, jpayanides(a)prosodie.com wrote:
> Hello Ondřej,
Hi Jean-Philippe,
> sorry to answer so late, I was off (sick).
>
> Answering your questions:
>
> I didn't try to reproduce the crash on a different system.
this will be the easiest way to get more information both on whether the
crash might be coming from another of the system and, with newer tools,
more about the crash itself.
> What is the goal of installing an new version of gdb on my system ? I am
> not sure it will be easy to proceed.
>From what you have provided, the version of gdb you have used seems to
have issues debugging this program, a newer tool might be able to do a
better job (or you can try remote debugging with gdbserver). But if you
can, trying to reproduce this on a different (newer) system should be
a priority.
> Following your advise, I have corrected the chain configuration with
> removing mode=self, but it didn't change nothing regarding the crash.
>
> do you think it could be possible that the glibc contains bugs resulting
> that crash?
Hard to tell, your system is ancient and I have no idea how stable any
part of it was.
> I do not know what to do. Would it be relevant to upgrade the OS?
If you can upgrade the system at all, please do so, it has been about 12
years since Debian Etch was released and many things have happened
since.
Regards,
--
OndÅ™ej KuznÃk
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Full_Name: Alex
Version: LMDB 0.9.23
OS: iOS
URL: https://hastebin.com/raw/arexecefew
Submission from: (NULL) (2620:119:5001:3000:242c:3bea:acec:6a7d)
Hey guys,
We are using LMDB in our LRUCache implementation and facing the issue: when we
evict old records from this cache sometimes we have MDB_MAP_FULL error though
record eviction by using mdb_del() went fine. We were able to isolate an issue
in the unit test which is run from just one thread. Since there are no any
concurrent readers for this case we are expecting LMDB to claim free pages
immediately after we commit "deletion" transaction, but in some rare cases it
still raises MDB_MAP_FULL error.
The unit test scenario is as follows:
1) start with empty DB
2) keep inserting random records until hi the first MDB_FULL
3) delete some old recrods to some pages
4) try to insert new record and check that is succeeded.
The step 4 fails with another MDB_FULL error
We enable debugging and attached a debug logs from LDMB. Hope it would be
helpful.
--On Sunday, May 26, 2019 12:47 PM +0000 danybensighar(a)gmail.com wrote:
> Full_Name: Dany Bensighar
Hello,
The ITS system is for bug reports. Usage questions such as this should be
sent to the openldap-technical(a)openldap.org mailing list
(<https://www.openldap.org/lists/mm/listinfo/openldap-technical>)
This ITS will be closed.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>