Full_Name: Alan Richard Knowles Version: 1.1 Stable OS: Linux (Debian 2.0) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.64.34.22) Seg faults on base searching, (intermitant) gbd info stack #0 0x400dcb04 in __syscall_sigsuspend () #1 0x401010ec in svc_fdset () #2 0x4006159d in pthread_create () #3 0x8049cd5 in main (argc=2, argv=0xbffffcf4) at main.c:189 could be a bug in the implementation of pthreads (not sure how to check which version I have of this)
I assume this is the same slapd crash you noted on stable when doing: Alan Knowles wrote: ># ldapsearch -b '' 'member=cn=julian knowles,o=ossc,c=hk' >will cause it to segfault. (with or without acls) > where as ># ldapsearch -b 'c=hk' 'member=cn=julian knowles,o=ossc,c=hk' >will work quite happily (if you were doing a different operation, please provide details). > At 02:53 AM 12/19/98 GMT, alan_k@HK.Super.NET wrote: >Full_Name: Alan Richard Knowles >Version: 1.1 Stable >OS: Linux (Debian 2.0) >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (202.64.34.22) > > >Seg faults on base searching, (intermitant) >gbd >info stack >#0 0x400dcb04 in __syscall_sigsuspend () >#1 0x401010ec in svc_fdset () >#2 0x4006159d in pthread_create () >#3 0x8049cd5 in main (argc=2, argv=0xbffffcf4) at main.c:189 >could be a bug in the implementation of pthreads (not sure how to check which >version I have of this) Can you run slapd with some debugging turned on and provide the relevant entries? Probably -d 1 would be enough... Thanks, Kurt
Alan Knowles wrote: > > I'm not sure this is that helpful:), but the last line does show > send_ldap_result 0:àø : > Segmentation fault > > Note the strange output characters > > heres the rest, best regards, > > Alan > > using base o=ossc,c=HK > base_candidates: base: o=ossc,c=HK > dn2entry_r: dn: o=ossc,c=HK > => dn2id( "o=ossc,c=HK" ) > => ldbm_cache_open( "/usr/tmp/dn2id.dbb", 66, 600 ) > <= ldbm_cache_open (cache 3) > <= dn2id 910 > => id2entry_r( 910 ) > ====> cache_find_entry_dn2id: found id: 910 rw: 0 > <= id2entry_r 0x808a738 (cache) > ====> cache_return_entry_r > => id2entry_r( 910 ) > ====> cache_find_entry_dn2id: found id: 910 rw: 0 > <= id2entry_r 0x808a738 (cache) > => send_search_entry (o=ossc, c=HK) > <= send_search_entry > ====> cache_return_entry_r > send_ldap_result 0:: > do_search > using base > subtree_candidates: base: > => filter_candidates > => list_candidates 0xa1 > => filter_candidates > => ava_candidates 0xa3 > => index_read( "objectclass" "=" "REFERRAL" ) > => ldbm_cache_open( "/usr/tmp/objectclass.dbb", 66, 600 ) > <= ldbm_cache_open (cache 0) > <= index_read 0 candidates > <= ava_candidates 0 > <= filter_candidates 0 > => filter_candidates > => ava_candidates 0xa3 > => index_read( "member" "=" "O=OSSC, C=HK" ) > => ldbm_cache_open( "/usr/tmp/member.dbb", 66, 600 ) > <= ldbm_cache_open (opened 4) > <= index_read 0 candidates > <= ava_candidates 0 > <= filter_candidates 0 > <= list_candidates 0 > <= filter_candidates 0 > send_ldap_result 0:àø : > Segmentation fault > > Kurt@openldap.org wrote: > > > > I assume this is the same slapd crash you noted on stable > > when doing: > > > > Alan Knowles wrote: > > ># ldapsearch -b '' 'member=cn=julian knowles,o=ossc,c=hk' > > >will cause it to segfault. (with or without acls) > > > where as > > ># ldapsearch -b 'c=hk' 'member=cn=julian knowles,o=ossc,c=hk' > > >will work quite happily > > > > (if you were doing a different operation, please provide > > details). > > > > > > > At 02:53 AM 12/19/98 GMT, alan_k@HK.Super.NET wrote: > > >Full_Name: Alan Richard Knowles > > >Version: 1.1 Stable > > >OS: Linux (Debian 2.0) > > >URL: ftp://ftp.openldap.org/incoming/ > > >Submission from: (NULL) (202.64.34.22) > > > > > > > > >Seg faults on base searching, (intermitant) > > >gbd > > >info stack > > >#0 0x400dcb04 in __syscall_sigsuspend () > > >#1 0x401010ec in svc_fdset () > > >#2 0x4006159d in pthread_create () > > >#3 0x8049cd5 in main (argc=2, argv=0xbffffcf4) at main.c:189 > > >could be a bug in the implementation of pthreads (not sure how to check which > > >version I have of this) > > > > Can you run slapd with some debugging turned on and provide > > the relevant entries? Probably -d 1 would be enough... > > > > Thanks, Kurt > > -- > ------------------// Alan's Signature //-------------------- > If the answers not at http://www.hk.super.net/~alan_k , then > let me now, CAUSE IT'S SUPPOSED TO BE! > -----------// Alan's Linux Infomation Center //-------------
Alan Knowles wrote: > > Yeah, All the same, > > I'm still playing with it - eg. > have tried > --without-threads, > it will bug out somewhere in the ber library > CPPFLAGS with MIT (and installed the debian MIT threads) > this doesnt help - seems to produce the same errors. > I will try setting my db to gdbm to see if that makes a difference. If it segfaulting --without-threads, then provide (in a reply to the its to the openldap-its@openldap.org) a new traceback. Debugging in single threaded applications is much easier. Make sure you remove config.cache before rerunning configure with new options and then do a make clean; make depend before making. > I'm not sure the debug I gave was that usefull. - I'm pretty fresh to > xxgdb so my guesses where that the thread call is failing (does this > mean that the program/functions etc. running in the thread, not the > thread controller is failing) so do I need to work out how to monitor > the other thread? Let's look at the --without-thread crash first. > Anyway I'll keep plugging away, if you want me to try some other stuff > to send u info, let me know > > best regards > > alan > > "Kurt D. Zeilenga" wrote: > > > > I assume this is the same slapd crash you noted on stable > > when doing: > > > > Alan Knowles wrote: > > ># ldapsearch -b '' 'member=cn=julian knowles,o=ossc,c=hk' > > >will cause it to segfault. (with or without acls) > > > where as > > ># ldapsearch -b 'c=hk' 'member=cn=julian knowles,o=ossc,c=hk' > > >will work quite happily > > > > (if you were doing a different operation, please provide > > details). > > > > > > > At 02:53 AM 12/19/98 GMT, alan_k@HK.Super.NET wrote: > > >Full_Name: Alan Richard Knowles > > >Version: 1.1 Stable > > >OS: Linux (Debian 2.0) > > >URL: ftp://ftp.openldap.org/incoming/ > > >Submission from: (NULL) (202.64.34.22) > > > > > > > > >Seg faults on base searching, (intermitant) > > >gbd > > >info stack > > >#0 0x400dcb04 in __syscall_sigsuspend () > > >#1 0x401010ec in svc_fdset () > > >#2 0x4006159d in pthread_create () > > >#3 0x8049cd5 in main (argc=2, argv=0xbffffcf4) at main.c:189 > > >could be a bug in the implementation of pthreads (not sure how to check which > > >version I have of this) > > > > Can you run slapd with some debugging turned on and provide > > the relevant entries? Probably -d 1 would be enough... > > > > Thanks, Kurt > > -- > ------------------// Alan's Signature //-------------------- > If the answers not at http://www.hk.super.net/~alan_k , then > let me now, CAUSE IT'S SUPPOSED TO BE! > -----------// Alan's Linux Infomation Center //-------------
changed notes changed state Open to Feedback
Right, Replying to the 'its' address this time :) This is the backtrace after compliling with --without-threads - from my reading of the code though, even though it is not a threaded application, it emulates the calls (not sure if that at all relivant, but at least I tried :-) end of -d1 output, then info stack I've got some more probs with select gdbm database - I'll post that as a seperate issue to 'its' regards alan <= filter_candidates 0 => filter_candidates => ava_candidates 0xa3 => index_read( "member" "=" "CN=PERSON ALAN KNOWLES, O=ENVISION INTEGRATED DESIGN CONSULTANCY, OU=CONTACTS, O=OSSC, C=HK" ) => ldbm_cache_open( "/usr/tmp/member.dbb", 66, 600 ) <= ldbm_cache_open (opened 4) <= index_read 0 candidates <= ava_candidates 0 <= filter_candidates 0 <= list_candidates 0 <= filter_candidates 0 send_ldap_result 0:H: Program received signal SIGSEGV, Segmentation fault. 0x4009acc8 in free () (xxgdb) info stack #0 0x4009acc8 in free () #1 0x4009ac71 in free () #2 0x80586d2 in ber_free (ber=0x400efe80, freebuf=1) at io.c:262 #3 0x8050175 in op_free (op=0x806fc88) at operation.c:17 #4 0x80502ab in op_delete (olist=0x8070178, op=0x806fc88) at operation.c:74 #5 0x804af29 in connection_operation (arg_v=0x8084420) at connection.c:92 #6 0x80616bc in pthread_create (tid=0x806fcb4, attr=0xbffffa24, func=0x804aca0 <connection_operation>, arg=0x8084420) at thread.c:522 #7 0x804b247 in connection_activity (conn=0x8070114) at connection.c:201 #8 0x804aad4 in slapd_daemon (port=0x185) at daemon.c:362 #9 0x80616bc in pthread_create (tid=0x806c7a0, attr=0xbffffcd0, func=0x8049e20 <slapd_daemon>, arg=0x185) at thread.c:522
Update on investigation. I tried greg's rpms (www.rage.net), and passed the through alien. = these seem to have the same problem, I couldn't xxgdb them as It couldnt find the symbols. However, After alot of experimentation this is a definitive situation for it to segfault. create a database, with index on an item, eg. member index member (in slapd.conf) do ldapsearch -b '' 'member=some_silly_address_that_will_fail' it will only segfault if there are no matches, '', and it has an index file. basically, the temporary work round is to remove all indexes and increase the cache to compensate. regards alan -- ------------------// Alan's Signature //-------------------- If the answers not at http://www.hk.super.net/~alan_k , then let me now, CAUSE IT'S SUPPOSED TO BE! -----------// Alan's Linux Infomation Center //-------------
changed notes changed state Feedback to Open moved from Incoming to Software
changed notes
Alan, I suspect the problem may be the same as reported in ITS#12 which was fixed. This problem occurred regardless of whether slapd was built with threads or not. I've tried to duplicate the problem your reported using: % gdb ../servers/slapd/slapd (gdb) run -p 9009 -d 1 data/slapd-master.conf and (in a separate login session): % ldapsearch -L -h localhost -p 9009 -b 'o=University of Michigan,c=US' "member=cn=Manager,o=University of Michigan,c=US" dn: cn=lsloan-test, ou=User Groups, ou=Groups, o=University of Michigan, c=US [returned attributes snipped] % ldapsearch -L -h localhost -p 9009 -b '' "member=cn=Manager,o=University of Michigan,c=US" ldap_search: DSA is unwilling to perform I repeated the tests with and without threads with same results. If you can test the -rOPENLDAP_REL_ENG_1_1 (as currently available via AnonCVS) or apply the patch noted in #ITS 12 and test? If possible, can you duplicate using the one of the test directories? Thanks, Kurt
Please try applying: http://www.OpenLDAP.org/devel/cvsweb.cgi/servers/slapd/back-ldbm/search.c.diff?r1=1.7.2.6&r2=1.7.2.7
Unfortunaly no, I did however try the test data to see if I could get that to cause the same effects. using test.ldif and slapd-master.conf If I change the suffix to "" rather that "o=....." this seems to be the key problem.... I also added this (but I think it is just the suffix that causes it problems!) index master and ldif2ldbm ........ then start slapd and search ldapsearch -b '' 'member=*' segfaults every time.. Kurt Zeilenga wrote: > > Please try applying: > > http://www.OpenLDAP.org/devel/cvsweb.cgi/servers/slapd/back-ldbm/search.c.diff?r1=1.7.2.6&r2=1.7.2.7 -- ------------------// Alan's Signature //-------------------- If the answers not at http://www.hk.super.net/~alan_k , then let me now, CAUSE IT'S SUPPOSED TO BE! -----------// Alan's Linux Infomation Center //-------------
As far as I can tell, this has been fixed with 1.1.1, however I am now getting the Base "" segfault as reported in ITS#23 - will post additional info to ITS23 ??? best regards alan
changed notes changed state Feedback to Closed
moved from Software to Software Bugs
Investigation underway. Is independent of threading. Have not been able to duplicate. Believed to be same as ITS#12.