Re: Problems with mex file (allocating memory? )

"Dominic " <dom_awf@xxxxxxxxxxx> wrote in message <h0g5ne$h7q$1@xxxxxxxxxxxxxxxxxx>...
ok, I found out how to debug and he code crashs in this line

lineData = mxMalloc(*Records/500*sizeof(*lineData));

Because you haven't set the value of *Records yet. You are putting the cart before the horse. Here is a section of your original code you posted:

mwSize dims[2] = {1, *maxNoOfPhotons };
const char *fieldNames[] = {"chan","dtime","truetime","x","line","frame"};

// preallocate lineData array of structures
Data *lineData;
lineData = mxMalloc(*Records/500*sizeof(*lineData));

// passed parameters from matlab
fidIn = (FILE*)mxGetPr(prhs[0]);
Records = (int *)mxGetPr(prhs[1]);
syncperiod = (double*)mxGetPr(prhs[2]);
maxNoOfPhotons = (int*)mxGetPr(prhs[3]);
Resolution = (double*)mxGetPr(prhs[4]);

The first line above has the same problem. You are trying to dereference the maxNoOfPhotons variable before you have set it. So dims[1] will contain garbage, assuming that the dereferencing itself did not bomb the program. Same problem with your *Records dereferencing in the mxMalloc call above. You are using Records before it is set to anything.

2nd problem is that your use of prhs[1] and prhs[3] assumes that they are int32 class on the MATLAB side. I would suggest that you make things easier on yourself and use mxGetScalar generously here. e.g.,

change this:

int *Records;
int *maxNoOfPhotons;
double *syncperiod;
double *Resolution;

to this (i.e., don't use pointers):

int Records;
int maxNoOfPhotons;
double syncperiod;
double Resolution;

and then change these lines:

Records = (int *)mxGetPr(prhs[1]);
syncperiod = (double*)mxGetPr(prhs[2]);
maxNoOfPhotons = (int*)mxGetPr(prhs[3]);
Resolution = (double*)mxGetPr(prhs[4]);

to these lines:

Records = mxGetScalar(prhs[1]);
syncperiod = mxGetScalar(prhs[2]);
maxNoOfPhotons = mxGetScalar(prhs[3]);
Resolution = mxGetScalar(prhs[4]);

Then for all of the downstream stuff get rid of the dereferencing operator for these variables and just use them directly. e.g.,

change this line:

mwSize dims[2] = {1, *maxNoOfPhotons };

to this line:

mwSize dims[2] = {1, 0 }; // the 0 is an arbitrary placeholder number

and then right after getting the value of maxNoOfPhotons, do this line:

dims[1] = maxNoOfPhotons; // Note that you don't use *maxNoOfPhotons

That way you will have the dims array set properly for downstream use. Also, be sure to move this line:

lineData = mxMalloc(*Records/500*sizeof(*lineData));

to a point *after* you have set the value of Records, and then don't use the dereferencing operator because Records is no longer a pointer. e.g.,

lineData = mxMalloc(Records/500*sizeof(*lineData));

Just glancing through your code I also notice this:

if (result!= sizeof(Record))
{
mexPrintf("\nUnexpected end of input file!");
break;
}

Did you mean this?

if (result!= sizeof(Record))
{
mexErrMsgTxt("\nUnexpected end of input file!");
}

i.e., it you got an error or EOF trying to read your data, do you really want to continue the routine and use the invalid data? Or should you just return to MATLAB at that point with an error message?

James Tursa
.

Relevant Pages

  • Re: Explain why this prints the same
    ... > his original code and cleaned it up, but I am still wondering about ... lying to the compiler. ... Here the result is certain to be undefined behaviour. ...
    (comp.lang.c)
  • Re: [PATCH UPDATED] percpu: use dynamic percpu allocator as the default percpu allocator
    ... unsigned long flags; ... int off; ... Why don't we rewrite this as: ... actual difference between the original code and yours. ...
    (Linux-Kernel)
  • Re: goto
    ... Here is a rewrite that eliminates the gotos and the "silly" macros. ... is no guarantee that it (or the original code) is correct. ... int getStdI ...
    (comp.lang.c)
  • Re: goto
    ... is no guarantee that it (or the original code) is correct. ... I've never heard an objection to them. ... int getStdI ...
    (comp.lang.c)
  • Re: remove double entries from a sorted array
    ... --> int is okay this array has a limit to 100 items. ... I give you the original code ... RECLIEFNR *source; ... // for the last entrie ...
    (comp.lang.c)
Loading