openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

(ITS#8420) lmdb Windows sizeof(off_t) == sizeof(int32_t)
by clayton.stangeland＠gmail.com 08 May '16

08 May '16

Full_Name: Clayton Stangeland Version: lmdb master a04aad31c2 OS: Windows 7 64 bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.54.58.5) This is an lmdb bug. mdb_page_flush fails as database size nears 2 GB on Windows. The reason is off_t == int32_t on Windows. So the off_t pos variable becomes negative and this section of code in mdb_page_flush enters the error condition as ov.OffsetHigh is also negative: ov.Offset = pos & 0xffffffff; ov.OffsetHigh = pos >> 16 >> 16; if (!WriteFile(env->me_fd, dp, size, NULL, &ov)) { rc = ErrCode(); DPRINTF(("WriteFile: %d", rc)); return rc; } Adding23dedefine off_t int64_t in an #ifdef _WIN32 region solves this.

1 0

Re: (ITS#8419) mdb_env_stat crashes when the env argument hasn't been opened yet
by hyc＠symas.com 08 May '16

08 May '16

On Sat, May 07, 2016 at 10:39:29PM +0000, aschorr(a)telemetry-investments.com wrote: > Hi, FYI, mdb_env_info has the same issue. Dup of ITS#8401, closing this ITS. > > Thanks, > Andy > > >

1 0

Re: (ITS#8419) mdb_env_stat crashes when the env argument hasn't been opened yet
by aschorr＠telemetry-investments.com 08 May '16

08 May '16

Hi, FYI, mdb_env_info has the same issue. Thanks, Andy

1 0

(ITS#8419) mdb_env_stat crashes when the env argument hasn't been opened yet
by aschorr＠telemetry-investments.com 08 May '16

08 May '16

Full_Name: Andrew Schorr Version: lmdb 0.9.18 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.76.0.51) I am implementing a gawk lmdb API. As a silly test, I ran the following code: gawk -l lmdb ' BEGIN { env = mdb_env_create() rc = mdb_env_stat(env, f) }' It catches a SIGSEGV. It is apparently illegal to call mdb_env_stat before calling mdb_open. Please consider updating the documentation or updating the function to protect against this situation. Thanks, Andy

1 0

Re: (ITS#8418) mdb_load performance
by aschorr＠telemetry-investments.com 06 May '16

06 May '16

Hi, sorry, please close this issue. I am unable to duplicate my initial results. The use of a cursor seems to be marginally helpful, and I no longer see any slowdown from batching the commits. I guess my server must have had some other loads on it that impacted my previous test results. I do see one odd result of batching -- the process ru_maxrss value reported by getrusage is much higher (10 GB vs 3 GB for my test data). I'm not sure why that's the case. Perhaps that resulted in some swapping during my initial test. Sorry for wasting your time. Regards, Andy On Thu, May 05, 2016 at 09:56:10PM +0000, openldap-its(a)OpenLDAP.org wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#8418. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#8418) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#8418) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=8418 > > Please remember to retain your issue tracking number (ITS#8418) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > -- Andrew Schorr e-mail: aschorr(a)telemetry-investments.com Telemetry Investments, L.L.C. phone: 917-305-1748 545 Fifth Ave, Suite 1108 fax: 212-425-5550 New York, NY 10017-3630

1 0

(ITS#8418) mdb_load performance
by aschorr＠telemetry-investments.com 05 May '16

05 May '16

Full_Name: Andrew Schorr Version: lmdb 0.9.18 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.76.0.51) I patched mdb_load to add an option to set the mapsize with -T, as per open issue #8417. I then used it to load a 7 GB text file, and I found that the calls to mdb_txn_commit after every 100 mdb_cursor_put calls really slows down performance. If one comments out the batching, it goes much faster. And even faster is to avoid the cursor and just call mdb_put in a loop. Is there a reason mdb_load commits after every 100 puts?

1 0

Re: (ITS#8303) An Asynchronous meta back-end for OpenLDAP
by nivanova＠symas.com 03 May '16

03 May '16

This is a patch that removes some unused attributes from olcAsyncMetaConfig. These attributes were removed when some configuration options were removed for asyncmeta, being no longer applicable, but removing them from the class definition was missed. ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160503.patch

1 0

(ITS#8417) mdb_load could use an option to specify the mapsize.
by eriixblaike+git＠gmail.com 03 May '16

03 May '16

Full_Name: Eric R. Monson Version: git 3fe9678baa1be8067e7e0bbb94007a096952e62c OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.193.242.31) The lack of a mapsize option available in mdb_load can make it inconvenient to load datasets. This is particularly true when you are using the plaintext format specified by '-T', since it has no header you could add an appropriate mapsize to. My patch resolves this by adding a mapsize option ('-m') which can be used to manually specify a mapsize of your choosing, overriding both the default and any value specified in the header of the database you're loading. The patch also modifies the man page for mdb_load to reflect the new functionality. I don't know if the code is good enough for inclusion, but I figured providing my solution was better than nothing. 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

1 0

(ITS#8416) Cross compiling failed
by vystrcil.martin＠gmail.com 03 May '16

03 May '16

Full_Name: Martin Vystrcil Version: 2.4.4 OS: Linux Mint URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.32.219.136) While cross compiling it is not able to strip final binaries. My config command: ./configure --host=arm-linux-gnueabihf CC=/home/martin/Development/SMON3/testing/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin/arm-linux-gnueabihf-gcc STRIP=/home/martin/Development/SMON3/testing/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin/arm-linux-gnueabihf-strip --with-yielding_select=yes --prefix=/home/martin/Development/SMON3/testing/ldap What it prints (fail with) make[2]: Entering director%6`/home/martin/Development/SMON3/testing/openldap-2.4.44/clients/tools' ../../build/shtool mkdir -p /home/martin/Development/SMON3/testing/ldap/bin ../../build/shtool install -c -m 755 -s ldapsearch /home/martin/Development/SMON3/testing/ldap/bin/ldapsearch strip: Unable to recognise the format of the input file `/home/martin/Development/SMON3/testing/ldap/bin/#INST@30215#' Why this happen ? In file build/shtool is following construction. if [ ".$opt_s" = .yes ]; then if [ ".$opt_t" = .yes ]; then echo "strip $dsttmp" 1>&2 fi strip $dsttmp || shtool_exit $? fi In my opinion there should be strip based on config. In config there it is set correctly. Please lememe know, h t to fix this correctly, I'm not such an expert for automake.

1 0

Re: (ITS#8415) Documentation has hard coded date
by quanah＠zimbra.com 02 May '16

02 May '16

--On Monday, May 02, 2016 8:57 PM +0200 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no> wrote: > openldap-etc.git:misc/crupdate.sh needs a fix so it also > recognizes these two dates, and/or the .sdf copyright notices > can be modified so crupdate catches them. Right, that's the goal here. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

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