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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org