<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>(Email is better than IRC if that's OK - I don't know this code that well so it takes me a while).</div><div><br></div><div>Thanks, that's definitely interesting and not what I expected. I thought every call sequence r347205 changed the behavior of would have resulted in two calls to getStatValue().</div><div>I guess the "pch"/"main" output is printed before the corresponding lines in run.sh? Weird that we don't get any output from building the PCH, but I don't know well how PCH builds work.</div><div><br></div><div>> It looks like FS->getCurrentWorkingDirectory() is set yet FileSystemOpts.WorkingDir.empty() is also true. Is that expected?</div><div>I think so. The FileManager and the VFS each have their own concept of working directory, I guess for historical reasons.</div><div>Making use of the VFS one but not the FileManager one seems reasonable.</div><div><br></div><div>So the weirdness is that FileSystemStatCache::get() is returning true (i.e. file doesn't exist), when the file does exist.</div><div>Possibilities:</div><div>1) we're serving this result from the FileSystemStatCache (and maybe it's being poisoned in a PCH-related way somehow). Except as far as I can tell, FileSystemStatCache is always null (FileManager::setStateCache has no callers).</div><div>2) the FS.openFileForRead call failed (ultimately ::open, if FS is the real FS)</div><div>3) the OwnedFile->status() call failed (ultimately ::fstat)</div><div>4) I'm misreading the code somehow</div><div><br></div><div>Could you find out which of these is going on? Either running in a debugger or adding some similar printfs to FileSystemStatCache::get() should be doable.</div><div>I'm also going to try to work out how the patch could have affected this, but new vs correct much easier for me to compare than new vs old...</div></div></div></div>