make check fails for kerberos 1.4.2 on Slackware Linux 10.2. Please help

hairydamon@hotmail.com hairydamon at hotmail.com
Wed Oct 12 06:28:47 EDT 2005


Hi

I'm not going to be any help but I've noticed that it also fails in
slackware 10.1 same place and error (when doing the make checks).
Interestingly other MIT kerberos implementations fail at the same place
in slackware 10.1 (10.2 as well no doubt) - I've tried 1.4, 1.3.3 and
1.3 and they compile but fail during the checks. I'm guessing there
must be something about the compiler/tools/library in slackware 10.x
that doesn't like MIT Kerberos - unless someone from another distro has
noticed it does not work for them either :-)

If you look in that /root/krb5-1.4.2/src/util/db2/test directory you'll
find the test program ./dbtest and  the files it uses as data for the
test: t1,t2 and t3. The t1 file is based on the first 200 entries of
the word list from the dictionary (/usr/share/dictionary/words).

The t2 file is a command file that is used to generate  test database
file - it has commands to add data and keys (based on the dictionary
words) and retrieve  a particular keyed piece of data (there are other
commands as well but they are not particularly used).

The t3 file is the result of running the ./dbtest command and if it
works should be the same as the original (./t1) wordlist data file.

The dbtest command appears to only fail when running hash tests (the
btree tests appear to work). From what I can find out - I've only
experimented for a few hours is:

1) The first command set from the ./t2 (to store a key/data pair and
then retrieve it) always fails with a "get failed, no such key" error,
no matter what the data/key pair actually are.
2) I have not figured out if the hash function does not like lines over
8 characters long i.e. it truncates them to 8 so confuses longer words
with the same first 8 characters.....or if the hash function does not
like any word that shares the same root e.g. "abandon" and
"abandonment". Suspiciously there is a dictionary file in the
src/util/db2/test directory (which the script will use if it can find
no other) that seems to be all 8 character long words!
3) It does not appear to fail consistently - in my examples (below) I'm
only using a few words but in the full 200 words there are plenty of
instances where it has longs words (that share the same first 8
characters) but the dbtest routine does not complain about them all.

BTW, my slackware 10.1 is running a 2.6.11 kernel with gcc-3.3.4.


Here's some examples:

If my t2 file contains the following lines:

-------------------------------> snip
<-------------------------------------------------
p
kaback
daback
g
kaback
p
kabaft
dabaft
g
kabaft
p
kabandon
dabandon
g
kabandon
p
kabandoned
dabandoned
g
kabandoned
------------------------------------------> snip
<---------------------------------------------------

The command "./dbtest hash t2" fails with the following errors:

5: aback: get failed, no such key
abaft
15: abandon: get failed, no such key
abandoned


If I add some extra lines to the start of the ./t2 file to simply store
(not retrieve) some data. For example add the lines:

------------------------------------------> snip
<---------------------------------------------------
p
kzzzzzz
dzzzzzz
------------------------------------------> snip
<---------------------------------------------------

(but it could be any key/data information)

Then the command fails with:

aback
abaft
18: abandon: get failed, no such key
abandoned


If I delete the lines for "abandon" then I get no failures from the
command. However, if I add an entry for "abafts" to change the file to:

------------------------------------------> snip
<---------------------------------------------------
p
kzzzzzz
dzzzzzz
p
kaback
daback
g
kaback
p
kabaft
dabaft
g
kabaft
p
kabafts
dabafts
g
kabafts
p
kabandon
dabandon
g
kabandon
p
kabandoned
dabandoned
g
kabandoned
------------------------------------------> snip
<---------------------------------------------------

The command failure becomes:

aback
abaft
18: abafts: get failed, no such key
abandon
abandoned

For some reason it has now stopped complaining about not being able to
find a key for "abandon"

If I move the entry for "abafts" to the end of the file the failure
suddenly returns to moaning about "abandon" and stops complain about
abafts:

aback
abaft
18: abandon: get failed, no such key
abandoned
abafts

If I move "abandon" to the end of the file now so it becomes:

------------------------------------------> snip
<---------------------------------------------------
p
kzzzzzz
dzzzzzz
p
kaback
daback
g
kaback
p
kabaft
dabaft
g
kabaft
p
kabandoned
dabandoned
g
kabandoned
p
kabafts
dabafts
g
kabafts
p
kabandon
dabandon
g
kabandon
------------------------------------------> snip
<---------------------------------------------------

It will return to moaning about abafts:

aback
abaft
abandoned
23: abafts: get failed, no such key
abandon


Somehow ordering is important in the command file. I'm sure there will
be someone who understands hashing algorithms and how this little test
program works and will simply say "HAH! Fool does he not see the
problem - it is *so* obvious?!?" but I don't know what's up with it.

I cannot decide if the problems  are because the test routines are
simply faulty and therefore the actual install of MIT Kerberos is
actually sound or if there is some sort of fundamental problem with the
Kerberos install.

Either way I notice that Heimdal 0.7.1 compiles on Slackware 10.1 (and
probably 10.2) and runs all it's self checks without hitch - big
question is if everything else in the universe will compile against
Heimdal.



More information about the Kerberos mailing list