2018-07-09 14:30 GMT+08:00 Amir Goldstein <amir73il@xxxxxxxxx>:
> I have no clue.
> Is the leaked lock and crash on the client or the server?
> If you can get an strace from the process that gets the Leaked message
> maybe it will give us a clue to the sort of file descriptor of the leaked
> file and how it was opened.
> Alternatively print the inode numbers and file types of flock calls to see
> where we have a mismatch.
>
> Thanks,
> Amir.
Both the leaked lock and crash are on the server.
I can emulate one of the lock failure case with a reproducer run along with
android building. The reproducer's behavior and result are very similar with
out/.lock generated by android build to control only one build process can
run on at the same time. In the first time (out/.lock is not exist),
flock works but a
"Leaked ..." message is supposed caused by it. After a round of build
completed, do a second build, the out/.lock is now failed to be locked.
The reproducer open and flock another file under out/ can reproduce the case.
Can this scenario help us to debug?
process 1: process 2:
$ ~/flock/a.out /mnt/n/out/mylock
flock succeed, press any key to continue...
$ cd /mnt/n && make -j12 # (build android)
close succeed
$ ~/flock/a.out /mnt/n/out/mylock
failed to lock file '/mnt/n/out/mylock': Resource temporarily unavailable
close succeed
reproducer:
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/file.h>
#include <errno.h>
#include <string.h>
int main(int argc, void **argv) {
char *filename=argv[1];
int fd = open(filename, O_RDWR|O_CREAT, 0666);
int flock_result = flock(fd, LOCK_EX | LOCK_NB);
int err;
if (flock_result != 0) {
printf("failed to lock file '%s': %s\n", filename, strerror(errno));
goto out;
}
printf("flock succeed, press any key to continue...\n");
getchar();
out:
err = close(fd);
if (err == 0)
printf("close succeed\n");
else
printf("failed to close %d: %s\n", fd, strerror(errno));
}
Thanks,
Eddie
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
