Skip to content

Don't check directory atime in lstat_stat_variation10.phpt test #5553

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

alexdowad
Copy link
Contributor

This is a funny one. I discovered that lstat_stat_variation10.phpt was failing every now and again when the PHP test suite was run on my dev PC. The output from the failing test showed that the atime (access time) of the directory created in the test was changing between these lines:

$old_stat = stat($dirname);
clearstatcache();
sleep(1);
var_dump( is_dir($dirname) );
$new_stat = stat($dirname);

Could is_dir() be accessing the directory and changing the atime? strace showed that is_dir was only issuing a single stat() syscall. Could stat() change the atime? No, no, that would just be perverse. Nobody would be stupid enough to implement the kernel in that way.

Checked the kernel source, found that the function called when atime needs to be updated appears to be touch_atime(). Broke out the BCC kernel tracing tools and ran this one while running the flaky test case in a loop:

sudo trace -I<kernel src dir>/include/linux/path.h -I<same>/include/linux/dcache.h 'touch_atime(struct path *path) "%s", path->dentry->d_name.name'

Inspecting the results showed that something called "git_thread" was occcasionally updating
the atime on the directory in question!! What on earth...???

The PID shown by trace revealed that this was a background thread for Sublime Text 3.
Sublime now has git integration and shows when there are untracked or modified files. It
seems that it uses a background thread to regularly scan the project directory and look
for new and modified files. This was causing the atime to change.

Even though other developers may not be running ST3, there are any number of reasons why
a background process might recurse through various directories and could cause the atime
to change unexpectedly. Therefore, update the test case so it doesn't fail in such cases.

This is a funny one. I discovered that lstat_stat_variation10.phpt was failing every
now and again when the PHP test suite was run on my dev PC. The output from the failing
test showed that the atime (access time) of the directory created in the test was changing
between these lines:

    $old_stat = stat($dirname);
    clearstatcache();
    sleep(1);
    var_dump( is_dir($dirname) );
    $new_stat = stat($dirname);

Could is_dir() be accessing the directory and changing the atime? strace showed that is_dir
was only issuing a single stat() syscall. Could stat() change the atime? No, no, that would
just be perverse. Nobody would be stupid enough to implement the kernel in that way.

Checked the kernel source, found that the function called when atime needs to be updated
appears to be touch_atime(). Broke out the BCC kernel tracing tools and ran this one
while running the flaky test case in a loop:

    sudo trace -I<kernel src dir>/include/linux/path.h -I<same>/include/linux/dcache.h 'touch_atime(struct path *path) "%s", path->dentry->d_name.name'

Inspecting the results showed that something called "git_thread" was occcasionally updating
the atime on the directory in question!! What on earth...???

The PID shown by trace revealed that this was a background thread for Sublime Text 3.
Sublime now has git integration and shows when there are untracked or modified files. It
seems that it uses a background thread to regularly scan the project directory and look
for new and modified files. This was causing the atime to change.

Even though other developers may not be running ST3, there are any number of reasons why
a background process might recurse through various directories and could cause the atime
to change unexpectedly. Therefore, update the test case so it doesn't fail in such cases.
@php-pulls php-pulls closed this in 1e3196a May 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants