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