[Date Prev][Date Next]
Re: test002: TLS required?
> > 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
#0 0x40259b9c in memcpy () from /lib/i686/libc.so.6
#1 0x4006ca2f in __ham_bulk (dbc=0x813b7f8, data=0x406fa6bc, flags=67108896)
#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