[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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: hyc@symas.com
- Date: Wed, 29 Apr 2015 16:35:27 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/