[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#7715) SIGBUS when mdb is configured with writemap



Thanks. So far the output shows nothing out of the ordinary. Can you also 
provide the output for:
    ls -l /opt/openldap/var/openldap-data

Note from the mmap(2) manpage:

        Use of a mapped region can result in these signals:

        SIGSEGV
               Attempted write into a region mapped as read-only.

        SIGBUS Attempted access to a portion of the buffer that does not 
correspond to the file (for  example,  beyond
               the end of the file, including the case where another process 
has truncated the file).

LMDB always sets the size of the file when using the WRITEMAP option, so the 
SIGBUS condition should never happen. The pointers in your gdb output are all 
within the bounds of the map and mapsize you configured.

What filesystem type is the data directory stored on? This is looking more 
like a kernel or filesystem bug than anything else.

Željko NejaÅ¡miÄ? wrote:
> On Thu, Oct 3, 2013 at 2:57 PM, <hyc@symas.com> wrote:
>>
>> Željko NejaÅ¡miÄ? wrote:
>>> On Wed, Oct 2, 2013 at 6:43 PM, <hyc@symas.com <mailto:hyc@symas.com>> wrote:
>>> I ran the whole test suite for mdb, and as far as I can see, every test
>>> returned OK.
>>>
>>> Found a new way to reproduce the SIGBUS using ldapadd on Ubuntu 12.04 firing
>>> to openldap on RH 6.3:
>>> ldapadd -h 172.17.101.150 -p 389 -D "cn=admin,dc=test" -w test -f test.ldif --
>>> ldif file is the same as the previous ldclt command. Doubt it matters, but the
>>> ldif file is 1M adds.
>>
>> Can you provide your slapd config and this LDIF?
>
>
> LDIF file is just 1M adds of the following format:
> dn: uid=XXXXXXX,ds=USERS,o=STANDARD,dc=spr
> objectClass: sprUser
>
> I've uploaded the config here: http://hastebin.com/nicecafaci.ldif
>
>>> On the RH box:
>>> - compiled openldap with -g -O0 and previously used flags
>>> gdb `find /root/openldap/ -type d -printf '-d %p '` --args
>>> /opt/openldap/libexec/slapd -h "ldap:/// ldapi:///" -F
>>> /opt/openldap/etc/openldap/slapd.d -g openldap -u openldap -d 0
>>>
>>> gdb output:
>>> bt -- http://hastebin.com/hefikekaxi.sh
>>> bt 10 full -- http://hastebin.com/vudocosuka.sh
>>
>> Can you also provide the gdb output for
>>     print *env
>
> (gdb) print *env
> $1 = {me_fd = 15, me_lfd = 14, me_mfd = 15, me_flags = 940113920,
> me_psize = 4096,
>    me_maxreaders = 126, me_numreaders = 2, me_numdbs = 13, me_maxdbs =
> 130, me_pid = 43974,
>    me_path = 0x8c19a0 "/opt/openldap/var/openldap-data", me_map =
> 0x7ff6f721f000 "",
>    me_txns = 0x7ffff7ffb000, me_metas = {0x7ff6f721f010,
> 0x7ff6f7220010}, me_txn = 0x7ff6dc10afd0,
>    me_mapsize = 38654705664, me_size = 0, me_maxpg = 9437184, me_dbxs = 0x8eed10,
>    me_dbflags = 0x8ceb40, me_txkey = 1, me_pgstate = {mf_pghead =
> 0x7ff6dc109d58, mf_pglast = 44},
>    me_dpages = 0x0, me_free_pgs = 0xaf75e8, me_dirty_list =
> 0x7ffff721f010, me_maxfree_1pg = 509,
>    me_nodemax = 2040}
>
>>     -- Howard Chu
>>     CTO, Symas Corp.           http://www.symas.com
>>     Director, Highland Sun     http://highlandsun.com/hyc/
>>     Chief Architect, OpenLDAP  http://www.openldap.org/project/
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/