Leonid Yuriev wrote: > > > 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
OK, fixed in git. For the record, this affected MDB_INTEGERDUP, not MDB_INTEGERKEY. >>> 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. Ah yes, the padding is currently only done on platforms that don't allow unaligned access to ints (e.g. Sparc) git rev e2a7617d17368b5787fc24fbd017623d00fe162b > 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. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
