Leonid Yuriev wrote:

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

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.