bugGNU Octave - Bugs: bug #60993, Environment became unstable and...

 
 

bug #60993: Environment became unstable and does not recognize basic commands

Submitter:  None
Submitted:  Fri 30 Jul 2021 05:51:04 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Missed Error or Warning
Status:  Wont Fix Assigned to:  None
Originator Name:  Alex Mokhnatyuk Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 5.1.0
Operating System:  * Microsoft Windows Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 03 Aug 2021 04:22:25 PM UTC, comment #4: 

A user might have a good reason to leave a file handle open on exiting a function.
If Octave would close those handles automagically that would be very surprising (to me at least).

If you are worried about that, you could write a wrapper that checks how many files are already open before opening a new one. That could look similar to this:

function [varargout] = fopen_check (varargin)
max_num_open_files = 100;

if (numel (fopen ('all')) > max_num_open_files)
  ## do something...
  ## e.g. emit a warning or an error, or close all open files and continue if you think you can safely do that
endif

[varargout{1:nargout}] = fopen (varargin{:});

endfunction


Other than that, I often use a construct like the following to make sure that open file handles are closed when I know they shouldn't leave the scope of the current function:

fid = fopen ('t.tst', 'w');
fid_guard = onCleanup (@() fclose(fid));


Or `unwind_protect` blocks.

Anyway, closing handles is the responsibility of the user. There are multiple ways to do that in Octave.

Closing report as won't fix.

Markus Mützel <mmuetzel>
Group administrator
Tue 03 Aug 2021 12:54:06 AM UTC, comment #3: 

There's a workaround to protect you against resource exhaustion if you think you might forget to close files, but you'll have to port it from Linux to Windows yourself. Type the following line in a new Octave session, or in a script that opens lots of files:


system(sprintf("prlimit --pid %d --nofile=100", getpid()));
# here 100 is the maximum number of files that you want to allow Octave to open. Change it as you need.


If Windows doesn't have prlimit, you'll have to find out how to set resource limits in Windows.

But this is not an Octave bug or a limitation in any case. Resource limits can be broken with any programming language, usually leading to a frozen system.

Anonymous
Sat 31 Jul 2021 09:27:14 PM UTC, comment #2: 

Agreed, that it is programmers responsibility to program correctly, although errors and warnings exist to help of achieving this.

I think there is a way to handle this issue regardless of OS.   The algorithm is that each function should do housekeeping when it return value(s). This housekeeping should check if there are opened file(s), resource or memory inside that function, and close them if resource handler is not in the list of return arguments (or class members if that function is a class method). Warning (or error) should be displayed when fail to close file or resource.
Otherwise, as you said we have resource exhaustion or memory leaks.

Anonymous
Fri 30 Jul 2021 08:40:35 PM UTC, comment #1: 

Generally it's the programmer's responsibility to close every file that is opened, otherwise there will be a resource leak. This is particularly a problem inside loops and function calls as you've found out.

There's no easy way for Octave to tell that it has run out of file handles because that is very OS-specific. You will likely experience unresponsiveness and freezes for any sort of resource exhaustion like files, memory, or inodes.

You can try calling fclose("all") which will close all files opened in the current Octave session. Other than that there's not much that can be done here other than close files manually.

Anonymous
Fri 30 Jul 2021 05:51:04 PM UTC, original submission:  

Condition: When open too many files for reading inside function
Behavior: environment does not find and recognize basic commands like save(), plot() after function finishes

It was tested at 1264 files opened for reading.
See attached files.

4 files attached:
ren_read1.m - procedure executed;

function dirstruct40_ fills cell array with filenames to be opened (before running it should be edited to look for existing files on certain machine);

function readList1_ represent cycle to open and read files;

function readPos2_ opening and parsing file (needs to be edited to be able open existing files on certain machine, parsing can be skipped or modified)

If comment line 23 (fclose(fid);) in this function readPos2_   then environment became unstable and unresponsive after function completed.

No error or warning is displayed showing that opened files were not closed.
Actually it make sense that all these files which were opened to be closed automatically when function finishes, or otherwise show error if fail to do so.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #51709:  run_read1.m added by None (120B - application/octet-stream)
file #51710:  readList1_.m added by None (464B - application/octet-stream)
file #51711:  dirstruct40_.m added by None (895B - application/octet-stream)
file #51712:  readPos2.m added by None (865B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-08-03 mmuetzel StatusNone Wont Fix
        Open/ClosedOpen Closed
    2021-07-30 None Attached File- Added run_read1.m, #51709
        Attached File- Added readList1_.m, #51710
        Attached File- Added dirstruct40_.m, #51711
        Attached File- Added readPos2.m, #51712

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code