Does mxDestroyArray() recursively de-allocate elements of structs and cells?

Question

Szabolcs 2013-2-16

1
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/63726-does-mxdestroyarray-recursively-de-allocate-elements-of-structs-and-cells

The question is in the title. Is is about the C matrix library interface.

To explain in more detail, suppose that I create a 1 by 1 cell using mxCreateCellArray(), then create a numeric matrix using mxCreateNumericArray() and set it as the only element of the cell. Now will calling mxDestroyArray() on the cell destroy the numeric array as well, in one go? Or do I need to call it separately for the elements of the cell, then just the cell? I am hoping for the latter, as this is more reasonable for complex manipulations.

The documentation is ambiguous on this point.

2 个评论
显示无隐藏无

Szabolcs 2013-2-16

编辑：Szabolcs 2013-2-17

Note: cross posted on StackOverflow.

Jan 2013-2-17

@Syabolcs: Thanks for mentioning the cross-posting. This is a good example for others. +1

You can omit the memset(), because the memory is initialized already.

请先登录，再进行评论。

请先登录，再回答此问题。

Answer 1

Jan 2013-2-17

2
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/63726-does-mxdestroyarray-recursively-de-allocate-elements-of-structs-and-cells#answer_75323

编辑：Jan 2013-2-17

在 MATLAB Online 中打开

Yes, mxDestroyArray() recursively de-allocates elements of structs and cells. Otherwise you could observe a memory leak.

[EDITED]

The documentation of mxDestroyArray explains clearly (e.g. in R2009a):

mxDestroyArray not only deallocates the memory occupied by the mxArray's characteristics fields [...], but also deallocates all the mxArray's associated data arrays, such as [...], fields of structure arrays, and cells of cell arrays.

And a small C-mex test function (call it test_mxDestroy.c and compile it):

#include "mex.h"
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
  mxArray *C;
  C = mxCreateCellMatrix(1, 1);
  mxSetCell(C, 0, mxCreateDoubleMatrix(1, 1000000, mxREAL));
  mxDestroyArray(C);
}

If the contents of the created cell is not freed implicitly, 8MB memory would be leaked in each call. Now inspect the operating systems memory manager while running:

for k = 1:1e6, test_mxDestroy; end

You will see, that the memory is not exhausted.

As James has explained already, your example does not crash accidentally only. When you try to use mat after mxDestroyArray(cell), you will encounter a crash soon. ATTENTION: Crashing the Matlab session can destroy data. So keep care, and even better keep a backup.

13 个评论
显示 11更早的评论隐藏 11更早的评论

James Tursa 2013-2-17

编辑：James Tursa 2013-2-17

I am quite certain that Jan is correct unless something very strange is going on in Engine applications vs mex routines that I am unaware of. You can test it with a very large mat instead of a scalar. Look at the memory usage before and after destroying cell and you will see the large memory used by mat is released.

As to why your example program does not crash, I would say you are just lucky. After calling mxDestroyArray(cell), the pointer value contained in mat is no longer valid because that mxArray has just been destroyed. Subsequently calling mxDestroyArray(mat) is not valid and will produce unpredictable results (dereferencing an invalid pointer and everything bad that can result from that). Maybe nothing bad happens because mat is small instead of large, or maybe because you don't do anything much downstream in your code, or maybe because you don't have many mxArray variables in existence that could be corrupted, or ...??? Who knows? But it is definitely invalid.

Szabolcs 2013-2-17

编辑：Szabolcs 2013-2-17

Thanks for looking at this @James. Yes, you are right that it can also be just luck that the example program doesn't crash, that is why it's not a proper test.

I did as you suggested (please see the edit to the example program), and I inserted pauses in the program after the creation of the matrix, after the destruction of the cell and after the destruction of the matrix. I was watching the memory usage at the pauses, as shown by Activity Monitor (I'm on OS X). Memory usage goes down only after mxDestroyArray(mat), not at mxDestroyArray(cell). This again suggests that destroying 'mat' separately is necessary (which is incidentally convenient for my application).

But I can't ignore that both of you said that mxDestroyArray(cell) is sufficient and mxDestroyArray(mat) is crash-prone, so I would like to ask you to please take another look at this.

Yes, this is an engine application, not mex. But the data structure manipulation functions are the same for both, aren't they?

Szabolcs 2013-2-17

@Jan You were running your example code from within MATLAB, right? I ran my example as an engine application, i.e. in a separate process from MATLAB. Now I also tried running these from within MATLAB as you did, and it turns out that the behaviour is different:

Here's something interesting to try: change your code to allocate a lot more memory in one go than 8 MB (I went straight for 800 MB to make things very clear). The remove all mxDestroyArray calls from it. Now memory should definitely grow significantly with every call to test_mxDestroy, right? But it doesn't. If I watch the task manager carefully, I sometimes notice a momentary increase in memory by a few hundred MB, but it drops right down. I can even put test_mxDestroy in a loop as you did, and it does not cause any memory increase even though I removed all mxDestroyArray calls.

Note that this only happens when running inside matlab, not when running as an engine application.

The only explanation I can find is that:

mxDestroyArray is not recursive
But MATLAB has some sort of garbage collection mechanism that takes care of freeing unreferenced data. This garbage collector is available within MATLAB, but not in libeng (engine applications).

James Tursa 2013-2-17

编辑：James Tursa 2013-2-18

@Jan: Technical side note ... for a normal return from a mex routine, shared data copies of the plhs[] variables are what are actually returned, not the plhs[] variables themselves. Then everything on the garbage collection list is destroyed, including the plhs[] variables which are in fact on the garbage collection list (except for persistent variables such as prhs[] or using mexMakeArrayPersistent). For an error return, the only difference is that shared data copies of the plhs[] variables are not made, only the garbage collection (including the plhs[] variables) takes place.