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.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
