29.04.2015 19:35, Howard Chu пишет:
Leonid Yuriev wrote:
> 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
>>> 3) lmdb-backend:
>>> 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
>>> 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
> 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.
Yes, I was made same local changes few hours ago.
This fixs miss-call for mdb_cmp_long().
But what about 5-bytes keys from indexer?
- How ones should be compared, as a 4-byte int without MSB, or as a
padded 8-byte long?
- Where is the padding code?