bugGNU Octave - Bugs: bug #58070, [octave forge] (symbolic) doesn't...

 
 

bug #58070: [octave forge] (symbolic) doesn't close Python subprocess on "clear all"

Submitter:  None
Submitted:  Sat 28 Mar 2020 06:30:07 PM UTC
   
 
Category:  Octave Package Severity:  1 - Wish
Priority:  3 - Low Item Group:  Performance
Status:  Confirmed Assigned to:  None
Originator Name:  gs Originator Email:  -email is unavailable-
Open/Closed:  * Open Release:  * dev
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 08 May 2020 10:05:54 PM UTC, comment #10: 

I don't have a github account. So I hope it is ok to comment here.
If you'd like the cleanup to "return" something, you could use a local function where variables share scope.
With the attached example, I see the following:

>> test_cleanup (true)
ans =  1
>> test_cleanup (false)
ans =  2


I tried with Octave 5.2. Not sure if other versions behaved the same.

(file #49045)

Markus Mützel <mmuetzel>
Group administrator
Fri 08 May 2020 07:38:17 PM UTC, comment #9: 
Mike Miller <mtmiller>
Group Member
Tue 31 Mar 2020 06:32:25 AM UTC, comment #8: 

Another possible solution - if you don't want the subprocess to be cleaned up on "clear all" - might be to mlock the function with the persistent variables.

Markus Mützel <mmuetzel>
Group administrator
Mon 30 Mar 2020 05:09:25 PM UTC, comment #7: 

Very good suggestion, I'll try that, thanks.

Mike Miller <mtmiller>
Group Member
Mon 30 Mar 2020 04:55:41 PM UTC, comment #6: 

Re comment #2: Maybe you could use a persistent onCleanup object that cleans up the subprocess?

Markus Mützel <mmuetzel>
Group administrator
Sat 28 Mar 2020 08:20:48 PM UTC, comment #5: 


comment #4:

> This bug report seems accurate to me in current versions of Octave. Basically, the default Python interface for the symbolic package uses popen2, and it keeps track of the open subprocess with persistent variables.
>
> If the user uses the command 'sympref reset', then the subprocess is cleaned up properly using 'fclose' and 'waitpid'. So there is no bug in this case, everything is cleaned up properly.
>
> But if the user uses 'clear all', or possibly 'clear functions', then the persistent state of the package is reset without properly closing the pipe and reaping the child process. I don't know if there's a way to handle that case. Patches would be welcome.



I use 'clear all' in the beginning of my script.

Anonymous
Sat 28 Mar 2020 08:11:57 PM UTC, comment #4: 

This bug report seems accurate to me in current versions of Octave. Basically, the default Python interface for the symbolic package uses popen2, and it keeps track of the open subprocess with persistent variables.

If the user uses the command 'sympref reset', then the subprocess is cleaned up properly using 'fclose' and 'waitpid'. So there is no bug in this case, everything is cleaned up properly.

But if the user uses 'clear all', or possibly 'clear functions', then the persistent state of the package is reset without properly closing the pipe and reaping the child process. I don't know if there's a way to handle that case. Patches would be welcome.

Mike Miller <mtmiller>
Group Member
Sat 28 Mar 2020 06:34:57 PM UTC, comment #3: 

possibly interesting lines of code:



fun_abs=eval(["function_handle(abs(tf_sym),'vars'," variable_order ")"]);





eval(["tf_sym_fitted=subs(tf_sym_s," fitted_variables ",vpa(c));"] )

Anonymous
Sat 28 Mar 2020 06:33:34 PM UTC, comment #2: 

Version 4.2.2 is ancient and no longer supported.  If you can reproduce this with current stable version of 5.2.0 then it could be investigated.

Changing category to Octave Forge Package since any change would need to be in the Symbolic package, rather than core Octave.

Rik <rik5>
Group administrator
Sat 28 Mar 2020 06:32:52 PM UTC, comment #1: 

test

original submission:

> Symbolic v2.8.0
>
> When running scripts the subprocess calls aren't closed so this uses a lot of memory. Restarting Octave closes all processes.
>
> I would call it normal usage of symbolic. I have a script which I am running many times as I am testing it.
>
> See the pic.

Anonymous
Sat 28 Mar 2020 06:30:07 PM UTC, original submission:  

Symbolic v2.8.0

When running scripts the subprocess calls aren't closed so this uses a lot of memory. Restarting Octave closes all processes.

I would call it normal usage of symbolic. I have a script which I am running many times as I am testing it.

See the pic.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #49045:  test_cleanup.m added by mmuetzel (196B - text/plain)
file #48694:  symbolic_bug.png added by None (79KiB - image/png)

 

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)
  •  

    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 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-05-08 mmuetzel Attached File- Added test_cleanup.m, #49045
    2020-03-28 mtmiller Summary[octave forge] (symbolic) doesn't close subprocess calls [octave forge] (symbolic) doesn't close Python subprocess on "clear all"
    2020-03-28 mtmiller Severity3 - Normal 1 - Wish
        Priority5 - Normal 3 - Low
        Item GroupNone Performance
        StatusNeed Info Confirmed
        Release4.2.2 dev
    2020-03-28 mtmiller SummarySymbolic doesn't close subprocess calls [octave forge] (symbolic) doesn't close subprocess calls
    2020-03-28 rik5 Carbon-CopyRemoved 72865 -
    2020-03-28 rik5 CategoryNone Octave Package
        StatusNone Need Info
    2020-03-28 None Attached File- Added symbolic_bug.png, #48694

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code