openldap-bugs

openldap-bugs@openldap.org

21001 discussions

Re: (ITS#5541) slapd segfaults with specific search on string bdb and hdb backend (closing, already solved)
by hyc＠symas.com 02 Jun '08

02 Jun '08

Piotr Wadas wrote: > It works as expected with CVS current OPENLDAP_REL_ENG_2_4 > version (didn't test -devel version), > Deep respect& many thanks for your amazing work with free ldap software - Thanks for the feedback, glad it's working for you. This ITS will be closed. > Piotr Wadas > > On Mon, 2 Jun 2008, Howard Chu wrote: > >> pwadas(a)jewish.org.pl wrote: >>> This message is in MIME format. The first part should be readable text, >>> while the remaining parts are likely unreadable without MIME-aware tools. >> Looks like you didn't have the correct frame selected before issuing those >> print commands. >> >> At any rate, I suspect this issue has already been fixed in the 2.4.10 release >> candidate. Please test with the 2.4 release in CVS. >> >>>> =20 >>>> Hello, >>>> Regarding http://www.openldap.org/its/index.cgi?findid=3D5541 >>>> =20 >>>> Link to indexes file and full schema, including custom schema >>>> is mailed to Howard Chu, as I'd like to avoid spreading it. >>>> It says there's no variable "ava" nor "mr", as below >>>> =20 >>>> I keep gdb on detached screen, so I additional variables >>>> need to be printed I have'em at hand. >>>> =20 >>>> ------------------------------- >>>> (gdb) print *ava->aa_desc >>>> No symbol "ava" in current context. >>>> (gdb) print *mr >>>> No symbol "mr" in current context. >>>> (gdb) print ava->aa_desc >>>> No symbol "ava" in current context. >>>> (gdb) print mr >>>> No symbol "mr" in current context. >> >> > -- -- Howard Chu CTO, 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#5541) slapd segfaults with specific search on string bdb and hdb backend (closing, already solved)
by pwadas＠jewish.org.pl 02 Jun '08

02 Jun '08

It works as expected with CVS current OPENLDAP_REL_ENG_2_4 version (didn't test -devel version), Deep respect & many thanks for your amazing work with free ldap software - Piotr Wadas On Mon, 2 Jun 2008, Howard Chu wrote: > pwadas(a)jewish.org.pl wrote: > > This message is in MIME format. The first part should be readable text, > > while the remaining parts are likely unreadable without MIME-aware tools. > > Looks like you didn't have the correct frame selected before issuing those > print commands. > > At any rate, I suspect this issue has already been fixed in the 2.4.10 release > candidate. Please test with the 2.4 release in CVS. > > > > =20 > > > Hello, > > > Regarding http://www.openldap.org/its/index.cgi?findid=3D5541 > > > =20 > > > Link to indexes file and full schema, including custom schema > > > is mailed to Howard Chu, as I'd like to avoid spreading it. > > > It says there's no variable "ava" nor "mr", as below > > > =20 > > > I keep gdb on detached screen, so I additional variables > > > need to be printed I have'em at hand. > > > =20 > > > ------------------------------- > > > (gdb) print *ava->aa_desc > > > No symbol "ava" in current context. > > > (gdb) print *mr > > > No symbol "mr" in current context. > > > (gdb) print ava->aa_desc > > > No symbol "ava" in current context. > > > (gdb) print mr > > > No symbol "mr" in current context. > > >

1 0

Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie
by rein＠OpenLDAP.org 02 Jun '08

02 Jun '08

On Mon, 2 Jun 2008, hyc(a)symas.com wrote: > Rein Tollevik wrote: > >> I see you have commited an alternative version to syncrepl.c. This >> version don't include the serverID in the cookie when syncrepl is used on >> the glue database itself, only when used on subordinate DBs. And >> unfortunately, it is when used on the glue database it is needed (at least >> in my configuration). > > Hm, can you show the configuration you're dealing with now? Is it still > similar to your test053 setup? (By the way, the test053 in HEAD works > with the current code. No, that test has a stripped down config used to trigger that bug. To show this problem the producer2 would have to syncrepl the basedn back from the first producer, and producer2 would need a subordinate database which it manages itself (the base DN for the syncrepl used by the first producer). I'm thinking about creating a new test script that tests more of my configuration. It seems as my config is a bit off the usual, as I have managed to hit a lot of bugs lately... And there are still a few open issues I would like solved before everything works as I wish, although I think all (or at least most) of my critical problems has been solved now. >> So, I still think we have to always include it when it is configured. > > Probably. But when I went down that route it seemed to require configuring it > in several cases that never needed it before, which is why I changed approach. It was my intention to avoid changes to existing configurations, and I do believe it wasn't needed with my approach. Although I think it would be preferrable (but not necessary) if we could forbid explicit usage of serverID=0. That would require a config change for those that used it. But a change to another unused ID should be sufficient, i.e no changes to existing databases. >> Unless there exist some easy way to know that a subordinate DB is not >> managed by syncrepl. The only solution I know to that is to loop through >> all the subordinate DBs and compare the rootdn values. > > We can think about this some more but I'd like to get 2.4.10 out now. A final > resolution of this issue may have to wait for 2.4.11. That should be OK, this bug isn't critical as it is possible to configure around it. Rein

1 0

Re: (ITS#5541) slapd segfaults with specific search on string bdb and hdb backend
by hyc＠symas.com 02 Jun '08

02 Jun '08

pwadas(a)jewish.org.pl wrote: > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. Looks like you didn't have the correct frame selected before issuing those print commands. At any rate, I suspect this issue has already been fixed in the 2.4.10 release candidate. Please test with the 2.4 release in CVS. >> =20 >> Hello, >> Regarding http://www.openldap.org/its/index.cgi?findid=3D5541 >> =20 >> Link to indexes file and full schema, including custom schema >> is mailed to Howard Chu, as I'd like to avoid spreading it. >> It says there's no variable "ava" nor "mr", as below >> =20 >> I keep gdb on detached screen, so I additional variables >> need to be printed I have'em at hand. >> =20 >> ------------------------------- >> (gdb) print *ava->aa_desc >> No symbol "ava" in current context. >> (gdb) print *mr >> No symbol "mr" in current context. >> (gdb) print ava->aa_desc >> No symbol "ava" in current context. >> (gdb) print mr >> No symbol "mr" in current context. -- -- Howard Chu CTO, 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#5541) slapd segfaults with specific search on string bdb and hdb backend
by pwadas＠jewish.org.pl 02 Jun '08

02 Jun '08

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589865158-1366188462-1212434906=:9248 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <Pine.LNX.4.64.0806022128461.9248(a)kehillah.jewish.org.pl> Hello, Forwarding as requested, sorry for mislead. Regards, PW. ---------- Forwarded message ---------- Date: Mon, 02 Jun 2008 10:33:14 -0700 From: Quanah Gibson-Mount <quanah(a)zimbra.com> To: Piotr Wadas <pwadas(a)jewish.org.pl>, openldap-software(a)openldap.org Subject: Re: slapd 2.4.7-2.4.9 segfaults with some specific search Information for your ITS should be sent to the ITS address with the bug num= ber in the subject, as the email you were sent after filing the ITS instructed,= and not to openldap-software. Thanks. --Quanah --On May 31, 2008 8:11:46 AM +0200 Piotr Wadas <pwadas(a)jewish.org.pl> wrote= : >=20 > Hello, > Regarding http://www.openldap.org/its/index.cgi?findid=3D5541 >=20 > Link to indexes file and full schema, including custom schema > is mailed to Howard Chu, as I'd like to avoid spreading it. > It says there's no variable "ava" nor "mr", as below >=20 > I keep gdb on detached screen, so I additional variables > need to be printed I have'em at hand. >=20 > ------------------------------- > (gdb) print *ava->aa_desc > No symbol "ava" in current context. > (gdb) print *mr > No symbol "mr" in current context. > (gdb) print ava->aa_desc > No symbol "ava" in current context. > (gdb) print mr > No symbol "mr" in current context. > (gdb) info variables ava > All variables matching regular expression "ava": >=20 > Non-debugging symbols: > 0xb7cc61ac __set_robust_list_avail > 0xb7cc61ac __set_robust_list_avail > 0xb7c8d10e not_available > 0xb7f75da0 available_ciphers > (gdb) info variables mr > All variables matching regular expression "mr": > ---------------- >=20 > But I found this may be also relevant: >=20 > frame 3: >=20 > (gdb) frame 3 > # 3 0xb7f18235 in ber_bvarray_free_x (a=3D0xa976b354, ctx=3D0x8279658) a= t > /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory. > c:731 731 ber_memfree_x(a[i].bv_val, ctx); > (gdb) info args > a =3D (BerVarray) 0xa976b354 > ctx =3D (void *) 0x8279658 > (gdb) print *a > $30 =3D {bv_len =3D 4, bv_val =3D 0xa976b36c "\200"} > (gdb) print *a->bv_val > $31 =3D -128 '\200' >=20 > frame 4 >=20 >=20 > $44 =3D > { > o_hdr =3D 0x82793b8, o_tag =3D 99, o_time =3D 1212212344, o_tincr =3D 1= , o_bd =3D > 0xa9c6af80, o_req_dn =3D > { > bv_len =3D 29, bv_val =3D 0xa976b154 "dc=3Ddns,dc=3Dnameservers,dc=3Dco= m,dc=3Deu"} > , o_req_ndn =3D > { > bv_len =3D 29, bv_val =3D 0xa976b1a4 "dc=3Ddns,dc=3Dnameservers,dc=3Dco= m,dc=3Deu"} > , o_request =3D > { > oq_add =3D > { > rs_modlist =3D 0x2, rs_e =3D 0x0} > , oq_bind =3D > { > rb_method =3D 2, rb_cred =3D > { > bv_len =3D 0, bv_val =3D 0xffffffff < Address 0xffffffff out of bou= nds > >} , rb_edn =3D > { > bv_len =3D 4294967295, bv_val =3D 0x0} > , rb_ssf =3D 0, rb_mech =3D > { > bv_len =3D 0, bv_val =3D 0xa976b2bc "=A0"} > } > , oq_compare =3D > { > rs_ava =3D 0x2} > , oq_modify =3D > { > rs_mods =3D > { > rs_modlist =3D 0x2, rs_no_opattrs =3D 0 '\0'} > , rs_increment =3D -1} > , oq_modrdn =3D > { > rs_mods =3D > { > rs_modlist =3D 0x2, rs_no_opattrs =3D 0 '\0'} > , rs_deleteoldrdn =3D -1, rs_newrdn =3D > { > bv_len =3D 4294967295, bv_val =3D 0x0} > , rs_nnewrdn =3D > { > bv_len =3D 0, bv_val =3D 0x0} > , rs_newSup =3D 0xa976b2bc, rs_nnewSup =3D 0x79} > , oq_search =3D > { > rs_scope =3D 2, rs_deref =3D 0, rs_slimit =3D -1, rs_tlimit =3D > =09-1, rs_limit =3D 0x0, rs_attrsonly =3D 0, rs_attrs =3D > =090x0, rs_filter =3D 0xa976b2bc, rs_filterstr =3D > { > bv_len =3D 121, bv_val =3D > =09 0xa976b2cc >=20 > "(&(objectClass=3DdNSDomain)(associatedDomain=3D*fakedomain.com)(customer= ID=3D1 > 0125)(sOARecord=3D*)(nSRecord=3D*)(topLevelDomain=3DTRUE))"} } > , oq_abandon =3D > { > rs_msgid =3D 2} > , oq_cancel =3D > { > rs_msgid =3D 2} > , oq_extended =3D > { > rs_reqoid =3D > { > bv_len =3D 2, bv_val =3D 0x0} > , rs_flags =3D -1, rs_reqdata =3D 0xffffffff} > , oq_pwdexop =3D > { > rs_extended =3D > { > =09rs_reqoid =3D > =09{ > =09bv_len =3D 2, bv_val =3D 0x0} > , rs_flags =3D -1, rs_reqdata =3D 0xffffffff} > , rs_old =3D > { > bv_len =3D 0, bv_val =3D 0x0} > , rs_new =3D > { > bv_len =3D 0, bv_val =3D 0xa976b2bc "=A0"} > , rs_mods =3D 0x79, rs_modtail =3D 0xa976b2cc} > } > , o_abandon =3D 0, o_cancel =3D 0, o_groups =3D 0x0, > o_do_not_cache =3D 0 '\0', o_is_auth_check =3D 0 '\0', o_acl_priv =3D > ACL_NONE, o_nocaching =3D 0 '\0', o_delete_glue_parent =3D > 0 '\0', o_no_schema_check =3D 0 '\0', o_no_subordinate_glue =3D > 0 '\0', o_ctrlflag =3D '\0' < repeats 31 times >, o_controls =3D > 0x82794e4, o_authz =3D > { > sai_method =3D 128, sai_mech =3D > { > bv_len =3D 0, bv_val =3D 0x0} > , sai_dn =3D > { > bv_len =3D 28, bv_val =3D 0x8279b70 "cn=3DDirectory Manager,dc=3Dcom,= dc=3Deu"} > , sai_ndn =3D > { > bv_len =3D 28, bv_val =3D 0x8279b98 "cn=3Ddirectory manager,dc=3Dcom,= dc=3Deu"} > , sai_ssf =3D 0, sai_transport_ssf =3D 0, sai_tls_ssf =3D 0, sai_sasl_s= sf =3D 0} > , o_ber =3D 0x8264b98, o_res_ber =3D 0x0, o_callback =3D > 0xa9c6b07c, o_ctrls =3D 0x0, o_csn =3D > { > bv_len =3D 0, bv_val =3D 0x0} > , o_private =3D 0x0, o_extra =3D > { > slh_first =3D 0x0} > , o_next =3D > { > stqe_next =3D 0x0} > } >=20 -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --1589865158-1366188462-1212434906=:9248--

1 0

Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie
by hyc＠symas.com 02 Jun '08

02 Jun '08

Rein Tollevik wrote: > I see you have commited an alternative version to syncrepl.c. This > version don't include the serverID in the cookie when syncrepl is used on > the glue database itself, only when used on subordinate DBs. And > unfortunately, it is when used on the glue database it is needed (at least > in my configuration). Hm, can you show the configuration you're dealing with now? Is it still similar to your test053 setup? (By the way, the test053 in HEAD works with the current code.) > So, I still think we have to always include it when it is configured. Probably. But when I went down that route it seemed to require configuring it in several cases that never needed it before, which is why I changed approach. > Unless there exist some easy way to know that a subordinate DB is not > managed by syncrepl. The only solution I know to that is to loop through > all the subordinate DBs and compare the rootdn values. We can think about this some more but I'd like to get 2.4.10 out now. A final resolution of this issue may have to wait for 2.4.11. -- -- Howard Chu CTO, 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#5536) Always use a configured serverID in the syncrepl cookie
by rein＠OpenLDAP.org 02 Jun '08

02 Jun '08

On Thu, 29 May 2008, hyc(a)symas.com wrote: > rein(a)OpenLDAP.org wrote: >> On Wed, 28 May 2008, Howard Chu wrote: >> >>> rein(a)OpenLDAP.org wrote: >> >>>> Syncrepl includes the serverID in the syncCookie in multi-master mode only, >>>> but >>>> there are other configuration that would benefit from it as well. >> >> The commited fix for this bug causes test033-glue-syncrepl to fail. The >> serverID is not set by the config, which makes syncprov_qresp() skip the >> delete when it fins that the consumer presented a cookie with its own sid >> value. > > OK then I guess you're right and we need the default to be -1. I see you have commited an alternative version to syncrepl.c. This version don't include the serverID in the cookie when syncrepl is used on the glue database itself, only when used on subordinate DBs. And unfortunately, it is when used on the glue database it is needed (at least in my configuration). So, I still think we have to always include it when it is configured. Unless there exist some easy way to know that a subordinate DB is not managed by syncrepl. The only solution I know to that is to loop through all the subordinate DBs and compare the rootdn values. Rein

1 0

Re: (ITS#5532) incorrect timestamp of slapd replica log
by quanah＠zimbra.com 02 Jun '08

02 Jun '08

--On June 2, 2008 8:34:12 AM -0400 Francis Swasey <Frank.Swasey(a)uvm.edu> wrote: > Quanah; > > Thank you for that completely unbiased opinion. > > Sheesh... I never had such terrible problems with slurpd. The problem > with slurpd was no one wanted to maintain it anymore. So, with major > changes in slapd came incompatibilities that no one had interest in > working to fix. > > Personally -- I like Scotties comment... the fancier they make the > plumbing, the easier it is to stop it up. > > Syncrepl has some really interesting failure modes. And figuring out > that syncrepl is what loused up your replica can take a while. True, syncrepl has definitely had some interesting issues to sort out. But slurpd did have a lot of problems, and could mess things up just as badly, for very obscure reasons as well. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5532) incorrect timestamp of slapd replica log
by Frank.Swasey＠uvm.edu 02 Jun '08

02 Jun '08

Quanah; Thank you for that completely unbiased opinion. Sheesh... I never had such terrible problems with slurpd. The problem with slurpd was no one wanted to maintain it anymore. So, with major changes in slapd came incompatibilities that no one had interest in working to fix. Personally -- I like Scotties comment... the fancier they make the plumbing, the easier it is to stop it up. Syncrepl has some really interesting failure modes. And figuring out that syncrepl is what loused up your replica can take a while. F On 5/29/08 12:02 AM, quanah(a)zimbra.com wrote: > --On Thursday, May 29, 2008 11:16 AM +0800 Hai <hai.zhao(a)gmail.com> wrote: > >> Hi, Quanah: >> >> I'm considering upgrading from 2.3 to 2.4.x. I haven't test 2.4.x yet. >> Does this bug exist in 2.4.x too? > > Since slurpd was removed because it is completely unreliable and buggy, no, > it does not exist. Sane people use syncrepl replication. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

1 0

RE: (ITS#5542) Bug in libldap/t61.c (for your information)
by emmanuel.duru＠atosorigin.com 02 Jun '08

02 Jun '08

I am currently working on synchronisation between OpenLDAP and X.500 directories. > -----Message d'origine----- > De : Howard Chu [mailto:hyc@symas.com] > Envoyé : vendredi 30 mai 2008 17:31 > À : emmanuel.duru(a)atosorigin.com > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#5542) Bug in libldap/t61.c (for your information) > > emmanuel.duru(a)atosorigin.com wrote: > > Full_Name: Emmanuel Duru > > Version: 2.3.39 > > OS: Windows > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (195.68.44.148) > > > In t61.c/ldap_utf8s_to_t61s(), the second loop is an infinite loop, > there misses > > a "i += j; c += j" at the end of the loop. > > Congratulations, you're the first person to use this code in over 6 years. > Out > of curiosity, why do you need it? > > Thanks for the report, fixed in CVS. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/

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