[Pkg-octave-devel] Bug#550823: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink())

[Sébastien Villemot]

Hi,

I think I found the culprit for what I thought was a race condition in
Octave.

The problem has to do with the way Octave 3.2 updates its load-path: it
only updates its cache of the current directory if the modification time
of the directory changes (see load_path::dir_info::update() in
src/load-path.cc).

The problem is that modification times (as returned by stat()) are
expressed in seconds; so when two changes of the directory occur within
the same second, Octave can miss the second one.

Here is an example script which demonstrates this:

---------------------------
system("echo 1+1 > foo.m");
delete("foo.m");
try
    foo;
catch
end
system("echo 1+1 > foo.m");
foo;
---------------------------

The first two lines update the modification time of the directory (file
creation then deletion). Then the call to script "foo" in the try/catch
block will obviously fail, and by the way it will update the load-path
cache.

Then it creates the file "foo.m", and tries to launch that script.

Two cases are possible:

* the creation of "foo.m" occurred within the same second than its
deletion a few lines above. The modification time of the directory is
not updated. Then on the second call to script "foo", Octave will not
update its load-path cache, and fail with an undefined symbol error

* the creation of "foo.m" occurred in a different second: Octave updates
its load-path, and everything goes well.

So on my machine this script randomly fails, depending on when it was
launched and how fast Octave performed the file system operations.

In my opinion this invalidates the idea of updating load-path cache
based on modification times.

The only workaround for the moment is to insert sleep() calls at the
right place to enforce changes in the modification times. I am applying
such a workaround for Dynare, since otherwise this bug makes it randomly
fail.

Best,

-- 
Sébastien Villemot
Dynare developer
Member of Debian Octave Group