bugGNU Octave - Bugs: bug #49197, xmlread in IO-pkg - open file...

 
 

bug #49197: xmlread in IO-pkg - open file handles

Submitted by:  None
Submitted on:  Tue 27 Sep 2016 09:31:22 AM UTC  
 
Category: Octave Forge PackageSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Performance
Status: FixedAssigned to: Philip Nienhuis <philipnienhuis>
Originator Name: TobiOriginator Email: -unavailable-
Open/Closed: ClosedRelease: other
Operating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Mon 03 Oct 2016 08:14:04 PM UTC, comment #8:

@Pantxo: Thanks for the cset, pushed here:
http://hg.code.sf.net/p/octave/io/rev/c6f62ab6e7b1

In addition I pushed similar fixes for the POI and OXS interfaces.

Closing report.

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Wed 28 Sep 2016 02:58:23 PM UTC, comment #7:

@OP:
Well I meant Octave file handles opened with fopen(), not so much Java file handles.
Those Octave handles can be (should be) closed explicitly with fclose() but many functions don't do that in case of errors, notably in test blocks - some core Octave functions included.

[Slightly OT]
It can get worse though. In the UNO interface for spreadsheet I/O (invoking LibreOffice behind the scenes) open file connections left dangling when the function invoking them crashes will simply make it impossible to close Octave gracefully. First the hidden soffice.bin processes (=LibreOffice) will have to be killed manually, only then Octave can be exited.
The relevant UNO spreadsheet I/O scripts include unwind_protect / try-catch blocks at the relevant places to at least make sure Octave can be exited.

@Pantxo, thank you very much, I'll have a look at your patch asap.

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Wed 28 Sep 2016 07:42:08 AM UTC, comment #6:

"At the OP: I think you're mixing up xmlread.m and xmlwrite.m :-)"

oh yes.. my bad.

"But I know that Octave file handles not explicitly closed in functions remain open until closure of Octave itself."

yes, this is exactly my problem. I can't delete my files before i close octave or delete the handle.

Anonymous
Tue 27 Sep 2016 09:55:56 PM UTC, comment #5:

I attached a patch. The unwind_protect enclosing try/catch blocks looks hacky but as I don't know a proper way to handle java exceptions I can't think of a better method. I used "ls -l /proc/OCTAVEPID/fd" to check the file was now properly closed.

(file #38611)

Pantxo Diribarne <pantxo>
Project Member
Tue 27 Sep 2016 06:52:56 PM UTC, comment #4:

At the OP: I think you're mixing up xmlread.m and xmlwrite.m :-)

Pantxo, if you could supply a cset, please do.
I'll have a check of the spreadsheet interfaces where similar constructs live.

BTW I figured that when an Octave function is finished, Octave clears all variables and objects created in the function, right?
That should also apply to Java objects.

But I know that Octave file handles not explicitly closed in functions remain open until closure of Octave itself.

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Tue 27 Sep 2016 05:50:59 PM UTC, comment #3:

I agree that the files stream should be closed, so simply applying the Tobi's solution is the way to go. We should probably also enclose all relevant code in an unwind_protect block to ensure the file stream is closed even if an error occurs. I can prepare a cset if needed.

Pantxo Diribarne <pantxo>
Project Member
Tue 27 Sep 2016 04:16:47 PM UTC, comment #2:

Adding Pantxo in turn (it's his code).

(release -> other (it's not core Octave)

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Tue 27 Sep 2016 11:15:18 AM UTC, comment #1:

Added package maintainer.

Kai Torben Ohlhus <siko1056>
Project Member
Tue 27 Sep 2016 09:31:22 AM UTC, original submission:

in xmlread.m line 91:
jos = javaObject ("java.io.FileOutputStream", jfile);

opens a file handle, but this handle will never close.

under line 123 in xmlrad.m, i would add
jos.close();

I'm not a javaexpert, but it works fine for my application.
I checked the open file handles with "Process Explorer".

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #38611:  close_os.patch added by pantxo (3KiB - text/x-diff)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by pantxo (Posted a comment)
  • -unavailable- added by philipnienhuis
  • -unavailable- added by siko1056 (Posted a comment)
  • -unavailable- added by siko1056 (Package maintainer.)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 12 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 03 Oct 2016 08:14:04 PM UTCphilipnienhuisStatusIn Progress=>Fixed
      Open/ClosedOpen=>Closed
    Mon 03 Oct 2016 05:02:21 PM UTCphilipnienhuisStatusConfirmed=>In Progress
      Assigned toNone=>philipnienhuis
    Tue 27 Sep 2016 09:55:56 PM UTCpantxoAttached File-=>Added close_os.patch, #38611
    Tue 27 Sep 2016 06:53:03 PM UTCphilipnienhuisOperating SystemMicrosoft Windows=>Any
    Tue 27 Sep 2016 05:50:59 PM UTCpantxoStatusNone=>Confirmed
    Tue 27 Sep 2016 04:16:47 PM UTCphilipnienhuisAssigned tophilipnienhuis=>None
      Release4.0.3=>other
      Carbon-Copy-=>Added pantxo
    Tue 27 Sep 2016 11:15:18 AM UTCsiko1056Assigned toNone=>philipnienhuis
      Carbon-Copy-=>Added philipnienhuis

    Back to the top


    Powered by Savane 3.1-cleanup1