Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

problems with mxDestroyArray

15 views
Skip to first unread message

Matthias Kirchhoff

unread,
Jul 6, 1998, 3:00:00 AM7/6/98
to

I hope someone can help me solving a problem with some memory allocation in
a mex environment

It's simply an examples from the matlab helpdesk (example from mxPutArray
function). That dll calculates some values and writes them into the matlab
workspace.

her it goes, the code:

/******************* Includes */
#include <windows.h>
#include "mex.h"
#include "matrix.h"
/******************* Defines */
#define fiblen 10
/***************** Mex-Callingfunction */
void mexFunction( int nlhs, mxArray *plhs[],
int nrhs, const mxArray *prhs[])
{
double pr[fiblen];
mxArray *array_ptr;
int c;
int status;
/* Generate the first Fibonacci numbers up to fiblen. */
pr[0]=1;
pr[1]=1;
for (c=2; c<fiblen; c++)
{
pr[c] = pr[c-1] + pr[c-2];
}
/* Create an mxArray named Fibs seeded to pr. */
array_ptr = mxCreateDoubleMatrix(1, fiblen, mxREAL);
mxSetPr(array_ptr, pr);
mxSetName(array_ptr, "Fibs");
/* Put "Fibs" into the MATLAB workspace. */
status = mexPutArray(array_ptr, "base");
printf("status = %d\n", status);
}

So far just fine, program compiles without any problems but during run the
following occured:

» fib
status = 0

Warning: You have set a component of an array (such as the data) to a block
of
memory not allocated through the MATLAB API. Such arrays cannot be
automatically destructed at MEX-file exit. MATLAB will attempt to
fix the problem and continue, but this will result in memory faults in
future releases.

--->
I allready reported that bug in the example to matlab and to correct that
problem inserted the following lines at the end of my program:

/* Free up allocated memory. */
mxDestroyArray(array_ptr);

I thought that would bring the stuff to a good end, but more and strange
things happened. The following was the result of running the dll.

» fib
status = 0

Assertion failed: (table->ptr_array != NULL), at line 797 of file
".\util\mwmem.c".
Cache internal consistency error 3 (Table index invalid)
Stack trace:
[1] 0059dea0()
[2] 005990b9()
[3] 0059e8d4()
[4] 0059d831()
[5] 00503980()
[6] 0050389a()
[7] 052c109a()
[8] 006862f5()
[9] 00542d00()
[10] 00542ad2()
[11] 0053c439()
[12] 005534ab()
[13] 005329b6()
[14] 00553e7e()
[15] 00403427()
[16] 0068d06f()
[17] bff88e93()
[18] bff88d41()
[19] bff87759()
Error in ==> c:\matlab5\toolbox\mexeng\sources\fib.dll

*********************

Now the question. Has anybody encountered a similar problem and how can I
solve this.

Thanks in advance
Matthias

Sharon Reposa Quaranta

unread,
Jul 6, 1998, 3:00:00 AM7/6/98
to Matthias Kirchhoff


Dear Matthias,

You were getting the original warning:

Warning: You have set a component of an array (such as the data) to a
block of memory not allocated through the MATLAB API. Such arrays
cannot be
automatically destructed at MEX-file exit. MATLAB will attempt to
fix the problem and continue, but this will result in memory faults in
future releases.

because there was an error in the example. The example used mxSetPr to
set the data pointer. Due to changes in the API, if you call mxSetPr
with memory as the intended data block that was not allocated by
mxCalloc, mxMalloc, or mxRealloc, when the MEX-file returns, MATLAB will
attempt to free the pointer to the real data the pointer to the
imaginary data(if any exists), thus causing memory problems. This is
why the warning is now displayed when you run the code.

To correct the code, you should create the mxArray with the right size
and use the memcpy command to copy the stack data into the buffer
returned by mxGetPr. I have corrected the example below.

I was able to compile and run this example without any problems on my
machine. Please let me know if you run into any problems with the code
below.


/******************* Includes */

#include "mex.h"
#include "matrix.h"
/******************* Defines */
#define fiblen 10
/***************** Mex-Callingfunction */
void mexFunction( int nlhs, mxArray *plhs[],
int nrhs, const mxArray *prhs[])
{
double pr[fiblen];
mxArray *array_ptr;
int c;
int status;
/* Generate the first Fibonacci numbers up to fiblen. */
pr[0]=1;
pr[1]=1;
for (c=2; c<fiblen; c++)
{
pr[c] = pr[c-1] + pr[c-2];
}
/* Create an mxArray named Fibs seeded to pr. */
array_ptr = mxCreateDoubleMatrix(1, fiblen, mxREAL);

memcpy (mxGetPr(array_ptr), pr , fiblen*sizeof(double));


mxSetName(array_ptr, "Fibs");
/* Put "Fibs" into the MATLAB workspace. */
status = mexPutArray(array_ptr, "base");
printf("status = %d\n", status);
}

HTH,
Sharon
--
====================================================================
| Sharon Reposa Quaranta | sharon...@mathworks.com |
| The MathWorks, Inc. | email: in...@mathworks.com |
| 24 Prime Park Way | WWW : http://www.mathworks.com |
| Natick, MA 01760-1500 | FTP : ftp://ftp.mathworks.com |
| Phone: (508) 647-7000 | FAX : (508) 647-7201 |
====================================================================

raymond s. norris

unread,
Jul 6, 1998, 3:00:00 AM7/6/98
to Matthias Kirchhoff

Hi Matthias-

[See Sharon Quaranta's post about the error first error message]

Just to explain your second error message, you don't want to destroy
your array if it's gettting passed back to MATLAB. This included calls
such as:

plhs[0]=mxCreate...

and then

mxDestroyArray(plhs[0])

In the same way, if you "put" an array into a workspace, you don't want
to destroy it, let MATLAB handle those variables.

hth,
-raymond

Kristopher Giesing

unread,
Jul 6, 1998, 3:00:00 AM7/6/98
to

raymond s. norris wrote:
>
> Hi Matthias-
>
> [See Sharon Quaranta's post about the error first error message]
>
> Just to explain your second error message, you don't want to destroy
> your array if it's gettting passed back to MATLAB. This included calls
> such as:
>
> plhs[0]=mxCreate...
>
> and then
>
> mxDestroyArray(plhs[0])
>

Hi,

Ray is correct in that the outputs from a MEX-file should not be
destroyed. However, when you call mexPutArray(), the array you pass is
actually copied before being placed into the workspace. (mexGetArray()
similarly gives you a copy of the array in the workspace.) So,
destroying the array you pass to mexPutArray() is a legal operation.

If you don't destroy the array, MATLAB will destroy it for you as part
of the process of returning control to the MEX-file's caller. The
warning is generated when MATLAB detects that the array you've left is
not "destroyable," that is, attempting to destroy it raises an error
condition. In this case, it's because the data part of the array cannot
be freed. MATLAB traps this error, but if you try to destroy the array
on your own (as you attempted to do) the error will cause an assertion
failure or segmentation violation.

I hope this explanation makes sense. You might be interested in reading
the section in the API Guide called "Memory Management" (under the
Advanced Topics heading in chapter 3). This section is new in the
MATLAB 5.2 documentation.

Sincerely,

Kris Giesing
--

==Kris Giesing========================== kr...@mathworks.com ========


| The MathWorks, Inc. | email: in...@mathworks.com |
| 24 Prime Park Way | WWW : http://www.mathworks.com |

| Natick, MA 01760-1500 | FTP : ftp.mathworks.com |
| Phone: (508) 647-7000 | FAX : (508) 647-7001 |
====================================================================

0 new messages