[Octave-bug-tracker] [bug #53539] Timestamps in filebrowser continuously change under heavy load

[Lars Kindermann]

Follow-up Comment #3, bug #53539 (project octave):

I have localized the probable source of the problem.

It is indeed caused by massive use of datenum() in my scripts. Here is the
minimum code that triggers the error 100% reproducible when there is a large
amount of big datafiles to be parsed:


for fil = dir("*.dat")'
  disp (fil.name)
  FID = fopen (fil.name, 'r');
  f = textscan (FID, '%s %*[^\n]');
  fclose (FID);
  ts = datenum (f{1}, 'yyyymmdd-HHMMSS')
endfor



There seems to be a race condition between the interpreter and the gui caused
by code in datevec.m:



function [found, y, m, d, h, mi, s] = __date_str2vec__ (ds, p, f, rY, ry, fy,
fm, fd, fh, fmi, fs)

  ## Local time zone is irrelevant, and potentially dangerous, when using
  ## strptime to simply convert a string into a broken down struct tm.
  ## Set and restore TZ so time is parsed exactly as-is. See bug #36954.
  TZ_orig = getenv ("TZ");
  unwind_protect
    setenv ("TZ", "UTC0");

...
 some code that uses strptime()
...

  unwind_protect_cleanup
    if (isempty (TZ_orig))
      unsetenv ("TZ");
    else
      setenv ("TZ", TZ_orig);
    endif
  end_unwind_protect



When the gui checks the timestamp of files, either of those open in the editor
or those displayed in the filebrowser while the TZ environment variable is
temporarily modified by that code, it assumes the files have changed and
redraws the timestamps, which are exactly off by the local TZ then.

The unwind_protect assures that TZ is definitely reset but does not protect
against concurrent code.   


@Mike: You can turn on the display of filetimes in the filebrowser widget by
right-clicking the header line... 

The zero size octave-workspace is not the cause, but for some reason it
increased the probability of the ocurrence for me.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53539>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/