bugGNU Octave - Bugs: bug #39461, clear'ing a mex files doesn't...

 
 

bug #39461: clear'ing a mex files doesn't dlclose() it.

Submitter:  None
Submitted:  Wed 10 Jul 2013 09:03:25 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Duplicate Assigned to:  None
Originator Name:  Mario Kleiner Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.6.1
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 10 Jul 2013 11:33:54 PM UTC, comment #2: 

Ah, perfect, thanks! I have one mercurial checkout on one linux machine for testing the gui, but apparently haven't noticed the absence of this problem, as i'm using it only infrequently.

I don't know if you plan to do another 3.6.x release before 3.8, but if so it would be splendid if this specific fix could be easily backported into it.

Thanks,
-mario

Anonymous
Wed 10 Jul 2013 10:46:42 PM UTC, comment #1: 

This has already been fixed on the development branch of Octave.  You can either wait for the next major release (3.8) which is expected within 1-3 months or you can build from the development sources in Mercurial. 

If you're familiar with dlclose() my guess is building from source won't be too hard for you.  See http://www.gnu.org/software/octave/get-involved.html for instructions on getting the sources.  Next look at the file etc/HACKING for instructions on how to build from the tree.

Rik <rik5>
Group administrator
Wed 10 Jul 2013 09:03:25 PM UTC, original submission:  

Hi,

when i clear an octave oct function, the corresponding .oct shared library file gets dlclose()'ed by octaves loader. When i clear an octave mex function, the corresponding .mex shared library gets its mexAtExit() function called as expected, but dlclose() is not called on it. I checked this via setting a breakpoint on dlclose() with gdb attached to octave and looking at the stack trace.

The problem here is that if a mex file function is called again after a clear, the corresponding shared library won't get reloaded from the filesystem. This means that if the mex file was recompiled inbetween, changes won't apply, which makes development cumbersome. More importantly if the mex file has static variables defined, they won't get cleared to startup defaults, e.g., a

static bool firstTime = true;

will not get reinitialized properly.

This causes unexpected behaviour for my users and/or crashes of the mex file when calling it after a previous clear.

Thanks,
-mario

Anonymous

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jordigh (Updated the item)
  • -email is unavailable- added by rik5 (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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-07-11 jordigh StatusFixed Duplicate
        Dependencies- Depends on bugs #34861
    2013-07-10 rik5 StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code