bugGNU Octave - Bugs: bug #56637, Access of a nested structure ->...

 
 

bug #56637: Access of a nested structure -> memory leak in mex function

Submitter:  Evangelos Rozos <vrozos>
Submitted:  Tue 16 Jul 2019 07:19:59 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Works For Me Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 5.1.0 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 17 Jul 2019 05:21:09 PM UTC, comment #8: 

In other words, we have a minimal example that doesn't show a memory leak. You have a complex example that does show a memory leak. At the moment, it seems most likely that the memory leak is in your code and not in Octave itself. As the reporter, we hope that you will put in some more effort to reduce your complex example to show a complete but minimal example that demonstrates the leak. Or perhaps by attempting to do so you will discover the source of the leak yourself. You might also try running your code under leak detection tools like LeakSanitizer or Valgrind.

Mike Miller <mtmiller>
Group Member
Wed 17 Jul 2019 03:44:01 PM UTC, comment #7: 

I'm also unable to duplicate the leak.  How pmxid used after it is given a value by the call to mxGetField?  What type of variable does it contain (numeric array, scalar, cell, ...)?

To fix the problem, we need to be able to reproduce it.  Can you provide a complete example that demonstrates the problem?  It doesn't have to be your original code, but it needs to show the problem.


John W. Eaton <jwe>
Group administrator
Wed 17 Jul 2019 03:15:07 PM UTC, comment #6: 

@Evangelos: It's fine to keep the code private.  Can you judge whether the test case from comment #4 is sufficiently similar to your usage?

Rik <rik5>
Group administrator
Wed 17 Jul 2019 06:38:41 AM UTC, comment #5: 

I cannot post publicly the code (it is m-files plus C code) that creates the leak. If someone wishes to have a closer look on this issue, I can send him the code confidentially.

comment #4:

> @Evangelos: Could you post some m-file code that can be used with the example.c that Mike posted?
>

Evangelos Rozos <vrozos>
Tue 16 Jul 2019 08:38:32 PM UTC, comment #4: 

@Evangelos: Could you post some m-file code that can be used with the example.c that Mike posted?

I tried this


movefile ('example.c', 'nestleak.c')
mex nestleak.c


and then


s.InsDmd.id = rand (1e6,1);

for i = 1:1e7
  nestleak (s);
endfor


I looked at memory usage for the process with


ps auxww | grep octave | grep 5.1.0


but I didn't see anything.  The first run or two the memory consumption goes up because the mex interface seems to be loaded.  But then it became stable.

Rik <rik5>
Group administrator
Tue 16 Jul 2019 05:44:22 PM UTC, comment #3: 

I am unable to reproduce a memory leak with the minimal example attached here. There does not seem to be a memory leak with the mxGetField function on a nested structure. Please take a closer look at your code and provide more information if you still think there is a bug here.

(file #47226)

Mike Miller <mtmiller>
Group Member
Tue 16 Jul 2019 09:59:59 AM UTC, comment #2: 


> Do you allocate memory for your pointers?


...
 mxArray* pmx1=NULL;
 mxArray* pmxid=NULL;
 pmx1= mxGetField(prhs[0], 0, "InsDmd");
 pmxid= mxGetField(pmx1, i, "id");        // <-- memory leak stops when commenting this out
...

In the code above:
- prhs[0] is a structure with name, say, Globals, allocated inside Octave and passed as argument to the mex function,
- InsDmd is an array of structures inside the structure Globals
- id is a member of the structure InsDmd[i].

Why there is a need to allocate memory? I just want to read the data (packed inside the structure Globals) that are passed from Octave prompt to the mex function.

Evangelos Rozos <vrozos>
Tue 16 Jul 2019 08:02:00 AM UTC, comment #1: 

There was a reply by George to this issue

> I think you're not allocating any memory to both pointers, hence the leak. You should use a function like Malloc() in the pointer declaration.
> Best regards,
> George


https://lists.gnu.org/archive/html/octave-maintainers/2019-07/msg00037.html

Do you allocate memory for your pointers?

Kai Torben Ohlhus <siko1056>
Group Member
Tue 16 Jul 2019 07:19:59 AM UTC, original submission:  

The access of a nested structure passed to a mex function seems to create memory leak.
Example code (snippet):
...
 mxArray* pmx1=NULL;
 mxArray* pmxid=NULL;
 pmx1= mxGetField(prhs[0], 0, "InsDmd");
 pmxid= mxGetField(pmx1, 0, "id");        // <-- memory leak stops when commenting this out
...

This problem has been witnessed in Octave 5.1.0/win64 and Octave 4.2.2/Linux (I believe it exists in every platform and recent Octave version). The same code does not create leak when compiled in MATLAB.

Apparently, the indicated line of code above does not create directly the leak, but somehow mixes up the memory management (a dynamic allocation somewhere else in the code is not freed by free() ). The leak is noticeable only after numerous calls of the mex function (estimated leak 7.6 MB/100000 calls).

Evangelos Rozos

Evangelos Rozos <vrozos>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #47226:  example.c added by mtmiller (347B - text/x-csrc)

 

Depends on the following items: None found

Digest:
   patch dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by vrozos (Submitted the item)
  • -email is unavailable- added by vrozos
  •  

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

    Date Changed by Updated Field Previous Value => Replaced by
    2019-07-25 rik5 Open/ClosedOpen Closed
    2019-07-16 mtmiller Attached File- Added example.c, #47226
        CategoryNone Interpreter
        StatusNeed Info Works For Me
    2019-07-16 mtmiller Dependencies- patch #9829 is dependent
    2019-07-16 siko1056 StatusNone Need Info
    2019-07-16 vrozos Carbon-Copy- Added vrozos

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code