assertion error for persistent memory object

Question

Chris van der Togt 2011-4-14

0
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/5495-assertion-error-for-persistent-memory-object

I have this code in a mex file to interface with a dll.

       plhs[0] = mxCreateDoubleMatrix(0, 0, mxREAL);
        Status = Reset_Status( In);
        mxSetPr(plhs[0], Status);
        mxSetM(plhs[0], 10);
        mxSetN(plhs[0], 1);

Reset_Status returns a global memory pointer which I want to read out multiple times. On windowsXP 32bit this does not cause problems. On Windows7 32 bit I get an assertion falure;

Assertion failed: Forced Assertion at line 314 of file ".\src\mem\alignment.cpp".
ALIGNMENT ERROR:   vector_check: pointer not allocated with vector_*alloc
PID:               2256
NATIVE ALIGNMENT:  8 (0x8)
REQ ALIGNMENT:     16 (0x10)
ALIGNED POINTER:   19BD2168
REQ SIZE:          0 (0)
HEADER ADDRESS:    00000000
HEADER SIZE:       8 (0x8)
HEADER DATA:       INACCESSIBLE

How should I resolve this?

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

请先登录，再进行评论。

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

Answer 1

Kaustubha Govind 2011-4-14

1
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/5495-assertion-error-for-persistent-memory-object#answer_7681

Since all memory held by variables passed in and out of MEX-functions is managed by MATLAB, it is not advisable to use mxSetPr to set (externally owned) data on a variable being returned to MATLAB. There is a danger of that memory being de-allocated by MATLAB.

Instead, I would recommend copying that data from your global buffer into plhs (which must be allocated using a call to mxCreateDoubleMatrix).

As for why this issue is not caught on XP - I wonder if the C runtime libraries are simply more robust on Windows 7?

5 个评论
显示 3更早的评论隐藏 3更早的评论

James Tursa 2011-4-14

Yes, but I would even make a stronger statement:

Mixing externally allocated data (i.e., automatic memory or memory allocated with functions other than MATLAB API functions like mxMalloc and cousins) into an mxArray causes unpredictable results and may crash MATLAB. Do not do this. The reason for this you have already stated ... it is unpredictable what will happen when MATLAB tries to clear such a variable and deallocate memory belonging to another memory manager.

As to why the assertion error shows up in one system and not another, I believe that has been a somewhat recent change in the API behavior. It used to be that the memory address passed into the mxSetPr, mxSetPi, etc functions was not checked to see if it came from the MATLAB memory manager. In those cases a mixed mxArray (for lack of a better term) was simply passed on downstream and then when it was eventually cleared the fault would happen at that time (typically some type of memory corruption segmentation fault). The API has changed so that the addresses passed to mxSetPr etc are now checked at the time of the call to see if they came from the MATLAB memory manager. If not, then an assertion fault happens at the point of the call. It is possible to get around this check by setting the pr etc pointers of an mxArray directly (i.e., not using mxSetPr), but doing so places a tremendous burden on the programmer to not screw things up downstream and this practice is highly discouraged (at least by me) unless you really, really, know what you are doing. Basically you have to become your own memory manager and disentangle the mxArray manually before MATLAB has a chance to clear it. Highly risky.

Kaustubha Govind 2011-4-14

+1 for James' comment that the assertion is caused by recent changes to the API - .\src\mem\alignment.cpp does indeed belong inside MATLAB.

Chris van der Togt 2011-4-15

Thank you for your answers, that clears things up. It's a shame though, this global array was filled by a callback routine triggered by an IO card. So all I had to do was read out the values from time to time. But copying them off is not so bad.

But I'm surprised that in the matlab help files this method of setting pointers is shown as good practice.

请先登录，再进行评论。