[Date Prev][Date Next]
Re: (ITS#8117) Bugs related to key-size in lmdb and backend
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#8117) Bugs related to key-size in lmdb and backend
- From: email@example.com
- Date: Wed, 29 Apr 2015 17:25:31 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
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?