openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#5169) Test0001 - segmentation fault - slapd
by quanah＠zimbra.com 05 Oct '07

05 Oct '07

--On Friday, October 05, 2007 9:03 AM +0000 andy.n.parker(a)unilever.com wrote: > Full_Name: Andrew N Parker > Version: 2.3.38 > OS: RHEL 4.2 32 bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.60.106.5) OpenLDAP 2.3.38 does not support BDB 4.6. Use a supported BDB release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5170) Issue with mirrormode: endless loop when multiple add/delete
by hyc＠symas.com 05 Oct '07

05 Oct '07

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.175.154.35) > Submitted by: ando > > > There was an issue with mirror mode, which caused an endless replication loop > when repeated, very close add/delete of the same object, like those performed by > the slapd-addel tester tool, were performed in a multimaster environment using > refreahAndPersist. > > Howard fixed this by letting syncrepl_entry() propagate the replication cookie, > if available, so that modifications don't get sent back to the SID that > generated them (please correct me if I got it wrong). The same issue is > probably affecting cascaded syncrepl, but not delta-syncrepl. Right, refreshAndPersist in a cascaded syncrepl would also be affected by the patch, although so far there's no indication that this caused any actual problems. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5170) Issue with mirrormode: endless loop when multiple add/delete
by ando＠sys-net.it 05 Oct '07

05 Oct '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando There was an issue with mirror mode, which caused an endless replication loop when repeated, very close add/delete of the same object, like those performed by the slapd-addel tester tool, were performed in a multimaster environment using refreahAndPersist. Howard fixed this by letting syncrepl_entry() propagate the replication cookie, if available, so that modifications don't get sent back to the SID that generated them (please correct me if I got it wrong). The same issue is probably affecting cascaded syncrepl, but not delta-syncrepl. p.

1 0

Re: ITS#5072 incorrect certificateExactAssertion()
by ando＠sys-net.it 05 Oct '07

05 Oct '07

hyc(a)symas.com wrote: > Except that from ITS#5070 we always use hex for serial numbers now, so this > would actually be > { > serialNumber '03'H, > issuer rdnSequence:"email=ca(a)example.com,cn=example ca,o=example,st=xx, > c=us" > } works for me... thanks. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: ITS#5072 incorrect certificateExactAssertion()
by hyc＠symas.com 05 Oct '07

05 Oct '07

Howard Chu wrote: > I.e., the sequence should be enclosed in double quotes. So your example should be > > { > serialNumber 3, > issuer rdnSequence:"email=ca(a)example.com,cn=example ca,o=example,st=xx, > c=us" > } Except that from ITS#5070 we always use hex for serial numbers now, so this would actually be { serialNumber '03'H, issuer rdnSequence:"email=ca(a)example.com,cn=example ca,o=example,st=xx, c=us" } -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5169) Test0001 - segmentation fault - slapd
by andy.n.parker＠unilever.com 05 Oct '07

05 Oct '07

