[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: (ITS#3989) syncprov core dumps when combined with uniqueness overlay

To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#3989) syncprov core dumps when combined with uniqueness overlay
From: ando@sys-net.it
Date: Fri, 2 Sep 2005 07:44:44 GMT
I've read that portion of code up to back-bdb internals (where I nearly 
get lost) and I don't see anything strange.  I'd be curious to see what 
data your ACL is requesting; can you print (massaged, if required), from 
frame #9:
    target->e_nname
    *gr_ndn
    *op_ndn
    *group_oc
    *group_at
Can you reduce it to a very simple setup (e.g. from the testsuite data 
plus the offending ACL) so that we can try to reproduce and track it?

p.

quanah@stanford.edu wrote:

>--On Wednesday, August 31, 2005 3:10 AM +0000 openldap-its@OpenLDAP.org 
>wrote:
>
>I've found how to recreate this as many times as I want in 2.3.7, so gdb'd 
>the running process.
>
>Output is:
>
>Program received signal SIGSEGV, Segmentation fault.
>[Switching to LWP 3]
>0xfedc1e58 in _malloc_unlocked () from /usr/lib/libc.so.1
>
>
>(gdb) thread 3
>[Switching to thread 3 (LWP 4)]#0  __lock_get_internal (lt=0x22e608, 
>locker=2147483657, flags=0, obj=0x0, lock_mode=DB_LOCK_READ, timeout=0,
>    lock=0x7dbfd470) at ../lock/lock.c:843
>843     ../lock/lock.c: No such file or directory.
>        in ../lock/lock.c
>(gdb) bt
>#0  __lock_get_internal (lt=0x22e608, locker=2147483657, flags=0, obj=0x0, 
>lock_mode=DB_LOCK_READ, timeout=0, lock=0x7dbfd470) at ../lock/lock.c:843
>#1  0xff28feac in __lock_get (dbenv=0x22be48, locker=2147483657, flags=0, 
>obj=0x7dbfd280, lock_mode=DB_LOCK_READ, lock=0x7dbfd470) at 
>../lock/lock.c:586
>#2  0xff28fe10 in __lock_get_pp (dbenv=0x22be48, locker=2147483657, 
>flags=0, obj=0x7dbfd280, lock_mode=DB_LOCK_READ, lock=0x7dbfd470) at 
>../lock/lock.c:557
>#3  0x0009aac4 in bdb_cache_entry_db_lock (env=0x22be48, locker=2147483657, 
>ei=0xbb69a8, rw=0, tryOnly=0, lock=0x7dbfd470) at cache.c:135
>#4  0x0009b2a0 in bdb_cache_find_id (op=0x267e10, tid=0xbe0120, id=15, 
>eip=0x7dbfd3ec, islocked=0, locker=2147483657, lock=0x7dbfd470) at 
>cache.c:713
>#5  0x0009ec70 in bdb_dn2entry (op=0x267e10, tid=0xbe0120, dn=0x7dbfdaf0, 
>e=0x7dbfd468, matched=0, locker=2147483657, lock=0x7dbfd470) at 
>dn2entry.c:65
>#6  0x000a25cc in bdb_entry_get (op=0x267e10, ndn=0x7dbfdaf0, oc=0x1b9af0, 
>at=0x162800, rw=0, ent=0x7dbfd56c) at id2entry.c:349
>#7  0x00032378 in be_entry_get_rw (op=0x1b35b0, ndn=0x7dbfdaf0, 
>oc=0x1b9af0, at=0x162800, rw=0, e=0x7dbfd56c) at backend.c:1194
>#8  0x00032418 in fe_acl_group (op=0x267e10, target=0x7dbff470, 
>gr_ndn=0x7dbfdaf0, op_ndn=0x267ea8, group_oc=0x1b9af0, group_at=0x1de6a0) 
>at backend.c:1239
>#9  0x000328f4 in backend_group (op=0x267e10, target=0x7dbff470, 
>gr_ndn=0x7dbfdaf0, op_ndn=0x267ea8, group_oc=0x1b9af0, group_at=0x1de6a0) 
>at backend.c:1390
>#10 0x00044dc4 in slap_acl_mask (a=0x1dfa90, mask=0x7dbfdfb4, op=0x267e10, 
>e=0x7dbff470, desc=0x1dfd20, val=0x0, nmatch=100, matches=0x7dbfdfb8, 
>count=3,
>    state=0x7dbfe9a8) at acl.c:1849
>#11 0x00043094 in access_allowed_mask (op=0x267e10, e=0x7dbff470, 
>desc=0x251528, val=0x0, access=ACL_WDEL, state=0x7dbfe9a8, maskp=0x0) at 
>acl.c:737
>#12 0x00045e8c in acl_check_modlist (op=0x267e10, e=0x7dbff470, 
>mlist=0x251168) at acl.c:2334
>#13 0x00078a98 in bdb_modify_internal (op=0x267e10, tid=0xbe01a8, 
>modlist=0x251168, e=0x7dbff470, text=0x7dbffd6c, textbuf=0x7dbff4b0 "", 
>textlen=256)
>    at modify.c:49
>#14 0x000798cc in bdb_modify (op=0x267e10, rs=0x7dbffd58) at modify.c:467
>#15 0x00072adc in overlay_op_walk (op=0x267e10, rs=0x7dbffd58, which=32768, 
>oi=0x159754, on=0x8000) at backover.c:488
>#16 0x00072bd0 in over_op_func (op=0x267e10, rs=0x7dbffd58, 
>which=op_modify) at backover.c:540
>#17 0x0003a950 in fe_op_modify (op=0x267e10, rs=0x7dbffd58) at modify.c:417
>#18 0x0003a158 in do_modify (op=0x267e10, rs=0x7dbffd58) at modify.c:200
>#19 0x00026ba4 in connection_operation (ctx=0xf9400, arg_v=0x267e10) at 
>connection.c:1061
>#20 0xff33cd70 in ldap_int_thread_pool_wrapper (xpool=0x190a00) at 
>tpool.c:487
>#21 0xfed658c8 in _lwp_start () from /usr/lib/lwp/libthread.so.1
>#22 0xfed658c8 in _lwp_start () from /usr/lib/lwp/libthread.so.1
>Previous frame identical to this frame (corrupt stack?)
>
>
>(gdb) thread 2
>[Switching to thread 2 (LWP 3)]#0  0xfedc1e58 in _malloc_unlocked () from 
>/usr/lib/libc.so.1
>(gdb) bt
>#0  0xfedc1e58 in _malloc_unlocked () from /usr/lib/libc.so.1
>#1  0xfedc1ce0 in malloc () from /usr/lib/libc.so.1
>#2  0xfec8d1b8 in decrypt_internal_derived (context=0x2672d8, 
>crypto=0xbcd980, usage=24, data=0xbe27e0, len=51, result=0x7e3ff140, 
>ivec=0x0)
>    at ../../../lib/krb5/crypto.c:3454
>#3  0xfec8d78c in krb5_decrypt (context=0x2672d8, crypto=0xbcd980, 
>usage=24, data=0xbe27e0, len=51, result=0x7e3ff140) at 
>../../../lib/krb5/crypto.c:3693
>#4  0xfecdb050 in _gssapi_unwrap_cfx (minor_status=0x7e3ff23c, 
>context_handle=0x18, input_message_buffer=0x7e3ff140, 
>output_message_buffer=0x7e3ff240,
>    conf_state=0xbe27e0, qop_state=0x0, key=0xc0c700) at 
>../../../lib/gssapi/cfx.c:521
>#5  0xfece0ad4 in gss_unwrap (minor_status=0x7e3ff23c, 
>context_handle=0xbe0508, input_message_buffer=0x7e3ff248, 
>output_message_buffer=0x7e3ff240,
>    conf_state=0x0, qop_state=0x0) at ../../../lib/gssapi/unwrap.c:406
>#6  0xfed01af0 in gssapi_decode_packet () from 
>/usr/local/lib/sasl2/libgssapiv2.so.2
>#7  0xff1e272c in _plug_decode () from /usr/local/lib/libsasl2.so.2
>#8  0xfed01c24 in gssapi_decode () from 
>/usr/local/lib/sasl2/libgssapiv2.so.2
>#9  0xff1d88fc in sasl_decode () from /usr/local/lib/libsasl2.so.2
>#10 0xff3433bc in sb_sasl_read (sbiod=0xbcd660, buf=0xbe076f, len=8) at 
>cyrus.c:316
>#11 0xff309af8 in sb_debug_read (sbiod=0xbcd4c0, buf=0xbe076f, len=8) at 
>sockbuf.c:823
>#12 0xff308f88 in ber_int_sb_read (sb=0x250fd8, buf=0xbe076f, len=8) at 
>sockbuf.c:411
>#13 0xff306568 in ber_get_next (sb=0x250fd8, len=0x7e3ff67c, ber=0xbe0760) 
>at io.c:514
>#14 0x0002741c in connection_input (conn=0x253370) at connection.c:1397
>#15 0x00026f38 in connection_read (s=18) at connection.c:1322
>#16 0x00024174 in slapd_daemon_task (ptr=0xf1400) at daemon.c:1879
>#17 0xfed658c8 in _lwp_start () from /usr/lib/lwp/libthread.so.1
>#18 0xfed658c8 in _lwp_start () from /usr/lib/lwp/libthread.so.1
>Previous frame identical to this frame (corrupt stack?)
>
>
>(gdb) thread 1
>[Switching to thread 1 (LWP 1)]#0  0xfee1f33c in _lwp_wait () from 
>/usr/lib/libc.so.1
>(gdb) bt
>#0  0xfee1f33c in _lwp_wait () from /usr/lib/libc.so.1
>#1  0xfed5d7b8 in lwp_wait () from /usr/lib/lwp/libthread.so.1
>#2  0xfed590a0 in _thrp_join () from /usr/lib/lwp/libthread.so.1
>#3  0x0002480c in slapd_daemon () at daemon.c:2045
>#4  0x000169ec in main ()
>
>
>
>
>
>--
>Quanah Gibson-Mount
>Principal Software Developer
>ITSS/Shared Services
>Stanford University
>GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
>
>"These censorship operations against schools and libraries are stronger
>than ever in the present religio-political climate. They often focus on
>fantasy and sf books, which foster that deadly enemy to bigotry and blind
>faith, the imagination." -- Ursula K. Le Guin
>
>
>  
>



    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497
Prev by Date: Re: (ITS#3989) syncprov core dumps when combined with uniqueness overlay
Next by Date: Re: (ITS#3989) syncprov core dumps when combined with uniqueness overlay
Index(es):
- Chronological
- Thread