Re: (ITS#3456) test018 consumer segfault

[hyc@symas.com]

That looks like an Efence error, do you have the multithreading patches 
for Efence applied?

Kurt@OpenLDAP.org wrote:

>Finally found the time to run this under ElectricFence...
>Efence SIGBUSs here:
>
>(gdb) where
>#0  slotForUserAddress (address=0x2d4abfd8) at efence.c:685
>#1  0x80e6f0a in free (address=0x2d4abfd8) at efence.c:748
>#2  0x2838cb27 in pthread_attr_destroy () from /usr/lib/libc_r.so.4
>#3  0x80c77f3 in ldap_pvt_thread_create (thread=0xbfbff26c, detach=0, 
>    start_routine=0x8053f1c <slapd_daemon_task>, arg=0x0) at thr_posix.c:133
>#4  0x8054f46 in slapd_daemon () at daemon.c:2032
>#5  0x804d54c in main (argc=8, argv=0xbfbff324) at main.c:770
>
>Hmmm....
>
>Kurt
>
>At 01:22 PM 12/29/2004, kurt@OpenLDAP.org wrote:
>  
>
>>Full_Name: Kurt Zeilenga
>>Version: HEAD
>>OS: FreeBSD4
>>URL: ftp://ftp.openldap.org/incoming/
>>Submission from: (NULL) (198.144.202.244)
>>Submitted by: kurt
>>
>>
>>test018's consumer slapd (w/ provider overlay) is segfaulting upon restart:
>>
>>./run test018
>>Cleaning up test run directory leftover from previous run.
>>Running ./scripts/test018-syncreplication-persist...
>>running defines.sh
>>Starting master slapd on TCP/IP port 9011...
>>Using ldapsearch to check that master slapd is running...
>>Waiting 5 seconds for slapd to start...
>>Using ldapadd to create the context prefix entry in the master...
>>Starting slave slapd on TCP/IP port 9014...
>>Using ldapsearch to check that slave slapd is running...
>>Waiting 5 seconds for slapd to start...
>>Using ldapadd to populate the master directory...
>>Waiting 15 seconds for syncrepl to receive changes...
>>Using ldapmodify to modify master directory...
>>Waiting 15 seconds for syncrepl to receive changes...
>>Stopping consumer to test recovery...
>>Modifying more entries on the master...
>>Restarting consumer...
>>Waiting 25 seconds for syncrepl to receive changes...
>>Segmentation fault (core dumped)
>>Using ldapsearch to read all the entries from the master...
>>Using ldapsearch to read all the entries from the slave...
>>ldapsearch failed at slave (1)!
>>kill: 72396: No such process
>>
>>(gdb) thread apply all bt
>>
>>Thread 1 (process 203424):
>>#0  0x80d3af5 in bdb_idl_fetch_key (be=0x820be00, db=0x8b2c000, tid=0x0, 
>>   key=0xbfb3e7d8, ids=0x832c000, saved_cursor=0x0, get_flag=0) at idl.c:408
>>#1  0x80d5bbf in bdb_key_read (be=0x820be00, db=0x8b2c000, txn=0x0, 
>>   k=0x822c004, ids=0x832c000, saved_cursor=0x0, get_flag=0) at key.c:50
>>#2  0x80d1bd6 in equality_candidates (op=0xbfbfecc4, ava=0xbfb3e9e4, 
>>   ids=0x842c000, tmp=0x832c000) at filterindex.c:642
>>#3  0x80d0956 in bdb_filter_candidates (op=0xbfbfecc4, f=0xbfb3ea08, 
>>   ids=0x842c000, tmp=0x832c000, stack=0x84ac000) at filterindex.c:117
>>#4  0x80d14fc in list_candidates (op=0xbfbfecc4, flist=0xbfb3ea08, ftype=161, 
>>   ids=0x83ac000, tmp=0x832c000, save=0x842c000) at filterindex.c:454
>>#5  0x80d0c5e in bdb_filter_candidates (op=0xbfbfecc4, f=0xbfb3e9fc, 
>>   ids=0x83ac000, tmp=0x832c000, stack=0x842c000) at filterindex.c:166
>>#6  0x80d14fc in list_candidates (op=0xbfbfecc4, flist=0xbfb3e9f0, ftype=160, 
>>   ids=0xbfb7eb40, tmp=0x832c000, save=0x83ac000) at filterindex.c:454
>>#7  0x80d0bf2 in bdb_filter_candidates (op=0xbfbfecc4, f=0xbfb3ea14, 
>>   ids=0xbfb7eb40, tmp=0x832c000, stack=0x83ac000) at filterindex.c:160
>>#8  0x80b02e1 in search_candidates (stackop=0xbfbfecc4, op=0xbfbfecc4, 
>>   rs=0xbfbfec88, e=0xbfb3eb18, locker=28, ids=0xbfb7eb40, scopes=0xbfb3eb40)
>>   at search.c:2089
>>#9  0x80af49f in bdb_do_search (op=0xbfbfecc4, rs=0xbfbfec88, sop=0xbfbfecc4, 
>>   ps_e=0x0, ps_type=0) at search.c:984
>>#10 0x80aecaa in bdb_search (op=0xbfbfecc4, rs=0xbfbfec88) at search.c:603
>>#11 0x8134dd7 in syncprov_findcsn (op=0xbfbfee70, mode=1) at syncprov.c:694
>>#12 0x813788e in syncprov_db_open (be=0x820be00) at syncprov.c:2053
>>#13 0x80a323c in over_db_func (be=0x820be00, which=db_open) at backover.c:55
>>#14 0x80a348b in over_db_open (be=0x820be00) at backover.c:143
>>#15 0x806f7cd in backend_startup_one (be=0x820be00) at backend.c:194
>>#16 0x806fb03 in backend_startup (be=0x0) at backend.c:277
>>#17 0x8085bc8 in slap_startup (be=0x0) at init.c:174
>>#18 0x805dcce in main (argc=8, argv=0xbfbff2dc) at main.c:730
>>
>>When I modify the consumer's configuration file to comment out
>>"overlay syncprovider", test018 will pass.
>>    
>>
>
>
>
>
>  
>


-- 
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support