Running 'make check' hangs for ever

Greg Hudson ghudson at mit.edu
Wed Dec 30 18:08:50 EST 2015


On 12/30/2015 04:28 PM, Isaac Boukris wrote:
> [pid 21891] fcntl64(6</home/admin/git/krb5/src/lib/krb5/ccache/testdir/db.kadm5.lock>,
> F_OFD_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0,
> l_len=-5230051357888610304}) = -1 EINVAL (Invalid argument)
> [pid 21891] fcntl64(6</home/admin/git/krb5/src/lib/krb5/ccache/testdir/db.kadm5.lock>,
> F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}

Unfortunately, I can't really tell what's going on.  In ofdlock(), we
pass the same struct flock pointer to both fcntl() invocations when we
fall back to F_SETLKW, so I don't know why the first invocation is
reported a garbage l_len.  I also don't know why the second invocation
is blocking; did the first invocation somehow obtain a lock despite
returning EINVAL?  I can't find any search results about a known kernel
or glibc bug which might explain this odd behavior.

> PYTHONPATH=../../util VALGRIND="" python ./t_gss_sample.py
> *** Failure: /home/admin/git/krb5/src/appl/gss-sample/gss-client
> failed with code 1.

There should have been some additional messages explaining how to get
more information from a failing Python test; that information (and
perhaps more) is needed to figure out why this is failing for you.


More information about the Kerberos mailing list