- openldap-bugs - openldap.org

Re: (ITS#4741) ppolicy.c improperly discards return value of check_password() function
by hyc＠symas.com 09 Nov '06

09 Nov '06

lsherida(a)nccs.nasa.gov wrote: > Full_Name: Lee Sheridan > Version: 2.3.27 > OS: Debian GNU/Linux (etch) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.168.13.7) > > > In servers/slapd/overlays/ppolicy.c, check_password_quality function, at > line 530, the value of the 'ok' variable is discarded by unconditionally > assigning it the value LDAP_SUCCESS. > > The variable is the return code of the user-defined check_password() function, > which is assigned at line 522. The next if-then-else block is checking to > see if the module reported an error, at which point 'ok' would be assigned > LDAP_OTHER regardless of what check_password() returned. A superfluous else > block appears after this check, assigning 'ok' to LDAP_SUCCESS. > > It works fine for me if I remove the else block. > > Thanks, A fix has been committed to CVS HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

[Fwd: Re: (ITS#4739) Server crashes every time alias is dereferenced]
by hyc＠symas.com 09 Nov '06

09 Nov '06

This is a multi-part message in MIME format. --------------080602030800020000070003 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit This is the info Kevin sent before. aliases are known to work incorrectly in back-ldbm. back-ldbm has been deprecated since OpenLDAP 2.2 and has been deleted from the source tree for OpenLDAP 2.4. As such, I don't see us taking any action on this bug report. Use back-bdb or back-hdb instead. -------- Original Message -------- Subject: Re: (ITS#4739) Server crashes every time alias is dereferenced Date: Wed, 8 Nov 2006 22:09:51 -0800 (PST) From: Kevin Hardiman <hardimankevin(a)yahoo.com> To: Howard Chu <hyc(a)symas.com> Howard, To answer your initial questions: 1. The aliased entry does exist 2. The backined is ldbm 3. Attached is a sanitized slapd.conf 4. Attached is a sanitized ldif export Here's the output from running slapd (sanitized for sensitive information) without forking (-d 1): > >> dnPrettyNormal: <ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com> <<< dnPrettyNormal: <ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com>, <ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: => ldbm_back_search dn2entry_r: dn: "ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" => dn2id( "ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" ) ====> cache_find_entry_ndn2id("ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com"): 16378 (1 tries) <= dn2id 16378 (in cache) => id2entry_r( 16378 ) ====> cache_find_entry_id( 16378 ) "ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com" (found) (1 tries) <= id2entry_r( 16378 ) 0x82d2068 (cache) search_candidates: base="ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" s=2 d=3 => filter_candidates => list_candidates 0xa0 => filter_candidates => dn2idl( "@ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" ) => ldbm_cache_open( "dn2id.dbb", 73, 600 ) <= ldbm_cache_open (cache 0) <= filter_candidates 2 => filter_candidates => list_candidates 0xa1 => filter_candidates => equality_candidates => ldbm_cache_open( "objectClass.dbb", 73, 600 ) <= ldbm_cache_open (cache 3) => key_read <= index_read 1 candidates <= equality_candidates 1 <= filter_candidates 1 => filter_candidates => equality_candidates => ldbm_cache_open( "objectClass.dbb", 73, 600 ) <= ldbm_cache_open (cache 3) => key_read <= index_read 0 candidates <= equality_candidates NULL <= equality_candidates 0 <= filter_candidates 0 idl_free: called with NULL pointer => filter_candidates => list_candidates 0xa0 => filter_candidates => equality_candidates => ldbm_cache_open( "objectClass.dbb", 73, 600 ) <= ldbm_cache_open (cache 3) => key_read <= index_read 4 candidates <= equality_candidates 4 <= filter_candidates 4 => filter_candidates => equality_candidates => ldbm_cache_open( "uid.dbb", 73, 600 ) <= ldbm_cache_open (cache 4) => key_read <= index_read 0 candidates <= equality_candidates NULL <= equality_candidates 0 <= filter_candidates 0 <= list_candidates NULL <= filter_candidates 0 idl_free: called with NULL pointer <= list_candidates 1 <= filter_candidates 1 <= list_candidates 1 <= filter_candidates 1 ====> cache_return_entry_r( 16378 ): returned (0) => id2entry_r( 16400 ) ====> cache_find_entry_id( 16400 ) "uid=test,ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com" (found) (1 tries) <= id2entry_r( 16400 ) 0x82d5580 (cache) dn2entry_r: dn: "ÿÿÐuhH_øP" => dn2id( "ÿÿÐuhH_øP" ) => ldbm_cache_open( "dn2id.dbb", 73, 600 ) <= ldbm_cache_open (cache 0) <= dn2id NOID slapd: dn.c:1148: dnParent: Assertion `( ( ( ( (p[ 0 ]) >= 'a' && (p[ 0 ]) <= 'z' ) || ( (p[ 0 ]) >= 'A' && (p[ 0 ]) <= 'Z' ) ) ) || ( ( (p[ 0 ]) >= '0' && (p[ 0 ]) <= '9' ) ) )' failed. Aborted Let me know if you need anything else. Regards, Kevin Hardiman ----- Original Message ---- From: Howard Chu <hyc(a)symas.com> To: hardimankevin(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Wednesday, November 8, 2006 9:45:27 PM Subject: Re: (ITS#4739) Server crashes every time alias is dereferenced hardimankevin(a)yahoo.com wrote: > Full_Name: Kevin Hardiman > Version: 2.3.27 > OS: Linux (Mandriva 2007) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.90.130.182) > > > Using the very simple alias below, OpenLDAP will crash every time it is > dereferenced: > > dn: uid=test,ou=Users,ou=bladiant,ou=smb,ou=Core Services,dc=example,dc=com > objectClass: alias > objectclass: extensibleObject > uid: test > aliasedObjectName: uid=test,ou=Users,dc=example,dc=com > > This error has been experience with OpenLDAP releases 2.3.6 and 2.3.27, both in > the form of provided Mandriva packages. I also have seen a number of references > to this error in previous releases, with no explicit fix. Please advise. Well, considering that no one has reported any such problem during the whole time releases 2.3.6-2.3.27 were published, it's no surprise that there has been no fix yet. There's not enough information here to reproduce the bug. What backend are you using, what other entries are in the database? In particular, does "uid=test,ou=Users,dc=example,dc=com" exist? You should provide a sample slapd.conf and minimal LDIF needed to reproduce the error. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ ------------------------------------------------------------------------ Sponsored Link $200,000 mortgage for $660/mo - 30/15 yr fixed, reduce debt, home equity - Click now for info <http://www.ratemarketplace.com/forms/form.jsp?ADEL=Os4fVJ19lSwzAOc/zMz/CYLq…> -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ --------------080602030800020000070003 Content-Type: application/octet-stream; name="slapd.conf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapd.conf" aW5jbHVkZQkvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9jb3JlLnNjaGVtYQppbmNsdWRl CS91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2Nvc2luZS5zY2hlbWEKaW5jbHVkZQkvdXNy L3NoYXJlL29wZW5sZGFwL3NjaGVtYS9jb3JiYS5zY2hlbWEgCmluY2x1ZGUJL3Vzci9zaGFy ZS9vcGVubGRhcC9zY2hlbWEvaW5ldG9yZ3BlcnNvbi5zY2hlbWEKaW5jbHVkZQkvdXNyL3No YXJlL29wZW5sZGFwL3NjaGVtYS9qYXZhLnNjaGVtYSAKaW5jbHVkZQkvdXNyL3NoYXJlL29w ZW5sZGFwL3NjaGVtYS9rcmI1LWtkYy5zY2hlbWEKaW5jbHVkZSAvdXNyL3NoYXJlL29wZW5s ZGFwL3NjaGVtYS9rZXJiZXJvc29iamVjdC5zY2hlbWEKaW5jbHVkZQkvdXNyL3NoYXJlL29w ZW5sZGFwL3NjaGVtYS9taXNjLnNjaGVtYQppbmNsdWRlCS91c3Ivc2hhcmUvb3BlbmxkYXAv c2NoZW1hL25pcy5zY2hlbWEKaW5jbHVkZQkvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9v cGVubGRhcC5zY2hlbWEgCmluY2x1ZGUgL3Vzci9zaGFyZS9vcGVubGRhcC9zY2hlbWEvYXV0 b2ZzLnNjaGVtYQppbmNsdWRlIC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL3NhbWJhLnNj aGVtYQppbmNsdWRlIC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2tvbGFiLnNjaGVtYQpp bmNsdWRlIC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2V2b2x1dGlvbnBlcnNvbi5zY2hl bWEKaW5jbHVkZSAvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9jYWxlbmRhci5zY2hlbWEK aW5jbHVkZSAvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9zdWRvLnNjaGVtYQppbmNsdWRl IC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2Ruc3pvbmUuc2NoZW1hCmluY2x1ZGUgL3Vz ci9zaGFyZS9vcGVubGRhcC9zY2hlbWEvZGhjcC5zY2hlbWEKaW5jbHVkZQkvZXRjL29wZW5s ZGFwL3NjaGVtYS9sb2NhbC5zY2hlbWEKaW5jbHVkZSAvdXNyL3NoYXJlL29wZW5sZGFwL3Nj aGVtYS9tb3ppbGxhQWJQZXJzb25BbHBoYS5zY2hlbWEKaW5jbHVkZSAJL2V0Yy9vcGVubGRh cC9zbGFwZC5hY2Nlc3MuY29uZgoKYWNjZXNzIHRvIGRuLnN1YnRyZWU9ImRjPWV4YW1wbGUs ZGM9Y29tIgogICAgICAgIGJ5IGdyb3VwPSJjbj1SZXBsaWNhdG9yLG91PUdyb3VwLGRjPWV4 YW1wbGUsZGM9Y29tIgogICAgICAgIGJ5IHVzZXJzIHJlYWQKICAgICAgICBieSBhbm9ueW1v dXMgcmVhZAoKbGltaXRzIGdyb3VwPSJjbj1SZXBsaWNhdG9yLG91PUdyb3VwLGRjPWV4YW1w bGUsZGM9Y29tIgogc2l6ZT11bmxpbWl0ZWQKIHRpbWU9dW5saW1pdGVkCnBpZGZpbGUJCS92 YXIvcnVuL2xkYXAvc2xhcGQucGlkCmFyZ3NmaWxlCS92YXIvcnVuL2xkYXAvc2xhcGQuYXJn cwptb2R1bGVwYXRoCS91c3IvbGliL29wZW5sZGFwClRMU1JhbmRGaWxlICAgICAgICAgICAg L2Rldi9yYW5kb20KVExTQ2lwaGVyU3VpdGUgICAgICAgICBISUdIOk1FRElVTTorU1NMdjIK VExTQ2VydGlmaWNhdGVGaWxlICAgICAgL2V0Yy9zc2wvb3BlbmxkYXAvbGRhcGNlcnQucGVt ClRMU0NlcnRpZmljYXRlS2V5RmlsZSAgIC9ldGMvc3NsL29wZW5sZGFwL2xkYXBrZXkucGVt ClRMU0NBQ2VydGlmaWNhdGVQYXRoICAgL2V0Yy9zc2wvb3BlbmxkYXAvClRMU0NBQ2VydGlm aWNhdGVGaWxlICAgIC9ldGMvc3NsL29wZW5sZGFwL2NhY2VydC5wZW0KVExTVmVyaWZ5Q2xp ZW50IHRyeSAjIChbbmV2ZXJdfGFsbG93fHRyeXxkZW1hbmQpCmxvZ2xldmVsIDI2OAphbGxv dyBiaW5kX3YyCnNhc2wtc2VjcHJvcHMgbm9uZQpkYXRhYmFzZQlsZGJtCnN1ZmZpeAkJImRj PWJsYWRpYW50LGRjPWNvbSIKcm9vdGRuCQkiY249S2V2aW4gSGFyZGltYW4sb3U9UGVvcGxl LGRjPWV4YW1wbGUsZGM9Y29tIgpsYXN0bW9kCQlvbgpkaXJlY3RvcnkJL3Zhci9saWIvbGRh cApjaGVja3BvaW50IDI1NiA1CmluZGV4CW9iamVjdENsYXNzLHVpZCx1aWROdW1iZXIsZ2lk TnVtYmVyLG1lbWJlcnVpZAllcQppbmRleAljbixtYWlsLHN1cm5hbWUsZ2l2ZW5uYW1lCQll cSxzdWJpbml0aWFsCiAK --------------080602030800020000070003 Content-Type: application/octet-stream; name="minimal_export.ldif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="minimal_export.ldif" ZG46IG91PVVzZXJzLCBkYz1leGFtcGxlLGRjPWNvbQpvdTogVXNlcnMKb2JqZWN0Q2xhc3M6 IG9yZ2FuaXphdGlvbmFsVW5pdAoKZG46IHVpZD10ZXN0LCBvdT1Vc2VycywgZGM9ZXhhbXBs ZSxkYz1jb20Kc2FtYmFQcmltYXJ5R3JvdXBTSUQ6IFhYWFgKc2FtYmFMTVBhc3N3b3JkOiBY WFhYCmRpc3BsYXlOYW1lOiBLZXZpbiBIYXJkaW1hbgpvYmplY3RDbGFzczogdG9wCm9iamVj dENsYXNzOiBpbmV0T3JnUGVyc29uCm9iamVjdENsYXNzOiBwb3NpeEFjY291bnQKb2JqZWN0 Q2xhc3M6IHNoYWRvd0FjY291bnQKb2JqZWN0Q2xhc3M6IHNhbWJhU2FtQWNjb3VudAp1c2Vy UGFzc3dvcmQ6OiBYWFhYCnNhbWJhTG9nb25UaW1lOiAwCnVpZE51bWJlcjogNTAwCnVpZDog dGVzdApjbjogdGVzdApzYW1iYUxvZ29mZlRpbWU6IDIxNDc0ODM2NDcKc2FtYmFQd2RMYXN0 U2V0OiAxMTYxOTIzMzcwCmxvZ2luU2hlbGw6IC9iaW4vYmFzaApzYW1iYUFjY3RGbGFnczog W1VdCmdpZE51bWJlcjogMTAwCnNhbWJhUHdkTXVzdENoYW5nZTogMTE2NTgxMTM3MApzYW1i YVNJRDogWFhYCnNhbWJhUHdkQ2FuQ2hhbmdlOiAwCnNhbWJhTlRQYXNzd29yZDogWFhYCmdl Y29zOiBLZXZpbiBIYXJkaW1hbgpkZXNjcmlwdGlvbjogS2V2aW4gSGFyZGltYW4KaG9tZURp cmVjdG9yeTogL2hvbWUvdGVzdApzYW1iYUtpY2tvZmZUaW1lOiAyMTQ3NDgzNjQ3CnNuOiBI YXJkaW1hbgoKZG46IG91PUNvcmUgU2VydmljZXMsIGRjPWV4YW1wbGUsZGM9Y29tCm91OiBD b3JlIFNlcnZpY2VzCm9iamVjdENsYXNzOiB0b3AKb2JqZWN0Q2xhc3M6IG9yZ2FuaXphdGlv bmFsVW5pdAoKZG46IG91PXNtYiwgb3U9Q29yZSBTZXJ2aWNlcywgZGM9ZXhhbXBsZSxkYz1j b20Kb3U6IHNtYgpvYmplY3RDbGFzczogdG9wCm9iamVjdENsYXNzOiBvcmdhbml6YXRpb25h bFVuaXQKCmRuOiBvdT1leGFtcGxlLG91PXNtYiwgb3U9Q29yZSBTZXJ2aWNlcywgZGM9ZXhh bXBsZSxkYz1jb20Kb3U6IGV4YW1wbGUKb2JqZWN0Q2xhc3M6IHRvcApvYmplY3RDbGFzczog b3JnYW5pemF0aW9uYWxVbml0Cgpkbjogb3U9VXNlcnMsb3U9ZXhhbXBsZSxvdT1zbWIsIG91 PUNvcmUgU2VydmljZXMsIGRjPWV4YW1wbGUsZGM9Y29tCm91OiBVc2VycwpvYmplY3RDbGFz czogdG9wCm9iamVjdENsYXNzOiBvcmdhbml6YXRpb25hbFVuaXQKCmRuOiB1aWQ9dGVzdCxv dT1Vc2VycyxvdT1leGFtcGxlLG91PXNtYixvdT1Db3JlIFNlcnZpY2VzLGRjPWV4YW1wbGUs ZGM9Y29tCm9iamVjdENsYXNzOiBhbGlhcwpvYmplY3RjbGFzczogZXh0ZW5zaWJsZU9iamVj dAp1aWQ6IHRlc3QKYWxpYXNlZE9iamVjdE5hbWU6IHVpZD10ZXN0LG91PVVzZXJzLGRjPWV4 YW1wbGUsZGM9Y29tCg== --------------080602030800020000070003--

1 0

Re: (ITS#4741) ppolicy.c improperly discards return value of check_password() function
by quanah＠stanford.edu 09 Nov '06

09 Nov '06

--On Thursday, November 09, 2006 2:20 AM +0000 lsherida(a)nccs.nasa.gov wrote: > Full_Name: Lee Sheridan > Version: 2.3.27 > OS: Debian GNU/Linux (etch) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.168.13.7) > > > In servers/slapd/overlays/ppolicy.c, check_password_quality function, at > line 530, the value of the 'ok' variable is discarded by unconditionally > assigning it the value LDAP_SUCCESS. > > The variable is the return code of the user-defined check_password() > function, which is assigned at line 522. The next if-then-else block is > checking to see if the module reported an error, at which point 'ok' > would be assigned LDAP_OTHER regardless of what check_password() > returned. A superfluous else block appears after this check, assigning > 'ok' to LDAP_SUCCESS. > > It works fine for me if I remove the else block. Howard checked in a fix to HEAD for this last night, please test. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4739) Server crashes every time alias is dereferenced
by quanah＠stanford.edu 09 Nov '06

09 Nov '06

--On Thursday, November 09, 2006 5:08 PM +0000 hardimankevin(a)yahoo.com wrote: > --0-1753053770-1163092074=:90949 > Content-Type: text/plain; charset=ascii > Content-Transfer-Encoding: quoted-printable > > Buchan,=0A=0ANot sure what to say - I can reproduce this error with the > Man= driva packages and from source (which leads me to believe it has > nothing to= do with the packaging) with a 100% rate. I had sent Howard > Chu an email l= ast night with much more detail; if you'd like me to > forward that I will.= =0A=0A -kph=0A=0A=0A----- Original Message > You should send responses with more detail to the ITS, not to individual people. This allows all developers and other involved to have the full information. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4739) Server crashes every time alias is dereferenced
by hardimankevin＠yahoo.com 09 Nov '06

09 Nov '06

--0-1753053770-1163092074=:90949 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Buchan,=0A=0ANot sure what to say - I can reproduce this error with the Man= driva packages and from source (which leads me to believe it has nothing to= do with the packaging) with a 100% rate. I had sent Howard Chu an email l= ast night with much more detail; if you'd like me to forward that I will.= =0A=0A -kph=0A=0A=0A----- Original Message ----=0AFrom: Buchan Milne <bg= milne(a)staff.telkomsa.net>=0ATo: hardimankevin(a)yahoo.com=0ACc: openldap-its@= openldap.org=0ASent: Thursday, November 9, 2006 11:07:10 AM=0ASubject: Re: = (ITS#4739) Server crashes every time alias is dereferenced=0A=0AOn Wednesda= y 08 November 2006 21:18, hardimankevin(a)yahoo.com wrote:=0A> Full_Name: Kev= in Hardiman=0A> Version: 2.3.27=0A> OS: Linux (Mandriva 2007)=0A> URL: ftp:= //ftp.openldap.org/incoming/=0A> Submission from: (NULL) (24.90.130.182)=0A= >=0A>=0A> Using the very simple alias below, OpenLDAP will crash every time= it is=0A> dereferenced:=0A>=0A> dn: uid=3Dtest,ou=3DUsers,ou=3Dbladiant,ou= =3Dsmb,ou=3DCore Services,dc=3Dexample,dc=3Dcom=0A> objectClass: alias=0A> = objectclass: extensibleObject=0A> uid: test=0A> aliasedObjectName: uid=3Dte= st,ou=3DUsers,dc=3Dexample,dc=3Dcom=0A>=0A> This error has been experience = with OpenLDAP releases 2.3.6 and 2.3.27,=0A> both in the form of provided M= andriva packages. I also have seen a number=0A> of references to this erro= r in previous releases, with no explicit fix. =0A> Please advise.=0A=0A=0AC= an't reproduce:=0A=0A$ ldapsearch -h localhost -LLL -s children -a never -= x -b "ou=3DTest =0AAliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom"=0Adn: uid=3D= bgmilne,ou=3DTest Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom=0AobjectClass:= alias=0AobjectClass: extensibleObject=0Auid: bgmilne=0AaliasedObjectName: = uid=3Dbgmilne,ou=3DPeople,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom=0A=0A$ ldapsea= rch -h localhost -LLL -s children -a always -x -b "ou=3DTest =0AAliases,dc= =3Dranger,dc=3Ddnsalias,dc=3Dcom" objectclass=0Adn: uid=3Dbgmilne,ou=3DPeop= le,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom=0AobjectClass: mailRecipient=0Aobject= Class: person=0AobjectClass: organizationalPerson=0AobjectClass: inetOrgPer= son=0AobjectClass: posixAccount=0AobjectClass: top=0AobjectClass: kerberosS= ecurityObject=0AobjectClass: shadowAccount=0AobjectClass: sambaSamAccount= =0A=0A$ rpm -q openldap-servers=0Aopenldap-servers-2.3.27-1mdv2007.0=0A=0A$= rpm -q openldap-servers --qf "%{PACKAGER}\n"=0ABuchan Milne <bgmilne@mandr= iva.org>=0A=0A=0ARegards,=0ABuchan=0A=0A-- =0ABuchan Milne=0AISP Systems Sp= ecialist - Monitoring/Authentication Team Leader=0AB.Eng,RHCE(8030047890107= 97),LPIC-2(LPI000074592)=0A=0A=0A=0A=0A=0A=0A=0A =0A_______________________= _____________________________________________________________=0ADo you Yaho= o!?=0AEveryone is raving about the all-new Yahoo! Mail beta.=0Ahttp://new.m= ail.yahoo.com --0-1753053770-1163092074=:90949 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable <html><head><style type=3D"text/css"></style></he= ad><body><div style=3D"font-family:arial, helvetica, sans-serif;font-size:1= 0pt"><div style=3D"font-family: arial,helvetica,sans-serif; font-size: 10pt= ;">Buchan, Not sure what to say - I can reproduce this error with th= e Mandriva packages and from source (which leads me to believe it has nothi= ng to do with the packaging) with a 100% rate.  I had sent Howard Chu = an email last night with much more detail; if you'd like me to forward that= I will.     -kph <div style=3D"font-famil= y: times new roman,new york,times,serif; font-size: 12pt;">----- Original M= essage ---- From: Buchan Milne <bgmilne(a)staff.telkomsa.net> To:= hardimankevin(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Thursday= , November 9, 2006 11:07:10 AM Subject: Re: (ITS#4739) Server crashes ev= ery time alias is dereferenced <div>On Wednesday 08 November 2006 21= :18, hardimankevin(a)yahoo.com wrote: > Full_Name: Kevin Hardiman > V= ersion: 2.3.27 > OS: Linux (Mandriva 2007) > URL: ftp://ftp.ope= nldap.org/incoming/ > Submission from: (NULL) (24.90.130.182) >= > > Using the very simple alias below, OpenLDAP will crash eve= ry time it is > dereferenced: > > dn: uid=3Dtest,ou=3DUse= rs,ou=3Dbladiant,ou=3Dsmb,ou=3DCore Services,dc=3Dexample,dc=3Dcom > = objectClass: alias > objectclass: extensibleObject > uid: test<= br>> aliasedObjectName: uid=3Dtest,ou=3DUsers,dc=3Dexample,dc=3Dcom &= gt; > This error has been experience with OpenLDAP releases 2.3.6 and= 2.3.27, > both in the form of provided Mandriva packages. &nbsp= ;I also have seen a number > of references to this error in previous = releases, with no explicit fix. > Please advise. Can't re= produce: $ ldapsearch -h localhost -LLL -s children -a never &n= bsp;-x -b "ou=3DTest Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom" dn: uid=3Dbgmilne,ou=3D= Test Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom objectClass: alias ob= jectClass: extensibleObject uid: bgmilne aliasedObjectName: uid=3Dbgm= ilne,ou=3DPeople,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom $ ldapsearch -h = localhost -LLL -s children -a always  -x -b "ou=3DTest Aliase= s,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom" objectclass dn: uid=3Dbgmilne,ou= =3DPeople,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom objectClass: mailRecipient<= br>objectClass: person objectClass: organizationalPerson objectClass:= inetOrgPerson objectClass: posixAccount objectClass: top objectCl= ass: kerberosSecurityObject objectClass: shadowAccount objectClass: s= ambaSamAccount $ rpm -q openldap-servers openldap-servers-2.3.27-= 1mdv2007.0 $ rpm -q openldap-servers --qf "%{PACKAGER}\n" Buchan = Milne <bgmilne(a)mandriva.org> Regards, Buchan -- = Buchan Milne ISP Systems Specialist - Monitoring/Authentication Team Leader B.Eng,RHCE(803004789010797),LPIC-= 2(LPI000074592) </div></div> </div></div> =0A=0A<hr size=3D1>Every= one is raving about <a href=3D"http://us.rd.yahoo.com/evt=3D45083/*http://a= dvision.webevents.yahoo.com/mailbeta">the all-new Yahoo! Mail beta.</a></bo= dy></html> --0-1753053770-1163092074=:90949--

1 0

Re: (ITS#4739) Server crashes every time alias is dereferenced
by bgmilne＠staff.telkomsa.net 09 Nov '06

09 Nov '06

--nextPart2681002.ZbxIqWnAlZ Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 08 November 2006 21:18, hardimankevin(a)yahoo.com wrote: > Full_Name: Kevin Hardiman > Version: 2.3.27 > OS: Linux (Mandriva 2007) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.90.130.182) > > > Using the very simple alias below, OpenLDAP will crash every time it is > dereferenced: > > dn: uid=3Dtest,ou=3DUsers,ou=3Dbladiant,ou=3Dsmb,ou=3DCore Services,dc=3D= example,dc=3Dcom > objectClass: alias > objectclass: extensibleObject > uid: test > aliasedObjectName: uid=3Dtest,ou=3DUsers,dc=3Dexample,dc=3Dcom > > This error has been experience with OpenLDAP releases 2.3.6 and 2.3.27, > both in the form of provided Mandriva packages. I also have seen a number > of references to this error in previous releases, with no explicit fix.=20 > Please advise. Can't reproduce: $ ldapsearch -h localhost -LLL -s children -a never -x -b "ou=3DTest=20 Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom" dn: uid=3Dbgmilne,ou=3DTest Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom objectClass: alias objectClass: extensibleObject uid: bgmilne aliasedObjectName: uid=3Dbgmilne,ou=3DPeople,dc=3Dranger,dc=3Ddnsalias,dc= =3Dcom $ ldapsearch -h localhost -LLL -s children -a always -x -b "ou=3DTest=20 Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom" objectclass dn: uid=3Dbgmilne,ou=3DPeople,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom objectClass: mailRecipient objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: kerberosSecurityObject objectClass: shadowAccount objectClass: sambaSamAccount $ rpm -q openldap-servers openldap-servers-2.3.27-1mdv2007.0 $ rpm -q openldap-servers --qf "%{PACKAGER}\n" Buchan Milne <bgmilne(a)mandriva.org> Regards, Buchan =2D-=20 Buchan Milne ISP Systems Specialist - Monitoring/Authentication Team Leader B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592) --nextPart2681002.ZbxIqWnAlZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFU1IvrJK6UGDSBKcRAhkQAKDCpV5W+plszHrf/GIqkx2yMcTtwQCePs67 JaAwrB9eaYnzEcK7uS41ZEo= =4WpH -----END PGP SIGNATURE----- --nextPart2681002.ZbxIqWnAlZ--

1 0

Re: (ITS#4739) Server crashes every time alias is dereferenced
by hyc＠symas.com 08 Nov '06

08 Nov '06

hardimankevin(a)yahoo.com wrote: > Full_Name: Kevin Hardiman > Version: 2.3.27 > OS: Linux (Mandriva 2007) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.90.130.182) > > > Using the very simple alias below, OpenLDAP will crash every time it is > dereferenced: > > dn: uid=test,ou=Users,ou=bladiant,ou=smb,ou=Core Services,dc=example,dc=com > objectClass: alias > objectclass: extensibleObject > uid: test > aliasedObjectName: uid=test,ou=Users,dc=example,dc=com > > This error has been experience with OpenLDAP releases 2.3.6 and 2.3.27, both in > the form of provided Mandriva packages. I also have seen a number of references > to this error in previous releases, with no explicit fix. Please advise. Well, considering that no one has reported any such problem during the whole time releases 2.3.6-2.3.27 were published, it's no surprise that there has been no fix yet. There's not enough information here to reproduce the bug. What backend are you using, what other entries are in the database? In particular, does "uid=test,ou=Users,dc=example,dc=com" exist? You should provide a sample slapd.conf and minimal LDIF needed to reproduce the error. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4741) ppolicy.c improperly discards return value of check_password() function
by lsherida＠nccs.nasa.gov 08 Nov '06

08 Nov '06

Full_Name: Lee Sheridan Version: 2.3.27 OS: Debian GNU/Linux (etch) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.168.13.7) In servers/slapd/overlays/ppolicy.c, check_password_quality function, at line 530, the value of the 'ok' variable is discarded by unconditionally assigning it the value LDAP_SUCCESS. The variable is the return code of the user-defined check_password() function, which is assigned at line 522. The next if-then-else block is checking to see if the module reported an error, at which point 'ok' would be assigned LDAP_OTHER regardless of what check_password() returned. A superfluous else block appears after this check, assigning 'ok' to LDAP_SUCCESS. It works fine for me if I remove the else block. Thanks,

1 0

(ITS#4740) SASL bind assert
by hyc＠OpenLDAP.org 08 Nov '06

08 Nov '06

Full_Name: Howard Chu Version: all < 2.3.29 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc Apparently this bug was discovered by Evgeny Legerov but was not previously reported to anyone on the Project. The bug is now fixed in HEAD and RE23. Performing a SASL Bind with an authcid longer than 255 characters, with a space as the 255th character, will cause the length of the normalized name to be computed incorrectly, failing to take into account the escaping of the space character. (The SASL Bind code truncates all incoming names longer than 255 to exactly 255 characters.) This triggers an assert in libldap because the resulting string length doesn't match what we expected it to be. The fix is in libldap/getdn.c rev 1.134. The MITRE CVE record for this bug is http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5779

1 0

(ITS#4739) Server crashes every time alias is dereferenced
by hardimankevin＠yahoo.com 08 Nov '06

08 Nov '06

Full_Name: Kevin Hardiman Version: 2.3.27 OS: Linux (Mandriva 2007) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.90.130.182) Using the very simple alias below, OpenLDAP will crash every time it is dereferenced: dn: uid=test,ou=Users,ou=bladiant,ou=smb,ou=Core Services,dc=example,dc=com objectClass: alias objectclass: extensibleObject uid: test aliasedObjectName: uid=test,ou=Users,dc=example,dc=com This error has been experience with OpenLDAP releases 2.3.6 and 2.3.27, both in the form of provided Mandriva packages. I also have seen a number of references to this error in previous releases, with no explicit fix. Please advise. Kevin Hardiman

1 0

Re: (ITS#4738) hdb livelock
by hyc＠symas.com 07 Nov '06

07 Nov '06

richton(a)nbcs.rutgers.edu wrote: > Please visit > https://www.nbcs.rutgers.edu/~richton/richton-20061107-livelock_2.txt for > an updated backtrace. This one almost looks like it has lock contention, > and a writewaiter assert is notably missing... The trace shows several threads backing off because they think some other thread is about to read the entry from the database. At a guess, none of them is actually going to perform the database read. Most likely a lock is missing here. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4738) hdb livelock
by richton＠nbcs.rutgers.edu 07 Nov '06

07 Nov '06

Please visit https://www.nbcs.rutgers.edu/~richton/richton-20061107-livelock_2.txt for an updated backtrace. This one almost looks like it has lock contention, and a writewaiter assert is notably missing... I'm going to rm the bad link, it can only hurt people. On Tue, 7 Nov 2006, Aaron Richton wrote: > Sigh. As may be obvious to anybody unfortunate enough to look at the link, I > seem to have gotten my core files confused. I have a bunch of db_stat -CA > done properly, but the backtrace for this may be lost to the bit bucket. I'll > poke around my systems and see what I can find, but I think it might be > nothing. A syslog of "waiting for 1027 threads to terminate" might be the > only other durable evidence. >

1 0

Re: (ITS#4738) hdb livelock
by richton＠nbcs.rutgers.edu 07 Nov '06

07 Nov '06

Sigh. As may be obvious to anybody unfortunate enough to look at the link, I seem to have gotten my core files confused. I have a bunch of db_stat -CA done properly, but the backtrace for this may be lost to the bit bucket. I'll poke around my systems and see what I can find, but I think it might be nothing. A syslog of "waiting for 1027 threads to terminate" might be the only other durable evidence.

1 0

(ITS#4738) hdb livelock
by richton＠nbcs.rutgers.edu 07 Nov '06

07 Nov '06

Full_Name: Aaron Richton Version: 2.3.28+4720 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061107-livelock.txt Submission from: (NULL) (128.6.31.137) See also ITS#4720, although this is slightly different. hdb livelock (CPU 100% gunned) on 2.3.28 with patch for ITS #4720 (syncprov.c 1.161 -> 1.162 diff). See URL for backtrace and db_stat -CA of the database on threads t@13 and t@16, which (if I'm reading correctly) are the affected ones. I have the db_stat -CA of the other backends saved if I misread, and the core file available if variables are needed. Aside, I know you're looking for RE23 testing, I was kicking the tires of that and about to put it up when this happened. Soon I'll be there, regardless of how this turns out, due to writewaiter concern.

1 0

Re: (ITS#4737) "overlay not found"
by ando＠sys-net.it 07 Nov '06

07 Nov '06

mmollet(a)westar.com wrote: > Full_Name: Matthieu Mollet > Version: 2.2.13 > OS: Centos 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (208.45.242.10) > > > Built the smbk5pwd.la overlay and installed it with the 2.2.13 openldap that > comes with Centos. Added module = pathto/smbk5pwd.la and overlay = smbk5pwd > slapd fails with "overlay smbk5pwd not found" > the syntax "<keyword> = <value>" has never been implemented in OpenLDAP software; the keyword "module" has never been supported as well. I suggest you read at least slapd.conf(5) (but I suspect you need to read more) before considering the possibility of a software bug. This ITS will be closed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4737) "overlay not found"
by Kurt＠OpenLDAP.org 07 Nov '06

07 Nov '06

At 09:19 AM 11/7/2006, mmollet(a)westar.com wrote: >Full_Name: Matthieu Mollet >Version: 2.2.13 >OS: Centos 4 >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (208.45.242.10) > > >Built the smbk5pwd.la overlay and installed it with the 2.2.13 openldap that >comes with Centos. Added module = pathto/smbk5pwd.la and overlay = smbk5pwd >slapd fails with "overlay smbk5pwd not found" While there is no indication that this behavior is due to a bug in OpenLDAP Software and 2.2 is Historic, there seems this report should be closed. If you believe this behavior due to a bug in OpenLDAP Software, I suggest you duplicate it in the latest 2.3 release and then file a new bug report that elaborates on why you believe the behavior is due to a bug in OpenLDAP Software.

1 0

(ITS#4737) "overlay not found"
by mmollet＠westar.com 07 Nov '06

07 Nov '06

Full_Name: Matthieu Mollet Version: 2.2.13 OS: Centos 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (208.45.242.10) Built the smbk5pwd.la overlay and installed it with the 2.2.13 openldap that comes with Centos. Added module = pathto/smbk5pwd.la and overlay = smbk5pwd slapd fails with "overlay smbk5pwd not found"

1 0

Re: (ITS#4736) writewaiter == 1 in connection_destroy
by hyc＠symas.com 06 Nov '06

06 Nov '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt > Submission from: (NULL) (68.196.250.61) > > > 822 assert( c->c_writewaiter == 0); > > Unfortunately writewaiter == 1, the assertion catches, byebye... > > This happened earlier with 2.3.27 (see > https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt). Kurt > advised upgrading to 2.3.28, which was running when this caught today. See > https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt for the > 2.3.28 trace, not that it looks all too different. I've sync'd the connection manager in RE23 with HEAD. Please test RE23. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4736) writewaiter == 1 in connection_destroy
by hyc＠symas.com 06 Nov '06

06 Nov '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt > Submission from: (NULL) (68.196.250.61) > > > 822 assert( c->c_writewaiter == 0); > > Unfortunately writewaiter == 1, the assertion catches, byebye... > > This happened earlier with 2.3.27 (see > https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt). Kurt > advised upgrading to 2.3.28, which was running when this caught today. See > https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt for the > 2.3.28 trace, not that it looks all too different. There have been no changes to the connection management since 2.3.27, so it makes sense that the traces look the same. A number of fixes have gone into HEAD along these lines, but they haven't been backported to RE23. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4736) writewaiter == 1 in connection_destroy
by richton＠nbcs.rutgers.edu 06 Nov '06

06 Nov '06

Full_Name: Aaron Richton Version: 2.3.28 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt Submission from: (NULL) (68.196.250.61) 822 assert( c->c_writewaiter == 0); Unfortunately writewaiter == 1, the assertion catches, byebye... This happened earlier with 2.3.27 (see https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt). Kurt advised upgrading to 2.3.28, which was running when this caught today. See https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt for the 2.3.28 trace, not that it looks all too different.

1 0

Re: (ITS#4704) accesslog database fails to store contextCSN at shutdown
by quanah＠stanford.edu 06 Nov '06

06 Nov '06

--On Tuesday, November 07, 2006 12:35 AM +0000 quanah(a)stanford.edu wrote: > I've finally figured out how to reproduce this -- The problem is related > to the log purging done by access log. Here is what I did: After applying the commit to HEAD to my source, behavior after log purge was correct. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4704) accesslog database fails to store contextCSN at shutdown
by quanah＠stanford.edu 06 Nov '06

06 Nov '06

I've finally figured out how to reproduce this -- The problem is related to the log purging done by access log. Here is what I did: Make changes to the database, that were replicated. Everything is happy. Shut down slapd, modify the logpurge parameter so that log purging is done. Restart slapd Verified that log purging was done, and that everything was still happily in sync. Stop slapd, restart slapd Now the access log DB has generated a new CSN that is in the future of the suffix stored CSN. So it appears that somehow the logpurge operation either causes a new contextCSN to be written at the time the server is shut down, or it erases the contextCSN held by the accesslog db. Now, this is when I restarted slapd: Nov 6 16:27:14 ldap-dev0 slapd[27400]: @(#) $OpenLDAP: slapd 2.3.28 (Oct 26 2006 13:41:27) $ ^Iquanah@ldap-uat00.stanford.edu:/usr/local/build/openldap-2.3.28/servers/slapd However, the contextCSN that was generated is: contextCSN: 20061107002625Z#000000#00#000000 This matches the time at which I started slapd when log purging was run: Nov 6 16:26:25 ldap-dev0 slapd[27385]: @(#) $OpenLDAP: slapd 2.3.28 (Oct 26 2006 13:41:27) $ ^Iquanah@ldap-uat00.stanford.edu:/usr/local/build/openldap-2.3.28/servers/slapd so I'd say that when log purge is run, it resets the contextCSN in the accesslog DB to the time at which slapd last started... --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4734) Segmentation fault
by hyc＠symas.com 06 Nov '06

06 Nov '06

Christopher Moore wrote: >> This trace indicates that an attribute in the given entry had NULL for >> its AttributeDescription, which is pretty much a "this-can't-happen" >> situation. It would probably be useful to look at the contents of the >> Entry e in frame 2, and all of its attributes. How was this database >> created, how was the entry created? >> > > I forgot to mention that I have just upgraded from Openldap 2.2.23 and the > database was created by open-xchange. > Here is entry e in frame 2. I hope this is what you are after: > (gdb) frame 2 > #2 0x0807e491 in test_filter (op=0x8265c88, e=0x8266140, f=0x40d3b14c) at > filterentry.c:797 > 797 for(a = attrs_find( e->e_attrs, desc ); > (gdb) print *e > $1 = {e_id = 16777216, e_name = {bv_len = 100, bv_val = 0x8265ef5 > "c=open-xchange,dc=org"}, > e_nname = {bv_len = 103, bv_val = 0x8265f5b "e"}, e_attrs = 0x8266168, > e_ocflags = 0, e_bv = { > bv_len = 585, bv_val = 0x8265ef0 "\202\001è\026dc=open-xchange,dc=org"}, > e_private = 0x8265e90} > (gdb) Apparently you are using the OpenLDAP 2.2 database files with OpenLDAP 2.3. This is not supported since the database format changed between 2.2 and 2.3; you have to export with 2.2 slapcat and import with 2.3 slapadd as described in the docs on upgrading. This ITS will be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

RE: (ITS#4734) Segmentation fault
by chris＠linuxepos.com 06 Nov '06

06 Nov '06

> chris(a)linuxepos.com wrote: > > > #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 > > 489 for ( a = sub->ad_type; a; a=a->sat_sup ) { > > (gdb) where > > #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 > > #1 0x0806952e in attrs_find (a=0x8266168, desc=0x81eafb0) at attr.c:347 > > #2 0x0807e491 in test_filter (op=0x8265c88, e=0x8266140, f=0x40d3b14c) > at > > filterentry.c:797 > > #3 0x080c83cf in bdb_search (op=0x8265c88, rs=0x40d3a8bc) at > search.c:853 > > #4 0x080632b9 in fe_op_search (op=0x8265c88, rs=0x40d3a8bc) at > search.c:355 > > #5 0x08062a44 in do_search (op=0x8265c88, rs=0x40d3a8bc) at > search.c:217 > > #6 0x08061218 in connection_operation (ctx=0x40d3a93c, arg_v=0x8265c88) > at > > connection.c:1307 > > #7 0x08133ff8 in ldap_int_thread_pool_wrapper (xpool=0x81f1558) at > tpool.c:478 > > #8 0x40263d70 in pthread_start_thread (arg=0x40d3abe0) at manager.c:301 > > #9 0x4038d4a7 in __clone () from /lib/libc.so.6 > > (gdb) > > This trace indicates that an attribute in the given entry had NULL for > its AttributeDescription, which is pretty much a "this-can't-happen" > situation. It would probably be useful to look at the contents of the > Entry e in frame 2, and all of its attributes. How was this database > created, how was the entry created? > I forgot to mention that I have just upgraded from Openldap 2.2.23 and the database was created by open-xchange. Here is entry e in frame 2. I hope this is what you are after: (gdb) frame 2 #2 0x0807e491 in test_filter (op=0x8265c88, e=0x8266140, f=0x40d3b14c) at filterentry.c:797 797 for(a = attrs_find( e->e_attrs, desc ); (gdb) print *e $1 = {e_id = 16777216, e_name = {bv_len = 100, bv_val = 0x8265ef5 "c=open-xchange,dc=org"}, e_nname = {bv_len = 103, bv_val = 0x8265f5b "e"}, e_attrs = 0x8266168, e_ocflags = 0, e_bv = { bv_len = 585, bv_val = 0x8265ef0 "\202\001è\026dc=open-xchange,dc=org"}, e_private = 0x8265e90} (gdb) _________________________________________________________________________________ Scanned by an Igaware Box - protecting computers from viruses, spam, spyware and other Internet junk. For more information visit http://www.igaware.com/security.html _________________________________________________________________________________

1 0

Re: (ITS#4735) configure choice of ODBC
by ando＠sys-net.it 06 Nov '06

06 Nov '06

rk(a)owen.sj.ca.us wrote: > Full_Name: R.K. Owen > Version: HEAD > OS: linux > URL: ftp://ftp.openldap.org/incoming/rkowen-061106.patch > Submission from: (NULL) (66.87.79.68) > > > When using the back-sql with the Oracle XE DB, the Oracle ODBC library > libsqora.so.10.1 was designed to be linked against the unixODBC interface > library instead of the iODBC interface library. This can be demonstrated by > using the unixODBC isql tool which will allow successful interactive querying > of the Oracle DB. However, when trying to start up the slapd daemon with 'slapd > -d 1' the daemon will quit with an error claiming: > Message: [iODBC][Driver Manager] > /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib/libsqora.so.10.1: > undefined symbol: bcuMsgBoxError > > The cause for this is that the configure script will first search for iodbc, > then odbc, and thus cause slapd to be built against the iodbc library. > By adding the -with-odbc option the configure script will allow the > administrator to choose which library to use in a flexible way: > > --with-odbc=iodbc # current default (-liodbc) > --with-odbc=odbc # try -lodbc > --with-odbc=/usr/lib/libodbc.so.1 # link against the shared object library > > The changes have been made to the source configure.in file and uploaded as a > patch. > > The patch is not acceptable, since it requires to specify the desired OBDC support, which is counter-intuitive, as most of the RDBMS have drivers or allow to use drivers for both implementations of ODBC. However, your need is clear. I've designed a different fix, which requires to set --with-odbc to the preferred sequence of ODBCs to try (iodbc | unixodbc), while the default (auto) tries the original sequence. It is now committed to HEAD; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs