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.