Description of problem: I'm getting a SEGFAULT with fedora-ds-1.1.0-3.fc6. The script below can reproduce this: How reproducible: #!/bin/bash FILTER="1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111" for a in $(seq 1 5); do ldapsearch -w xxxxxxx -h h.h.h.h -x -b "o=xxxxxxxx" -D "uid=zzzzzzzz,ou=yyyyyy,ou=wwwwwww,ou=vvvvvvv,o=tttttttt" "(&(|(objectClass=inetorgperson)(objectClass=posixaccount))(|(cn=*$FILTER*)(mail=*$FILTER*)(mozillasecondemail=*$FILTER*)))" uidNumber uid cn givenName sn audio description labeledUri o ou title street l st postalCode telephoneNumber homePhone facsimileTelephoneNumber mobile pager mail roomNumber jpegPhoto displayName postalAddress userSMIMECertificate mozillaworkstreet2 c mozillahomestreet mozillahomestreet2 mozillahomelocalityname mozillahomestate mozillahomepostalcode mozillahomecountryname mozillasecondemail mozillahomeurl mozillapostaladdress2 co mozillahomepostaladdress2 birthDate note carPhone primaryPhone category businessRole assistantPhone assistantName fileAs homeFacsimileTelephoneNumber freeBusyURI calendarURI otherPhone callbackPhone entryuuid uid uidNumber objectClass createTimestamp modifyTimestamp creatorsName modifiersName done; Steps to Reproduce: 1. 2. 3. Actual results: 6506 --- SIGSEGV (Segmentation fault) @ 0 (0) --- 6519 +++ killed by SIGSEGV +++ 6518 +++ killed by SIGSEGV +++ 6517 +++ killed by SIGSEGV +++ 6516 +++ killed by SIGSEGV +++ 6515 +++ killed by SIGSEGV +++ 6514 +++ killed by SIGSEGV +++ 6513 +++ killed by SIGSEGV +++ 6512 +++ killed by SIGSEGV +++ 6511 +++ killed by SIGSEGV +++ 6510 +++ killed by SIGSEGV +++
I am unable to reproduce this running fedora-ds-base-1.1.0-3.fc8 on a Fedora 8 x86_64 machine. I have a few questions that may help in being able to reproduce this issue: - Is this reproducible with a fresh database immediately after an install, or do you have to have data in your database? - In your script, are you using a base and bind DN that are both valid and exist? If you find that having data in your database is needed to trigger this issue, I would appreciate a test LDIF that you can reproduce the issue with.
I'm able to reproduce this issue now. It required an entry to be added that the filter would be checked against. Here's the entry I added: dn: uid=test,dc=example,dc=com uid: test cn: test user sn: user objectclass: inetorgperson objectclass: posixaccount homedirectory: /home/test uidNumber: 501 gidNumber:501 Here's the stack trace: (gdb) bt #0 0x00002aaaaab60b48 in vattr_map_lookup (type_to_find=0xa13a80 "mail", result=0x40407a48) at ../ldapserver/ldap/servers/slapd/vattr.c:1904 #1 0x00002aaaaab612fb in vattr_map_namespace_sp_getlist (dn=0x787ec0, type_to_find=0xa13a80 "mail") at ../ldapserver/ldap/servers/slapd/vattr.c:2193 #2 0x00002aaaaab5e72e in vattr_test_filter (pb=0x958700, e=0xa10970, f=0xa139f0, filter_type=FILTER_TYPE_SUBSTRING, type=0xa13a80 "mail") at ../ldapserver/ldap/servers/slapd/vattr.c:439 #3 0x00002aaaaab08416 in slapi_vattr_filter_test_ext_internal (pb=0x958700, e=0xa10970, f=0xa139f0, verify_access=0, only_check_access=0, access_check_done=0x40407da8) at ../ldapserver/ldap/servers/slapd/filterentry.c:877 #4 0x00002aaaaab08a4c in vattr_test_filter_list (pb=0x958700, e=0xa10970, flist=0xa19790, ftype=161, verify_access=0, only_check_access=0, access_check_done=0x40407da8) at ../ldapserver/ldap/servers/slapd/filterentry.c:1018 #5 0x00002aaaaab08805 in slapi_vattr_filter_test_ext_internal (pb=0x958700, e=0xa10970, f=0xa19700, verify_access=0, only_check_access=0, access_check_done=0x40407da8) at ../ldapserver/ldap/servers/slapd/filterentry.c:945 #6 0x00002aaaaab08a4c in vattr_test_filter_list (pb=0x958700, e=0xa10970, flist=0xa10500, ftype=160, verify_access=0, only_check_access=0, access_check_done=0x40407da8) at ../ldapserver/ldap/servers/slapd/filterentry.c:1018 #7 0x00002aaaaab0878e in slapi_vattr_filter_test_ext_internal (pb=0x958700, e=0xa10970, f=0x9591b0, verify_access=0, only_check_access=0, access_check_done=0x40407da8) at ../ldapserver/ldap/servers/slapd/filterentry.c:939 #8 0x00002aaaaab08188 in slapi_vattr_filter_test_ext (pb=0x958700, e=0xa10970, f=0x9591b0, verify_access=1, only_check_access=0) at ../ldapserver/ldap/servers/slapd/filterentry.c:807 #9 0x00002aaaaab08120 in slapi_vattr_filter_test (pb=0x958700, e=0xa10970, f=0x9591b0, verify_access=1) at ../ldapserver/ldap/servers/slapd/filterentry.c:770 #10 0x00002aaaae9eefd4 in ldbm_back_next_search_entry_ext (pb=0x958700, use_extension=0) at ../ldapserver/ldap/servers/slapd/back-ldbm/ldbm_search.c:1240 #11 0x00002aaaae9ee7ba in ldbm_back_next_search_entry (pb=0x958700) at ../ldapserver/ldap/servers/slapd/back-ldbm/ldbm_search.c:1011 #12 0x00002aaaaab2841c in iterate (pb=0x958700, be=0x7d9480, send_result=1, pnentries=0x4040a04c) at ../ldapserver/ldap/servers/slapd/opshared.c:966 #13 0x00002aaaaab287a9 in send_results (pb=0x958700, send_result=1, nentries=0x4040a04c) at ../ldapserver/ldap/servers/slapd/opshared.c:1184 #14 0x00002aaaaab27e2e in op_shared_search (pb=0x958700, send_result=1) at ../ldapserver/ldap/servers/slapd/opshared.c:595 #15 0x00000000004282ad in do_search (pb=0x958700) at ../ldapserver/ldap/servers/slapd/search.c:276 #16 0x0000000000411aa1 in connection_dispatch_operation (conn=0x2aaab0851410, op=0xa14250, pb=0x958700) at ../ldapserver/ldap/servers/slapd/connection.c:532 #17 0x0000000000413066 in connection_threadmain () at ../ldapserver/ldap/servers/slapd/connection.c:2163 #18 0x00000033a742780d in sasl_map_config_add () at ../ldapserver/ldap/servers/slapd/sasl_map.c:342 #19 0x0000003398806407 in start_thread () from /lib64/libpthread.so.0 #20 0x0000003397cd4b0d in clone () from /lib64/libc.so.6
Created attachment 304041 [details] stacktraces I could also duplicate the crash. Since the cause of the problem is the memory corruption, different test cases show different stack traces. But the patch proposed by Ulf in bug 182621 fixes all cases. I'm marking this bug as duplicate of bug 182621.
*** This bug has been marked as a duplicate of 182621 ***
Bug already CLOSED. setting screened+ flag