Re: SEGV on syncRepl provider (ITS#3296)

[richton@nbcs.rutgers.edu]

> I suggest you either experiment with HEAD or wait for

With ITS#3320 resolved I've been able to work with HEAD. The problem seems
to occur much less often. Even running under watchmalloc, which was a
fairly reliable method to kill RE22, works nicer in HEAD. However, I can't
claim full resolution, as I did observe one SEGV in HEAD today.

Thread 1 (process 332925    ):
#0  0x00119844 in bdb_cache_lru_add () at index.c:318
#1  0x0011a244 in hdb_cache_find_id (op=0x4473fc0, tid=0x0, id=937,
    eip=0xd933f8f8, islocked=0, locker=132, lock=0xd933f78c) at cache.c:763
#2  0x000f9428 in hdb_do_search () at tools.c:294
#3  0x000f6ec4 in hdb_search () at tools.c:294
#4  0x0005ad78 in fe_op_search (op=0x4473fc0, rs=0xd93ffd50) at search.c:408
#5  0x0005a67c in do_search (op=0x4473fc0, rs=0xd93ffd50) at search.c:224
#6  0x00057284 in connection_operation (ctx=0xd93ffe14, arg_v=0x4473fc0)
    at connection.c:991
#7  0x001411c8 in ldap_int_thread_pool_wrapper (xpool=0x234810) at tpool.c:467

Other threads are parked. As in previous followups, this thread is doing a
syncRepl consumer search. This was using watchmalloc, so if there is
memory corruption, the stack trace should be fairly close to the actual
point of corruption.