Full_Name: Andrew N Parker Version: 2.3.38 OS: RHEL 4.2 32 bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.60.106.5) Running the standard installtion script; make test. tes001-slapadd fails with a segmentation fault from slapd. Compiled with OpenSSl 0.9.8e & BerkeleyDB 4.6.19. O/S RHEL 4.2, hardware Intel (arch command gives string i686). The same software combination seems to work on RHEL 4.2 64 bit. Here is the stack trace: <<< dnPrettyNormal: <cn=Start,cn=Time,cn=Monitor>, <cn=start,cn=time,cn=monitor> >>> dnNormalize: <> <<< dnNormalize: <> >>> dnNormalize: <> <<< dnNormalize: <> <= str2entry(cn=Start,cn=Time,cn=Monitor) -> 0x97dc658 => str2entry: "dn: cn=Current,cn=Time,cn=Monitor objectClass: monitoredObject structuralObjectClass: monitoredObject cn: Current monitorTimestamp: 20071004185030Z creatorsName: modifiersName: createTimestamp: 20071004185030Z modifyTimestamp: 20071004185030Z " >>> dnPrettyNormal: <cn=Current,cn=Time,cn=Monitor> <<< dnPrettyNormal: <cn=Current,cn=Time,cn=Monitor>, <cn=current,cn=time,cn=monitor> >>> dnNormalize: <> <<< dnNormalize: <> >>> dnNormalize: <> <<< dnNormalize: <> <= str2entry(cn=Current,cn=Time,cn=Monitor) -> 0x97dca60 => str2entry: "dn: cn=Read,cn=Waiters,cn=Monitor objectClass: monitorCounterObject structuralObjectClass: monitorCounterObject cn: Read creatorsName: modifiersName: createTimestamp: 20071004185030Z modifyTimestamp: 20071004185030Z " >>> dnPrettyNormal: <cn=Read,cn=Waiters,cn=Monitor> <<< dnPrettyNormal: <cn=Read,cn=Waiters,cn=Monitor>, <cn=read,cn=waiters,cn=monitor> >>> dnNormalize: <> <<< dnNormalize: <> >>> dnNormalize: <> <<< dnNormalize: <> <= str2entry(cn=Read,cn=Waiters,cn=Monitor) -> 0x97dce70 => str2entry: "dn: cn=Write,cn=Waiters,cn=Monitor objectClass: monitorCounterObject structuralObjectClass: monitorCounterObject cn: Write creatorsName: modifiersName: createTimestamp: 20071004185030Z modifyTimestamp: 20071004185030Z " >>> dnPrettyNormal: <cn=Write,cn=Waiters,cn=Monitor> <<< dnPrettyNormal: <cn=Write,cn=Waiters,cn=Monitor>, <cn=write,cn=waiters,cn=monitor> >>> dnNormalize: <> <<< dnNormalize: <> >>> dnNormalize: <> <<< dnNormalize: <> <= str2entry(cn=Write,cn=Waiters,cn=Monitor) -> 0x97dd580 slapd starting [New Thread 26901424 (LWP 9269)] >>> slap_listener(ldap://localhost:9011) connection_get(14): got connid=0 connection_read(14): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 12 contents: [New Thread 128756656 (LWP 9285)] ber_get_next do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 send_ldap_result: conn=0 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=0 ber_flush: 14 bytes to sd 14 do_bind: v3 anonymous bind connection_get(14): got connid=0 connection_read(14): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 54 contents: ber_get_next do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <dc=example,dc=com> <<< dnPrettyNormal: <dc=example,dc=com>, <dc=example,dc=com> ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: ==> limits_get: conn=0 op=1 dn="[anonymous]" => bdb_search bdb_dn2entry("dc=example,dc=com") => bdb_dn2id("dc=example,dc=com") <= bdb_dn2id: got id=0x00000001 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 128756656 (LWP 9285)] 0x006fb87c in __lock_get_internal () from /usr/local/berkeleydb4619/lib/libdb-4.6.so (gdb) bt full #0 0x006fb87c in __lock_get_internal () from /usr/local/berkeleydb4619/lib/libdb-4.6.so No symbol table info available. #1 0x006fc6eb in __lock_get () from /usr/local/berkeleydb4619/lib/libdb-4.6.so No symbol table info available. #2 0x00731ea9 in __db_lget () from /usr/local/berkeleydb4619/lib/libdb-4.6.so No symbol table info available. #3 0x006a6316 in __bam_get_root () from /usr/local/berkeleydb4619/lib/libdb-4.6.so No symbol table info available. #4 0x006a6633 in __bam_search () from /usr/local/berkeleydb4619/lib/libdb-4.6.so No symbol table info available. #5 0x00698d70 in __bamc_search () from /usr/local/berkeleydb4619/lib/libdb-4.6.so No symbol table info available. #6 0x00699f3c in __bamc_get () from /usr/local/berkeleydb4619/lib/libdb-4.6.so No symbol table info available. #7 0x007244b4 in __dbc_get () from /usr/local/berkeleydb4619/lib/libdb-4.6.so No symbol table info available. #8 0x0072efb2 in __dbc_get_pp () from /usr/local/berkeleydb4619/lib/libdb-4.6.so No symbol table info available. #9 0x080de047 in bdb_id2entry (be=0x69, tid=0x0, locker=26, id=1, e=0x7a08e1c) at id2entry.c:125 bdb = (struct bdb_info *) 0x97780c0 db = (DB *) 0x97c9ce8 key = {data = 0x7a08d7c, size = 4, ulen = 0, dlen = 0, doff = 0, ---Type <return> to continue, or q <return> to quit--- app_data = 0x0, flags = 4} data = {data = 0x0, size = 0, ulen = 0, dlen = 0, doff = 0, app_data = 0x0, flags = 8} cursor = (DBC *) 0x97cae48 bv = {bv_len = 0, bv_val = 0x182 <Address 0x182 out of bounds>} rc = 0 nid = 16777216 #10 0x080d7d39 in bdb_cache_find_id (op=0x97ded30, tid=0x0, id=1, eip=0x7a08ea8, islocked=0, locker=26, lock=0x7a09080) at cache.c:760 bdb = (struct bdb_info *) 0x97780c0 ep = (Entry *) 0x0 rc = 0 load = 1 ei = {bei_parent = 0x0, bei_id = 1, bei_lockpad = 0 '\0', bei_state = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0} #11 0x080db009 in bdb_dn2entry (op=0x97ded30, tid=0x0, dn=0x97ded4c, e=0x7a08fc8, matched=1, locker=26, lock=0x7a09080) at dn2entry.c:68 ei = (EntryInfo *) 0x97defc0 rc = 0 rc2 = Variable "rc2" is not available. (gdb) thread apply all bt Thread 3 (Thread 128756656 (LWP 9285)): #0 0x006fb87c in __lock_get_internal () from /usr/local/berkeleydb4619/lib/libdb-4.6.so #1 0x006fc6eb in __lock_get () from /usr/local/berkeleydb4619/lib/libdb-4.6.so #2 0x00731ea9 in __db_lget () from /usr/local/berkeleydb4619/lib/libdb-4.6.so #3 0x006a6316 in __bam_get_root () from /usr/local/berkeleydb4619/lib/libdb-4.6.so #4 0x006a6633 in __bam_search () from /usr/local/berkeleydb4619/lib/libdb-4.6.so #5 0x00698d70 in __bamc_search () from /usr/local/berkeleydb4619/lib/libdb-4.6.so #6 0x00699f3c in __bamc_get () from /usr/local/berkeleydb4619/lib/libdb-4.6.so #7 0x007244b4 in __dbc_get () from /usr/local/berkeleydb4619/lib/libdb-4.6.so #8 0x0072efb2 in __dbc_get_pp () from /usr/local/berkeleydb4619/lib/libdb-4.6.so #9 0x080de047 in bdb_id2entry (be=0x69, tid=0x0, locker=26, id=1, e=0x7a08e1c) at id2entry.c:125 #10 0x080d7d39 in bdb_cache_find_id (op=0x97ded30, tid=0x0, id=1, eip=0x7a08ea8, islocked=0, locker=26, lock=0x7a09080) at cache.c:760 #11 0x080db009 in bdb_dn2entry (op=0x97ded30, tid=0x0, dn=0x97ded4c, e=0x7a08fc8, matched=1, locker=26, lock=0x7a09080) at dn2entry.c:68 #12 0x080c6439 in bdb_search (op=0x97ded30, rs=0x7aca220) at search.c:374 #13 0x0806fc6a in fe_op_search (op=0x97ded30, rs=0x7aca220) at search.c:355 #14 0x0806f569 in do_search (op=0x97ded30, rs=0x7aca220) at search.c:217 #15 0x0806e058 in connection_operation (ctx=0x7aca2b0, arg_v=0x97ded30) at connection.c:1133 #16 0x00f787fb in ldap_int_thread_pool_wrapper (xpool=0x9752020) ---Type <return> to continue, or q <return> to quit--- at tpool.c:478 #17 0x00ae9341 in start_thread () from /lib/tls/libpthread.so.0 #18 0x00a546fe in clone () from /lib/tls/libc.so.6 Thread 2 (Thread 26901424 (LWP 9269)): #0 0x009747a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00a54d7e in epoll_wait () from /lib/tls/libc.so.6 #2 0x0806a5a7 in slapd_daemon_task (ptr=0x0) at daemon.c:2174 #3 0x00ae9341 in start_thread () from /lib/tls/libpthread.so.0 #4 0x00a546fe in clone () from /lib/tls/libc.so.6 Thread 1 (Thread -1208018720 (LWP 9266)): #0 0x009747a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00aea06d in pthread_join () from /lib/tls/libpthread.so.0 #2 0x00f79202 in ldap_pvt_thread_join (thread=26901424, thread_return=0x0) at thr_posix.c:193 #3 0x0806bb45 in slapd_daemon () at daemon.c:2579 #4 0x0805ccb7 in main (argc=8, argv=0xbfeff084) at main.c:859 Here is the output from the test run (I had to modify it slightly to get the gdb output): description: This object contains information about this server. description: Most of the information is held in operational attributes, which must be explicitly requested. creatorsName: modifiersName: createTimestamp: 20071004182607Z modifyTimestamp: 20071004182607Z monitoredInfo: OpenLDAP: slapd 2.3.38 (Oct 4 2007 17:10:33) entryDN: cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: TRUE >>>>> Test succeeded >>>>> ./scripts/test000-rootdse completed OK. >>>>> waiting 10 seconds for things to exit >>>>> Starting test001-slapadd ... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... ../servers/slapd/slapd -s0 -f ./testrun/slapd.1.conf -h ldap://localhost:9011/ -d 1 (The above line is an echo of the script line) (read statement in here) (Now I start gdb etc and run your slapd in the tests area). Using ldapsearch to retrieve all the entries... /tmp/openldap-2.3.38/tests ../clients/tools/ldapsearch -P 3 -x -LLL ./testrun/ldapsearch.out Now I obtain the failure in gdb. I can repeat this. Here is my build script: export CPPFLAGS="-I/usr/local/openssl098e/include -I/usr/kerberos/include -I/usr/local/berkeleydb4619/include" export LDFLAGS="-L/usr/lib -L/lib -L/lib/tls -L/usr/local/openssl098e/lib -L/usr/local/berkeleydb4619/lib" export LD_LIBRARY_PATH="/usr/local/berkeleydb4619/lib;/usr/local/openssl098e/lib" StdMsg -i "OpenLDAP - Running configure: CPPFLAGS=${CPPFLAGS}." StdMsg -i "OpenLDAP - Running configure: LDFLAGS=${LDFLAGS}." StdMsg -i "OpenLDAP - Running configure: LD_LIBRARY_PATH=${LD_LIBRARY_PATH}." ./configure \ --x-includes=/usr/include \ --x-includes=/usr/include/openssl/ssl \ --x-includes=/usr/include/openssl \ --x-libraries=/usr/lib \ --x-libraries=/lib \ --x-libraries=/lib/tls \ --prefix=${TARGET} \ --enable-debug \ --enable-dynamic \ --enable-syslog \ --enable-proctitle \ --enable-ipv6 \ --enable-local \ --with-cyrus-sasl \ --with-threads \ --with-tls \ --with-yielding-select \ --enable-overlays \ --enable-slapd \ --enable-slapi \ --enable-cleartext \ --enable-crypt \ --enable-spasswd \ --enable-lmpasswd \ --enable-aci \ --enable-modules \ --enable-rewrite \ --enable-rlookups \ --enable-wrappers \ --enable-bdb \ --enable-dnssrv=mod \ --enable-ldap \ --enable-passwd=mod \ --enable-perl=mod \ --enable-shell=mod \ --enable-dyngroup \ --enable-proxycache \ --enable-slurpd \ --enable-hdb=mod \ --enable-ldbm=mod \ --enable-ldbm-api=auto \ --enable-ldbm-type=auto \ --enable-meta=mod \ --enable-null=mod \ --enable-static \ --enable-shared | \ tee -a $Log_File If you need more info, just ask. Andrew N Parker

1 0

Re: ITS#5072 incorrect certificateExactAssertion()
by hyc＠symas.com 05 Oct '07

05 Oct '07

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> Yes, it looks like we're using an invalid format for the issuer component. >> Seems like using the GSER format is a bit harder to parse, since we have no >> reliable indicator of where the rdnSequence ends. Any thoughts? > > In general, I agree. In this specific case, it ends at the end of the > octetString :) I take that back. Section 3.20 of RFC3641 says >>> 3.20. Variant Encodings The values of some named complex ASN.1 types have special string encodings. These special encodings are always used instead of the encoding that would otherwise apply based on the ASN.1 type definition. VariantEncoding = RDNSequenceValue / RelativeDistinguishedNameValue / ORAddressValue A value of the RDNSequence type, i.e., a distinguished name, is encoded according to the <RDNSequenceValue> rule, as a quoted LDAPDN character string. The character string is first derived according to the <distinguishedName> rule in Section 3 of RFC 2253 [5], and then encoded as if it were a UTF8String value, i.e., between double quotes with any embedded double quotes escaped by being repeated. <<< I.e., the sequence should be enclosed in double quotes. So your example should be { serialNumber 3, issuer rdnSequence:"email=ca(a)example.com,cn=example ca,o=example,st=xx, c=us" } -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ITS#5072 incorrect certificateExactAssertion()
by ando＠sys-net.it 05 Oct '07

05 Oct '07

hyc(a)symas.com wrote: > Yes, it looks like we're using an invalid format for the issuer component. > Seems like using the GSER format is a bit harder to parse, since we have no > reliable indicator of where the rdnSequence ends. Any thoughts? In general, I agree. In this specific case, it ends at the end of the octetString :) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

ITS#5072 incorrect certificateExactAssertion()
by hyc＠symas.com 05 Oct '07

05 Oct '07

Yes, it looks like we're using an invalid format for the issuer component. Seems like using the GSER format is a bit harder to parse, since we have no reliable indicator of where the rdnSequence ends. Any thoughts? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5168) slapo-rwm(5) does not handle UUID syntax attrs in seach filters
by ando＠sys-net.it 04 Oct '07

04 Oct '07

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I found out that most of the issues I was seeing with syncrepl were a (nasty) side-effect of the fact that slapo-rwm does not play well with UUID-syntax attrs in search filters; unfortunately, syncrepl heavily exploits searching with equality filters on entryUUID... fixed. PS: sorry for the noise.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs