octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #56618] In dir.m, if internal call to lstat fa


From: Richard
Subject: [Octave-bug-tracker] [bug #56618] In dir.m, if internal call to lstat falis, an error is thrown unnecessarily
Date: Thu, 11 Jul 2019 21:38:31 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0

URL:
  <https://savannah.gnu.org/bugs/?56618>

                 Summary: In dir.m, if internal call to lstat falis, an error
is thrown unnecessarily 
                 Project: GNU Octave
            Submitted by: crobar
            Submitted on: Fri 12 Jul 2019 01:38:29 AM UTC
                Category: Octave Function
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Regression
                  Status: None
             Assigned to: None
         Originator Name: Richard Crozier
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 5.1.0
        Operating System: Any

    _______________________________________________________

Details:

This is a very hard to reproduce bug, but I think the problem should be clear
enough.

When calling dir.m, internally lstat is called to get info on files. Early in
dir.m this info structure is initialized like so:


  info = struct (zeros (0, 1),
           {"name", "folder" "date", "bytes", "isdir", "datenum",
"statinfo"});


There is a call to lstat at line 124. If this is successful, this structure is
populated, including the info.datenum field.

Now, if the call to lstat fails at line 124, there is an if statement which
tests for an error, and if there was an error, a warning is issued and the
structure is never populated, so info.datenum is still empty.

After this, however, outside the if statement there is the following:


## A lot of gymnastics in order to call datenum just once.  2x speed up.
    dvec = [info.datenum]([[1:6:end]', [2:6:end]', [3:6:end]', ...
                           [4:6:end]', [5:6:end]', [6:6:end]']);
    dnum = datenum (dvec);
    ctmp = mat2cell (dnum, ones (nf,1), 1);


So the still empty info.datenum field is attempted to be used, but results in
dvec being empty, dnum being empty, and ultimately you get an error from
mat2cell like so:


warning: called from
    dir at line 126 column 9
    setfilesemaphore at line 94 column 23
    loadslaveparams at line 69 column 9
    startmulticoreslave2 at line 273 column 90
error: mat2cell: mismatch on dimension 1 (0 != 1)
error: called from
    dir at line 159 column 10
    setfilesemaphore at line 94 column 23
    loadslaveparams at line 69 column 9
    startmulticoreslave2 at line 273 column 90


At the very least this is a bug due to incompatibility with Matlab, but I
think this is a straight out bug!

I'm pretty sure this used to work fine, so I have labelled it as a regression.
I suspect someone has done the gymnastics in the interim. Probably this could
just be reverted to the pre 2X speedup version mentioned in the comment.




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?56618>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]