Re: (ITS#9162) dbMaxSize property does not as expected
by quanah＠symas.com
--On Monday, February 3, 2020 9:49 AM +0000 pasumarthivijaykumar(a)gmail.com
wrote:
> Full_Name: Vijay Kumar
> Version: 2.4.48
> OS: windows
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (103.204.96.6)
Please stop filing ITSes, as you clearly are working with an already broken
database. 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>
3 years, 10 months
Re: (ITS#8988) Undefined Behavior in slapadd
by hyc＠symas.com
openldap-technical(a)kolttonen.fi wrote:
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
>
> ---1463811718-806940296-1580670508=:196090
> Content-Type: text/plain; charset=ISO-8859-15
> Content-Transfer-Encoding: 8BIT
>
>
> Hello,
>
> On Sat, 8 Jun 2019, hyc(a)symas.com wrote:
>
>> The gcc/clang folks have their heads up their asses. They've
>> deliberately misinterpreted the spec claiming undefined behaviors are
>> forbidden, supposedly to enable essential optimizations. Most of which
>> only apply to obscure corner cases in compiler benchmark suites, that
>> nobody in the real world ever benefits from.
>
> I realize this thread is very old, but Jeff and the C compiler folks are
> right. All C programs that invoke undefined behavior are illegal C
> programs and should be fixed.
>
> Posix threads are well-defined by Posix standards, so calling them
> "undefined behaviour" is not a valid argument.
No. The POSIX spec is *not* a part of the C spec - yet it is still valid.
Which simply proves the point that just because something is not defined
in the C spec does not make it invalid. The compiler guys are idiots for
taking this position.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3 years, 10 months
(ITS#9162) dbMaxSize property does not as expected
by pasumarthivijaykumar＠gmail.com
Full_Name: Vijay Kumar
Version: 2.4.48
OS: windows
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (103.204.96.6)
if i try to set the value from property, i dont understand from where the value
1406945XXXXXX and getting set.
Please check the details mentioned.
1) olcDbMaxSize: 10485760
>mdb_stat.exe -rne "C:\testMaxSize2\mdb\data.mdb"
Environment Info
Map address: 0000000000000000
Map size: 140694549168128
Page size: 4096
Max pages: 34349255168
Number of pages used: 2
Last transaction ID: 0
Max readers: 126
Number of readers used: 0
Reader Table Status
(no active readers)
>slapd.exe -T add -F ..\slapd.d -l backupContent.ldif
5e37a371 mdb_db_open: database "o=abc.net" cannot be opened: ⁿ (87).
Restore from backup!
5e37a371 backend_startup_one (type=mdb, suffix="o=abc.net"): bi_db_open failed!
(87)
slap_startup failed
2) olcDbMaxSize: 1048576
>slapd.exe -T add -F ..\slapd.d -l backupContent.ldif
5e37a5ef mdb_db_open: database "o=abc.net" cannot be opened: ⁿ (87).
Restore from backup!
5e37a5ef backend_startup_one (type=mdb, suffix="o=abc.net"): bi_db_open failed!
(87)
slap_startup failed
>mdb_stat.exe -rne "C:\testMaxSize2\mdb\data.mdb"
Environment Info
Map address: 0000000000000000
Map size: 140694539730944
Page size: 4096
Max pages: 34349252864
Number of pages used: 2
Last transaction ID: 0
Max readers: 126
Number of readers used: 0
Reader Table Status
(no active readers)
3) olcDbMaxSize: 1024
>slapd.exe -T add -F ..\slapd.d -l backupContent.ldif
5e37a7fd mdb_db_open: database "o=abc.net" cannot be opened: ⁿ (87).
Restore from backup!
5e37a7fd backend_startup_one (type=mdb, suffix="o=abc.net"): bi_db_open failed!
(87)
slap_startup failed
>mdb_stat.exe -rne "C:\testMaxSize2\mdb\data.mdb"
Environment Info
Map address: 0000000000000000
Map size: 140694538683392
Page size: 4096
Max pages: 34349252608
Number of pages used: 2
Last transaction ID: 0
Max readers: 126
Number of readers used: 0
Reader Table Status
(no active readers)
5) olcDbMaxSize 10
>slapd.exe -T add -F ..\slapd.d -l backupContent.ldif
5e37a92b mdb_db_open: database "o=abc.net" cannot be opened: ⁿ (87).
Restore from backup!
5e37a92b backend_startup_one (type=mdb, suffix="o=abc.net"): bi_db_open failed!
(87)
slap_startup failed
>mdb_stat.exe -rne "C:\testMaxSize2\mdb\data.mdb"
Environment Info
Map address: 0000000000000000
Map size: 140694538682378
Page size: 4096
Max pages: 34349252608
Number of pages used: 2
Last transaction ID: 0
Max readers: 126
Number of readers used: 0
Reader Table Status
(no active readers)
6) olcDbMaxSize 1
>slapd.exe -T add -F ..\slapd.d -l backupContent.ldif
5e37a92b mdb_db_open: database "o=abc.net" cannot be opened: ⁿ (87).
Restore from backup!
5e37a92b backend_startup_one (type=mdb, suffix="o=abc.net"): bi_db_open failed!
(87)
slap_startup failed
>mdb_stat.exe -rne "C:\testMaxSize2\mdb\data.mdb"
Environment Info
Map address: 0000000000000000
Map size: 140694538682369
Page size: 4096
Max pages: 34349252608
Number of pages used: 2
Last transaction ID: 0
Max readers: 126
Number of readers used: 0
Reader Table Status
(no active readers)
7) olcDbMaxSize not set
>mdb_stat.exe -rne "C:\testMaxSize2\mdb\data.mdb"
Environment Info
Map address: 0000000000000000
Map size: 1048576
Page size: 4096
Max pages: 256
Number of pages used: 254
Last transaction ID: 104
Max readers: 126
Number of readers used: 0
Reader Table Status
(no active readers)
3 years, 10 months
Re: (ITS#8988) Undefined Behavior in slapadd
by openldap-technical＠kolttonen.fi
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---1463811718-326687762-1580674674=:196994
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8BIT
On Sun, 2 Feb 2020, openldap-technical(a)kolttonen.fi wrote:
> I realize this thread is very old, but Jeff and the C compiler folks are
> right. All C programs that invoke undefined behavior are illegal C
> programs and should be fixed.
>
> Posix threads are well-defined by Posix standards, so calling them
> "undefined behaviour" is not a valid argument.
To make it clear that UB in C programs is horrible, let me provide a real
world example of UB: Cyrus IMAPD had an unnoticed dormant strcpy() related
UB bug for several years. You see, the manual page of strcpy() says that
the src and dst strings must not overlap, or else the C program invokes
UB.
For many years, Cyrus operated correctly even though the src and dst
strings *did* overlap in one part of their database code. UB of course
allows this behaviour too. The reason was because GNU libc folks had
written their strcpy() implementation in such a way that breaking the
contract of having non-overlapping strings did not cause any problems.
Then, years later, GNU libc folks deciced to optimize (or otherwise
change) their strcpy() implementation. Now the new implementation punished
all UB invokers, and we saw our Cyrus mailbox database slowly but surely
getting corrupted.
It is indeed shocking to hear that LMDB implementation invokes UB. GCC and
Clang could change their behaviour tomorrow, and LMDB could get corrupted,
crash or whatever. And certainly the blame would be on LMDB code, not the
compiler writers.
Best Regards,
Jokke Hämäläinen
---1463811718-326687762-1580674674=:196994--
3 years, 10 months
Re: (ITS#8988) Undefined Behavior in slapadd
by openldap-technical＠kolttonen.fi
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---1463811718-806940296-1580670508=:196090
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8BIT
Hello,
On Sat, 8 Jun 2019, hyc(a)symas.com wrote:
> The gcc/clang folks have their heads up their asses. They've
> deliberately misinterpreted the spec claiming undefined behaviors are
> forbidden, supposedly to enable essential optimizations. Most of which
> only apply to obscure corner cases in compiler benchmark suites, that
> nobody in the real world ever benefits from.
I realize this thread is very old, but Jeff and the C compiler folks are
right. All C programs that invoke undefined behavior are illegal C
programs and should be fixed.
Posix threads are well-defined by Posix standards, so calling them
"undefined behaviour" is not a valid argument.
Best regards,
Jokke Hämäläinen
---1463811718-806940296-1580670508=:196090--
3 years, 10 months
