RE: Access to a nested structure memory leak in mex function

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

RE: Access to a nested structure memory leak in mex function

George-2
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

---- [hidden email] wrote ----

>Send Octave-maintainers mailing list submissions to
> [hidden email]
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/octave-maintainers
>or, via email, send a message with subject or body 'help' to
> [hidden email]
>
>You can reach the person managing the list at
> [hidden email]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Octave-maintainers digest..."
>
>
>Today's Topics:
>
>   1. Re: Support Octave by new .m files (Hamed Shakouri)
>   2. Re: Access of a nested structure memory leak in mex function
>      (Evangelos Rozos)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 9 Jul 2019 14:31:36 -0700
>From: Hamed Shakouri <[hidden email]>
>To: CROZIER Richard <[hidden email]>
>Cc: "John W. Eaton" <[hidden email]>, Octave Maintainers List
> <[hidden email]>
>Subject: Re: Support Octave by new .m files
>Message-ID:
> <[hidden email]>
>Content-Type: text/plain; charset="utf-8"
>
>On Tue, Jul 9, 2019 at 3:13 AM CROZIER Richard <[hidden email]> wrote:
>
>>
>>
>> On 09/07/2019 01:46, Hamed Shakouri wrote:
>> >
>> >
>> > On Mon, Jul 8, 2019 at 8:54 AM CROZIER Richard <[hidden email]
>> > <mailto:[hidden email]>> wrote:
>> >
>> >
>> >      >
>> >      >  >> It's easy to find. If you look to the functions/scripts you
>> >     see that
>> >      > these undocumented functions such as abcdchk are used.
>> >      > These are usually simple functions that there is no need for
>> >     research or
>> >      > hard work to develop. e,g, abcdchk just checks for the proper
>> >     sizes of
>> >      > the state space matrixes.
>> >      >
>> >
>> >     His point is that, you have just shown, and put on record in a public
>> >     mailing list that you have opened and examined the Matlab source code
>> >     for the control package functions. This means that The Mathworks (who
>> >     are the owners of the Matlab code) could claim that you have
>> infringed
>> >     their copyright if you create code which is similar to theirs. Octave
>> >     code must be produced without any knowledge of how the code is
>> >     implemented in Matlab, see
>> >
>> >     https://en.wikipedia.org/wiki/Clean_room_design
>> >
>> >     for more information. Generally one should only look at the
>> >     documentation for Matlab code when developing an equivalent of a
>> Matlab
>> >     function for Octave.
>> >
>> >     Otherwise, The Mathworks might sue the pants off the Octave project.
>> >
>> >     Hopefully this explains the concerns better?
>> >
>> >     Regards,
>> >
>> >     Richard
>> >     The University of Edinburgh is a charitable body, registered in
>> >     Scotland, with registration number SC005336.
>> >
>> >
>> > Hi Richard,
>> >
>> > I know that some codes are valuable properties of their builders.
>> > However, the function I mentioned is a very simple straightforward one
>> > that anybody can implement without knowing anything from its inside, its
>> > logic is clear.
>> > For the other, FOH discretization method, I didn't use a MatLab function
>> > (it's not easy to find how it works!). One can get the formulation from
>> > published papers.
>> >
>> > A reference is here:
>> > Bingulac, S. and Sinha, N. K.: 'On the identification of continuous-time
>> > multivariable systems from samples of input-output data', Proc. 7th
>> > International Conference on Mathematical and Computer Modelling,
>> > Chicago, 1989.
>> > Or:
>> > Franklin G., J. Powell, and M. Workman, Digital Control of Dynamic
>> > Systems, 1990.
>> > Thank you for the clarification.
>> >
>> > With Regards,
>> >
>> > Hamed Shakouri G.
>>
>>
>> The triviality of the code may or may not be important. What's important
>> is that you have apparently opened up the Matlab functions, had a good
>> rummage around, and now plan to implement Octave code which does the
>> same thing. A lawyer can make a case from this, and if the Octave
>> project doesn't have a lot of money to defend itself (it doesn't) they
>> could walk all over it in court. Unfortunately the Octave devs have to
>> be very very careful about this kind of thing.
>>
>> Just to be clear, I'm not a core dev, just someone on the mailing list,
>> so don't take my opinion as the final word.
>>
>> Regards,
>>
>> Richard
>>
>>
>>
>>
>>
>>
>
>OK, thanks anyway. It is up to Octave team to manage such things. It was
>merely a suggestion.
>
>With Regards,
>
>Hamed Shakouri G.
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <https://lists.gnu.org/archive/html/octave-maintainers/attachments/20190709/f8c4ef3a/attachment.html>
>
>------------------------------
>
>Message: 2
>Date: Wed, 10 Jul 2019 12:42:24 +0300
>From: Evangelos Rozos <[hidden email]>
>To: Rik <[hidden email]>
>Cc: [hidden email]
>Subject: Re: Access of a nested structure memory leak in mex function
>Message-ID:
> <[hidden email]>
>Content-Type: text/plain; charset="utf-8"
>
>Yes, I will do that.
>
>On Mon, 8 Jul 2019 at 18:35, Rik <[hidden email]> wrote:
>
>> On 07/04/2019 09:01 AM, [hidden email] wrote:
>>
>> Subject:
>> Access of a nested structure memory leak in mex function
>>
>> From:
>> Evangelos Rozos <[hidden email]> <[hidden email]>
>>
>> Date:
>> 07/04/2019 03:59 AM
>>
>> To:
>> [hidden email]
>>
>> List-Post:
>> <mailto:[hidden email]> <[hidden email]>
>>
>> Content-Transfer-Encoding:
>> 8bit
>>
>> Precedence:
>> list
>>
>> MIME-Version:
>> 1.0
>>
>> Message-ID:
>> <[hidden email]>
>> <[hidden email]>
>>
>> Content-Type:
>> text/plain; charset=utf-8; format=flowed
>>
>> Message:
>> 1
>> The access of a nested structure passed to a mex function seems to create
>> memory leak.
>>
>> Example code:
>>
>>  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 exists in every platform and recent Octave version).
>> The same code does not create leak when compiled in MATLAB.
>>
>> Apparently, the indicated line code above does not create directly the
>> leak, but somehow confuses the memory management. The leak is noticeable
>> only after numerous calls of the mex function (7.6 MB/100000 calls).
>>
>> Evangelos Rozos
>>
>>
>> Could you file this as a bug report at bugs.octave.org?  It is liable to
>> get lost on the mailing list.
>>
>> When you do file a report, please include the Octave m-file code that is
>> associated with the mex C code so that the issue can be reproduced.
>>
>> Thanks,
>> Rik
>>
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <https://lists.gnu.org/archive/html/octave-maintainers/attachments/20190710/34f9420a/attachment.html>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>Octave-maintainers mailing list
>[hidden email]
>https://lists.gnu.org/mailman/listinfo/octave-maintainers
>
>
>------------------------------
>
>End of Octave-maintainers Digest, Vol 160, Issue 12
>***************************************************