Re: (ITS#8117) Bugs related to key-size in lmdb and backend

[leo@yuriev.ru]

29.04.2015 16:06, Howard Chu пиÑ?еÑ?:
> leo@yuriev.ru wrote:
>> Full_Name: Leo Yuriev
>> Version: 2.4-HEAD
>> OS: RHEL7
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (31.130.36.33)
>>
>>
>> 1) LMDB: On 64-bit systems, in some cases mdb_cmp_int() could be 
>> called instead
>> of mdb_cmp_long(), when key.mv_size == 8.
>> To reproduce this is enough add an assertion-check for key.size == 
>> sizeof(int)
>> into mdb_cmp_int().A%A
>
> You need to provide more details than this. mdb_cmp_int() isn't even 
> used on regular databases, only on DUPSORT databases. Provide actual 
> code reproducing the issue.
>
this is enough:
- add assert(a->mv_key_size == sizeof(size_t)) into mdb_cmp_long()
- make all test
- see a coredump
>
>> 2) LMDB: There is no any checking for invalid key-size for 
>> MDB_INTEGERKEY and
>> MDB_INTEGERDUP. Therefore, for example, mdb_cursor_put() accepts a 
>> key.size == 1
>> and so forth.
>
> Not a bug, MDB_INTEGERKEY is documented to only be used with 
> word-sized keys.

Ok, let it be "a feature" ;)

>> 3) lmdb-backend: 
>> AttributeDescription->ad_type->sat_equality->smr_indexer()
>> could generate a 5-byte sized ks.s. I can just imagine what this can 
>> create a
>> many problems. For instance, when I adds the control for key size, it 
>> breaks
>> test017-syncreplication-refresh. But I am not tested more.
>
> Not a bug, indexer keys are padded to 8 bytes.

There is just NOT padded, I am sure.
Also this is reason for unaligned-access in mdb_cmp_int() and 
mdb_cmp_long().
It is similar to reproduce, just assert + make test.

Seems that bugs together could break ordering of entries, this is 
detected by loop over all entries with mdb_cursor_get(..., MDB_NEXT) and 
comparing keys from previous step.
All of this I was found today, during developing a mdb_chk tool.

>> P.S.
>> It is a one more nice rebus from Howard ;)
>
> Thanks for the irrelevant editorials. It might even be amusing if they 
> were true, but mostly they just demonstrate your inexperience.
>
Code style and code quality of OpenLDAP - is just a trash (IMHO).
By functional is a 100 times simple than (for instance) 
Linux/FreeBSD/Windows kernel, or PostgreSQL.
But simultaneously it is 100 times harder to find and fix bugs or make a 
some progress.
You can't hide the obvious.