29.04.2015 16:06, Howard Chu пиÑеÑ: > [email protected] 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.
