Re: (ITS#3267) more modrdn problems

[ccontavalli@commedia.it]

ok, finally had some time to take a look at it...
  probably the problem has _nothing_ to do with modrdn,
sorry for the wrong information.

Enabling debug with slapadd:

=> hdb_tool_entry_put: id2entry_add failed: DB_KEYEXIST: 
	Key/data pair already exists (-30996)
=> hdb_tool_entry_put: txn_aborted! DB_KEYEXIST: 
	Key/data pair already exists (-30996)

by looking to bdb_id2entry_add, it seems like the generated
e->e_id is not always uniq. Probably the bug lies somewhere into
bdb_next_id. I did some minor playing with those functions, by
adding some debugging messages to print the e_id out on console.

  The typical situation is like the following:

[...]
added: "xxxx" (000013c1)
added: "xxxx" (0000140f)
=> hdb_tool_entry_put: id2entry_add failed: DB_KEYEXIST: Key/data pair
   already exists (-30996 - 000013c4)
=> hdb_tool_entry_put: txn_aborted! DB_KEYEXIST: Key/data pair already
   exists (-30996)
slapadd: could not add entry dn="xxxxx" (line=85981): txn_aborted! 
  DB_KEYEXIST: Key/data pair already exists (-30996) (ffffffff)
added: "xxxx" (00001410)
added: "xxxx" (00001411)
[...]

(the xxxx represent dns I cannot disclose).
Note that e_id is 000013c4. If I backward look in the output, something
like:

[...]
added: "xxxx" (000013c0)
added: "xxxx" (000013c2)
added: "xxxx" (000013c4)
added: "xxxx" (000013c5)
added: "xxxx" (000013c6)
[...]

shows up. As you can see, there's a hole at 000013c3. bdb_next_id, 
probably has some sort of ``off-by-one'' when recycling id from 
leftover holes, and returns the value incremented by one, which 
is already in use. This same pattern repeats for all the entries
which slapcat fails to insert. (why holes are left at all?)

Note also that some other entries fail to insert due to dn2id_add
failing. Still need to track that down, but they could just be
two aspects of the same problem.

  This is quite a serious bug, since slapadd is either unusable,
or if the -c option is used some ``random'' entries are not 
entered into the database, even if a warning is printed.

  but ... hey ... am I the only one using the HDB backend?? I 
believe a bug like this should already have been noticed a long 
ago... I'm also trying to generate a .ldiff file that shows the 
given problem without disclosing any information regarding our 
users...

Cheers,
Carlo
  
-- 
  GPG Fingerprint: 2383 7B14 4D08 53A4 2C1A CA29 9E98 5431 1A68 6975
                        -------------
* UNIX is a Trademark of Bell Laboratories.
* * * * * THIS TERMINAL IS IN USE * * * * *