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?

Answer 1

[Kaustubha Govind]

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?

[James Tursa]

"... it is not advisable to use mxSetPr to set the data on a variable being returned to MATLAB." Huh? I have never heard that one before. As long as one uses the MATLAB functions to allocate the memory (mxMalloc etc) this has always been safe. Can you please elaborate on your answer? It doesn't match my understanding of how one can safely build mxArrays from scratch.

[Kaustubha Govind]

James: Sorry about not being specific. I have edited my answer to say "... not advisable to use mxSetPr to set (externally owned) data on a variable being returned to MATLAB". Does this align with your understanding?

[James Tursa]

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]

+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]

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.