[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#3773) hdb ADD failure



Thanks for the report. This bug was caused by the conversion of the 
back-hdb code to be byte-order independent, missed some length checks in 
a couple places. Now fixed in HEAD.

richton@nbcs.rutgers.edu wrote:
> Full_Name: Aaron Richton
> Version: RE23 CVS
> OS: Solaris 9
> URL: 
> Submission from: (NULL) (67.80.49.181)
>
>
> RE23 CVS. Go into tests and ./run -b hdb -k test002
>
> Put the following into a breakme.ldif file:
>
> dn: cn=adm,ou=Groups,dc=example,dc=com
> objectClass: posixGroup
> objectClass: top
> cn: adm
> gidNumber: 1
>
> dn: cn=admin2,ou=Groups,dc=example,dc=com
> objectClass: posixGroup
> objectClass: top
> cn: admin2
> gidNumber: 2
>
> dn: cn=admin,ou=Groups,dc=example,dc=com
> objectClass: posixGroup
> objectClass: top
> cn: admin
> gidNumber: 3
>
>
> Run ldapadd -x -H "ldap://localhost:9011/"; -D "cn=Manager,dc=example,dc=com" -w
> secret -f breakme.ldif
>
> Disaster!
>
> adding new entry "cn=admin,ou=Groups,dc=example,dc=com"
> ldap_add: Already exists (68)
>
> but that's clearly wrong.
>
>
> Curiously enough, if you make the LDIF ordered "adm admin admin2" it works.
> Indexing/stemming? (note: hdb specific. that ldif works with bdb.)
>
>
>   


-- 
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support