Re: test002: TLS required?

[Pierangelo Masarati <masarati@aero.polimi.it>]

> > I did a complete make clean, cvs update, configure, rebuild, no errors.
> > make test runs both bdb and ldbm to completion. (And by the way, bdb is
> > noticably faster than ldbm now. test008 finishes in 0:59 on back-bdb, and
> > 1:16 on back-ldbm on my PII-400.)
> 
> I'm having a "random" amount of problems in running tests with bdb; 
> recently I'm expereincing failures right from test003-search, where
> tests with equality filter cause slapd to die (actually to hang).  
> I stepped thru the code but with little success (I have to say that 
> I've very little time to dedicate to the problem). I note I was using 
> gcc 3.0.2 and db 3.3, so I rebuilt from scratch with gcc 2.95 (RedHat's 
> 2.96) and db 4.0 and the exact filter search makes slapd hang.  I'll 
> dig into it further, if I have time.  Is there any suggestion (hints,
> special settings, twirks you used in building back-bdb) you can give?

Program received signal SIGSEGV, Segmentation fault.
0x40259b9c in memcpy () from /lib/i686/libc.so.6
(gdb) bt
#0  0x40259b9c in memcpy () from /lib/i686/libc.so.6
#1  0x4006ca2f in __ham_bulk (dbc=0x813b7f8, data=0x406fa6bc, flags=67108896)
    at ../hash/hash.c:1141
#2  0x400524dc in __db_c_get (dbc_arg=0x813a650, key=0x406fa72c, 
    data=0x406fa6bc, flags=32) at ../db/db_cam.c:817
#3  0x08091513 in bdb_idl_fetch_key (be=0x810a788, db=0x8139be0, tid=0x0, 
    key=0x406fa72c, ids=0x4077a89c) at idl.c:253
#4  0x08092b26 in bdb_key_read (be=0x810a788, db=0x8139be0, txn=0x0, 
    k=0x813b7d0, ids=0x4077a89c) at key.c:42
#5  0x080904d3 in equality_candidates (be=0x810a788, ava=0x81396d0, 
    ids=0x406fa80c, tmp=0x4077a89c) at filterindex.c:320
#6  0x0808fab0 in bdb_filter_candidates (be=0x810a788, f=0x81396c0, 
    ids=0x406fa80c, tmp=0x4077a89c) at filterindex.c:74
#7  0x0808ff41 in list_candidates (be=0x810a788, flist=0x407fa8cc, ftype=160, 
    ids=0x407fa98c, tmp=0x4077a89c) at filterindex.c:160
#8  0x0808fce4 in bdb_filter_candidates (be=0x810a788, f=0x407fa8dc, 
    ids=0x407fa98c, tmp=0x4077a89c) at filterindex.c:106
#9  0x0807f6c8 in search_candidates (be=0x810a788, op=0x8139488, e=0x8139908, 
    filter=0x81396c0, scope=2, deref=0, ids=0x407fa98c) at search.c:614
#10 0x0807edcc in bdb_search (be=0x810a788, conn=0x4043dd60, op=0x8139488, 
    base=0x4087aa24, nbase=0x4087aa2c, scope=2, deref=0, slimit=500, 
    tlimit=3600, filter=0x81396c0, filterstr=0x4087aa14, attrs=0x0, 
    attrsonly=0) at search.c:242
#11 0x08051b2f in do_search (conn=0x4043dd60, op=0x8139488) at search.c:315
#12 0x08050540 in connection_operation (arg_v=0x8139508) at connection.c:952
#13 0x080ad976 in ldap_int_thread_pool_wrapper (pool=0x80ff9e8) at tpool.c:402
#14 0x401c2bfd in pthread_start_thread (arg=0x4087ac00) at manager.c:262
#15 0x401c2cdf in pthread_start_thread_event (arg=0x4087ac00) at manager.c:285

The error now is reproducible; it happens inside the db; 
the arguments it is passed seem to be fine, but I have 
only a limited perception of how the backend works.
I definitely don't have time to debug db 4.0 !

I'll try without IDL_MULTI

Ando