Hello I am tracking a rare bug with perfused, where an existing file is reported as unexistent. It happens after a few hours of usage, and it happens only once: if I retry accessing the file, I am successful.
Adding traces in perfused while performing ktrace on the calling process, I am now confident that perfused is not the component that raises the ENOENT. Here is what I get in the ktrace: 14085 1 cc1 1326421055.211110998 CALL close(4) 14085 1 cc1 1326421055.214918302 RET close 0 14085 1 cc1 1326421055.215025195 CALL open(0xbb960a90,4,0x1b6) 14085 1 cc1 1326421055.215031533 NAMI "/gfs/manu/netbsd/usr/src/sys/sys/featuretest.h" 14085 1 cc1 1326421055.216282844 RET open -1 errno 2 No such file or directory In the PUFFS trace I collect in perfused, this open() only causes LOOKUPs up to /manu/netbsd/usr, all successful, then nothing. 1326421055.215229913 LOOKUP "/" cn = "manu" error = 0 1326421055.215396312 LOOKUP "/manu" cn = "netbsd" error = 0 1326421055.215749931 LOOKUP "/manu/netbsd" cn = "usr" error = 0 That means the ENOENT is decided by the kernel on its own, perfused does not produce it. The question is where can this come from? There are two ENOENT occurences in sys/fs/puffs. One can happen at mount time, and I ruled out the other in puffsop_flush() by adding a printf() that never show up when the bug strikes. There are also ENOENT in sys/dev/putter/putter.c, but they all have a printf() that I would have seen, therefore it cannot come from there. Hence I come to the conclusion that it may come from sys/kern/vfs_lookup.c, but it is very unlikely that there is a bug there that went unnoticed for other filesystems. Anyone would have an idea of what can possibly be going on? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org