Thread Subject: Segmentation violation due to MEX code

Hi!


I am trying to implement a very simple subroutine embeding a CMEX code in Matlab.

Does anybody know if it is possible that I get a "Segmentation violation" error even if I don't go beyond the iput arrays' limits?


I have checked the code with small inputs, and works fine. But when I send a rather huge array, it crashes.

This is the code:
#include "mex.h"

/*
* Calculate_I_Values.c
* Used to speed up the I mapping calculations
*
* This is a MEX-file for MATLAB.
*/


/* The gateway function */
void mexFunction( int nlhs, mxArray *plhs[],
int nrhs, const mxArray *prhs[])
{
/* variable declarations here */
double *e, *x, *y, *I;
int eRows, eCols, xRows, xCols, yRows, yCols, index, ySize;
int m, i, j;
double num, den;

e = mxGetPr(prhs[0]);
eRows = mxGetN(prhs[0]);
eCols = mxGetM(prhs[0]);

x = mxGetPr(prhs[1]);
xRows = mxGetN(prhs[1]);
xCols = mxGetM(prhs[1]);

y = mxGetPr(prhs[2]);
yRows = mxGetN(prhs[2]);
yCols = mxGetM(prhs[2]);
ySize = mxGetNumberOfElements(prhs[2]);


/* Allocate output memory */
plhs[0] = mxCreateDoubleMatrix(1, 256, mxREAL);
I = mxGetPr(plhs[0]);


/* code here */
printf("The xNumRow is: %d\n", (int)xRows);
printf("The xNumCol is: %d\n\n", (int)xCols);
printf("The yNumRow is: %d\n", (int)yRows);
printf("The yNumCol is: %d\n\n", (int)yCols);
printf("The ySize is: %d\n\n", (int)ySize);
printf("The eNumRow is: %d\n", (int)eRows);
printf("The eNumCol is: %d\n\n", (int)eCols);

for (m = 0; m <= 255; m++)
{
printf("m = %d -> ", (int)m);
num = 0;
den = 0;
for (i = 0; i < yRows; i++)
for (j = 0; j < yCols; j++)
{
index = i * yCols + j;
if (index >= ySize)
printf("Wrong\n");
else if (m == y[index])
{
num += e[j] * x[i];
den++;
}
}
if (den == 0) I[m] = num;
else I[m] = num / den;
}

}


It is actually pretty simple, but...

I call the function by:
Calculate_I_Values(exposures.', x.', y.');

Obviously after compiling.


The first printf lines give me:
The xNumRow is: 361862
The xNumCol is: 1

The yNumRow is: 361862
The yNumCol is: 16

The ySize is: 5789792

The eNumRow is: 1
The eNumCol is: 16

So everyting is as it should be. But then I get the segmentation violation error.


I have commented different parts of the program, and concluded that the error is when I do y[index]. So I guess I am trying to access a memory address which is shouldn't...

But I have already controlled that the index does not exceed the size of the input array! (ySize)


Anyway, if I don't let that line to run, and I print the index, i and j values, after the double loop ends, I get:
index: 5789791; i: 361862; j: 16

Which are fine! (i and j are 1 over the limit, so that's why the double loop has ended, and index is also correct)


I am pretty sure the problem has to do with memory allocation when calling the function.

I think so because I have tried to make it work with arrays with up to 10000 values and it performs correctly... I actually need to handle a 700x600x16 pixels array, so I am far from that!

Any idea if what I say makes sense?

If so, how can I increase the memory assigned to the MEX function?


Any clue would be appreciated :)

Thanks in advance
Jose

On 6 Jul, 21:49, "Jose Antonio " <jurig...@gmail.com> wrote:
> Hi!
>
> I am trying to implement a very simple subroutine embeding a CMEX code in Matlab.


> I am pretty sure the problem has to do with memory allocation when calling the function.

Well, you need to check that all the details match up.
What are the data types of the variables you feed to
the algorithm?

In a different thread you talked about image processing.
Is any of the variables an image? If so, what data
type do you use to represent pixels?

As I said before, you need to know what you are doing
on a level of detail way beyond what you would be used to,
if matlab is your only programming experience thus far.

Rune

Hi!

Thanks. You're absolutely right. I have just modified the data type sent to the function and it works.

By the way, it is even a little faster than the implementation we worked out using accumarray!

Jose

"Jose Antonio " <juriguen@gmail.com> wrote in message <h2tmbf$t3o$1@fred.mathworks.com>...

>
> By the way, it is even a little faster than the implementation we worked out using accumarray!

Any more specific?

Bruno

Sure!

I mean compared to the post
"HOWTO: Accelerate processing algorithm"

But the last version I have done in C, not the one in the post right now. If you are interested any further, I can post it as well.

Jose

"Jose Antonio " <juriguen@gmail.com> wrote in message <h2tnu1$dng$1@fred.mathworks.com>...
> Sure!
>
> I mean compared to the post
> "HOWTO: Accelerate processing algorithm"
>
> But the last version I have done in C, not the one in the post right now. If you are interested any further, I can post it as well.
>

Sorry; I meant to be more specific in run time between MEX and ACCUMARRAY?

Bruno

Jaja, sorry I misunderstood

The difference is not great though, but the solution you advised with accumarray takes around 1s in the best case (only that part of the code), while the MEX always takes 0.6s

I mean best for accumarray because it looks like it speeds up, as if Matlab had to warm up or something. The first time I call the routine it takes like 3s, and then fixes to around 1s. But the MEX code is always twice as fast.

Jose

"Jose Antonio " <juriguen@gmail.com> wrote in message <h2tos2$fdt$1@fred.mathworks.com>...
> Jaja, sorry I misunderstood
>
> The difference is not great though, but the solution you advised with accumarray takes around 1s in the best case (only that part of the code), while the MEX always takes 0.6s
>
> I mean best for accumarray because it looks like it speeds up, as if Matlab had to warm up or something. The first time I call the routine it takes like 3s, and then fixes to around 1s. But the MEX code is always twice as fast.
>

It's called "jitter". Also Matlab needs to download/sparse MEX/M/P files at the very first call. Thanks, the time is what I expected, ACCUMARRAY is quite efficient stock function.

Bruno

On 6 Jul, 23:04, "Jose Antonio " <jurig...@gmail.com> wrote:
> Jaja, sorry I misunderstood
>
> The difference is not great though, but the solution you advised with accumarray takes around 1s in the best case (only that part of the code), while the MEX always takes 0.6s
>
> I mean best for accumarray because it looks like it speeds up, as if Matlab had to warm up or something. The first time I call the routine it takes like 3s, and then fixes to around 1s. But the MEX code is always twice as fast.

It can get even faster. From your first post:

        for (i = 0; i < yRows; i++)
            for (j = 0; j < yCols; j++)
            {
                index = i * yCols + j;
                if (index >= ySize)
                    printf("Wrong\n");
                else if (m == y[index])
                {
======>>>>>> num += e[j] * x[i];
                    den++;
                 }
            }
        if (den == 0) I[m] = num;
        else I[m] = num / den;

The line I have marked out shows a computation
bewteev e[j] and x[i]. The loop ove j is inside
the loop over i, meaning that you multiply with
the same number x[i] j times.

Instead, move that computation out of the loop
over j, and multiply num by x[i] at the end,
before you use it.

Depending on what compiler you use, this may or
may not have an impact on run-time. A state-of-
the-art compiler might detect this and automatically
move x[i] outside the loop over j. With a simpler
compiler (LCC, which comes with matlab, is not
expected to be very advanced) you might have to
reorganize the code yourself.

Second, change the order of the if-else tests
in the last two lines above. If the code above
is correct, there are not very many cases where
den == 0, so the likelihood that the test actually
matches is very small.

However, since the test for den==0 has to be done
every time, and the alternative case is an else
statement, you loose some time here.

Instead, write

        if (den != 0) I[m] = num / den;
        else I[m] = num;

This way you skip the evaluaition of the else
statement most of the time.

And yes: Loose the PRINTF statements! You don't
need them, and they gobble ridiculous amounts
of time.

Don't be surprised if, after these modifications,
your routine run in less than 5% of the ACCUMARRAY
variant.

Rune

On 7 Jul, 06:18, Rune Allnor <all...@tele.ntnu.no> wrote:
> On 6 Jul, 23:04, "Jose Antonio " <jurig...@gmail.com> wrote:
>
> > Jaja, sorry I misunderstood
>
> > The difference is not great though, but the solution you advised with accumarray takes around 1s in the best case (only that part of the code), while the MEX always takes 0.6s
...
> Don't be surprised if, after these modifications,
> your routine run in less than 5% of the ACCUMARRAY
> variant.

It's early morning yet, so I missed a detail that
might be as significant as the others combined:

As a rule, use ++i, ++j, ++den, ++num and so on,
instead i++, j++ etc.

The ++i variant is slightly faster than the i++
variant, and your routine is so simple that this
might actually matter.

What speed-ups do you achieve after these
modifications?

Rune

>
> What speed-ups do you achieve after these
> modifications?

Elapsed time is 2.187960 seconds. % <- ACCUMARRAY
Elapsed time is 3.918172 seconds. % <- MEX, MSVS 6.0, compiled with -O

codes attached bellow.

% Bruno


function timethem

N=700*600*20;
x = rand(1,N);
e = rand(1,N);
y = floor(rand(1,N)*255);

tic
v = x.*e;
yp1 = y(:)+1;
S = accumarray(yp1,v(:))./accumarray(yp1,1,[],[],1);
toc
clear S

tic
S = Calculate_I_Values(e(:), x(:), y(:));
toc
clear S

end


/*
 * Calculate_I_Values.c
 * Used to speed up the I mapping calculations
 *
 * This is a MEX-file for MATLAB.
 */

#include "mex.h"
#include "matrix.h"

/* The gateway function */
void mexFunction( int nlhs, mxArray *plhs[],
        int nrhs, const mxArray *prhs[]) {
    /* variable declarations here */
    double *e, *x, *y, *I;
    int eRows, eCols, xRows, xCols, yRows, yCols, index, ySize;
    int m, i, j;
    double num, den;
    
    e = mxGetPr(prhs[0]);
    eRows = mxGetN(prhs[0]);
    eCols = mxGetM(prhs[0]);
    
    x = mxGetPr(prhs[1]);
    xRows = mxGetN(prhs[1]);
    xCols = mxGetM(prhs[1]);
    
    y = mxGetPr(prhs[2]);
    yRows = mxGetN(prhs[2]);
    yCols = mxGetM(prhs[2]);
    ySize = mxGetNumberOfElements(prhs[2]);
    
    
    /* Allocate output memory */
    plhs[0] = mxCreateDoubleMatrix(1, 256, mxREAL);
    I = mxGetPr(plhs[0]);
    
    /* code here */
    for (m = 0; m <= 255; ++m) {
        num = 0;
        den = 0;
        for (i = 0; i < yRows; ++i)
            for (j = 0; j < yCols; ++j) {
            index = i * yCols + j;
            if (m == y[index]) {
                num += x[i];
                ++den;
            }
        }
        num *= e[j];
        if (den != 0) I[m] = num / den;
        else I[m] = num;
    }
    
}

On 7 Jul, 07:29, "Bruno Luong" <b.lu...@fogale.findmycountry> wrote:
> > What speed-ups do you achieve after these
> > modifications?
>
> Elapsed time is 2.187960 seconds. % <- ACCUMARRAY
> Elapsed time is 3.918172 seconds. % <- MEX, MSVS 6.0, compiled with -O
>
> codes attached bellow.

The test is invalid, as the routines produce different results.

Rune

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function timethem

N=700*600*20;
x = rand(1,N);
e = rand(1,N);
y = floor(rand(1,N)*255);

tic
v = x.*e;
yp1 = y(:)+1;
S1 = accumarray(yp1,v(:))./accumarray(yp1,1,[],[],1);
toc

tic
S2 = Calculate_I_ValuesCpp(e(:), x(:), y(:));
toc

max(max(abs(S1-S2))) % Compare results. Fails because
                      % S1 and S2 are of different sizes.

end

Rune Allnor <allnor@tele.ntnu.no> wrote in message <0730bcf8-a935-44b6-b7ad-16430725fceb@d4g2000yqa.googlegroups.com>...
> On 7 Jul, 07:29, "Bruno Luong" <b.lu...@fogale.findmycountry> wrote:
> > > What speed-ups do you achieve after these
> > > modifications?
> >
> > Elapsed time is 2.187960 seconds. % <- ACCUMARRAY
> > Elapsed time is 3.918172 seconds. % <- MEX, MSVS 6.0, compiled with -O
> >
> > codes attached bellow.
>
> The test is invalid, as the routines produce different results.
>

Yes ACCUMARRAY doing *MORE* than the C code.

Bruno

On 7 Jul, 10:41, "Bruno Luong" <b.lu...@fogale.findmycountry> wrote:
> Rune Allnor <all...@tele.ntnu.no> wrote in message <0730bcf8-a935-44b6-b7ad-16430725f...@d4g2000yqa.googlegroups.com>...
> > On 7 Jul, 07:29, "Bruno Luong" <b.lu...@fogale.findmycountry> wrote:
> > > > What speed-ups do you achieve after these
> > > > modifications?
>
> > > Elapsed time is 2.187960 seconds. % <- ACCUMARRAY
> > > Elapsed time is 3.918172 seconds. % <- MEX, MSVS 6.0, compiled with -O
>
> > > codes attached bellow.
>
> > The test is invalid, as the routines produce different results.
>
> Yes ACCUMARRAY doing *MORE* than the C code.

I'd rather wait for whatever results the OP would post.
Remember, he reported that his crude C routine ran in
half the time of ACCUMARRAY.

My prediction:

- Removing PRINTF statements from his code would
  reduce run-time by more than 90%
- The remaining tweaks and mods would axe another
  30-50% of whatever remains.

Rune

Hi again!


Sorry I didn't answer before. I have to admit I have just realized all the experiments you have been posting. Thanks a lot!

The truth is that I posted the topic first through http://mathforum.org/kb/forum.jspa?forumID=80, and then I found the http://www.mathworks.de/matlabcentral/newsreader link and posted again, without knowing that I already had a copy of the first post in the latter forum.


Anyway, the codes to compare are a little different to what you posted, since I changed something that drastically increased the C performance. Here it goes:

#include "mex.h"

/*
 * Calculate_I_Values.c
 * Used to speed up the I mapping calculations
 *
 * S = Calculate_I_Values(exposures.', (x(:, chan)).', double(y.'));
 *
 * This is a MEX-file for MATLAB.
*/


/* The gateway function */
void mexFunction( int nlhs, mxArray *plhs[],
                  int nrhs, const mxArray *prhs[])
{
    /* variable declarations here */
    double *e, *x, *y, *I;
    int eRows, eCols, xRows, xCols, yRows, yCols, index, ySize;
    int m, i, j;
    double num[256], den[256];

    e = mxGetPr(prhs[0]);
    eRows = mxGetN(prhs[0]);
    eCols = mxGetM(prhs[0]);

    x = mxGetPr(prhs[1]);
    xRows = mxGetN(prhs[1]);
    xCols = mxGetM(prhs[1]);

    y = mxGetPr(prhs[2]);
    yRows = mxGetN(prhs[2]);
    yCols = mxGetM(prhs[2]);
    ySize = mxGetNumberOfElements(prhs[2]);


    /* Allocate output memory */
    plhs[0] = mxCreateDoubleMatrix(1, 256, mxREAL);
    I = mxGetPr(plhs[0]);


    /* code here */
    for (m = 0; m <= 255; m++)
        num[m] = den[m] = 0;
    for (i = 0; i < yRows; i++)
        for (j = 0; j < yCols; j++)
        {
            index = i * yCols + j;
            if (index <= ySize)
                m = (int) y[index];
            num[m] += e[j] * x[i];
            den[m]++;
        }
    for (m = 0; m <= 255; m++)
        if (den[m] == 0) I[m] = num[m];
        else I[m] = num[m] / den[m];
}

Note that now I directly use m as the index, rather than looping for all its range and performing if comparisons.

The code to beat was:
function S = calculate_I(exposures, x, y)

exposuresMat = repmat(exposures, [size(y,1) 1]);
xMat = repmat(x, [1 length(exposures)]);
v = xMat .* exposuresMat;

% Slower
% S = accumarray(y(:)+1,v(:), [], @mean);

yp1 = y(:)+1;
S = accumarray(yp1,v(:))./accumarray(yp1,1);
S(isnan(S)) = 0;


I have checked the comparison running the functions only once, and measuring with tic and toc. Probably a more precise result can be obtained running them 10 times and averaging.

My results:
tic; S = Calculate_I_Values(exposures.', (x(:, chan)).', double(y.')); toc
Elapsed time is 0.599098 seconds.

tic; S = calculate_I(exposures, x(:, chan), y); toc;
Elapsed time is 6.367185 seconds.
>> tic; S = calculate_I(exposures, x(:, chan), y); toc;
Elapsed time is 1.204878 seconds.
>> tic; S = calculate_I(exposures, x(:, chan), y); toc;
Elapsed time is 1.039880 seconds.

The Matlab function needs to warm up! Jaja.


The arrays:
>> size(exposures)
ans =
     1 16
>> size(x(:, chan))
ans =
      361862 1
>> size(y)
ans =
      361862 16


The returned S values are the same for both functions, but with different length. Yo can check that visually with [S1; [S2; 0].'].', being S1 the answer for the MEX code and S2 the accumarray solution.

I still have to check why I get 1 value less with the second approach, but I am doing a complete different thing today!


Thanks a lot again
Jose

"Jose Antonio " <juriguen@gmail.com> wrote in message <h2vhoq$oot$1@fred.mathworks.com>...

>
> I still have to check why I get 1 value less with the second approach, but I am doing a complete different thing today!
>

Probably because your image (y) never reach the value 255. Force the output size ACCUMARRAY. Also use BSXFUN (available from 2007A) is better than REPMAT.

function S = calculate_I(exposures, x, y)

exposuresMat = reshape(exposures, 1, []);
xMat = reshape(x, [], 1);
v = bsxfun(@times, xMat, exposuresMat);
yp1 = y(:)+1;
S = accumarray(yp1,v(:),[256 1]) ./ accumarray(yp1,1,[256 1]);
S(isnan(S)) = 0;

Bruno

Definitely better


Now Matlab functions again beat my C code! No all the time, though :)

>> tic; S1 = Calculate_I_Values(exposures.', (x(:, chan)).', double(y.')); toc
Elapsed time is 0.647157 seconds.
>> tic; S2 = calculate_I(exposures, x(:, chan), y); toc;
Elapsed time is 0.594447 seconds.


The only last weird thing is that the last 2 values that I obtain differ from both implementations... I have to check that... But don't worry, I will try that myself! I feel like you are spending too much time on this post :) (absolutely no problem for me, unless you're losing your own time!)

Cheers
Jose

"Jose Antonio " <juriguen@gmail.com> wrote in message <h2vqv1$a2i$1@fred.mathworks.com>...
> I feel like you are spending too much time on this post :) (absolutely no problem for me, unless you're losing your own time!)

Don't worry Jose, it doesn't take me too much time, and if it does I would stop posting on my own.

Bruno

Now, even though I know it's kind of stupid, I want to accelerate the C code... Matlab cannot be faster! Jaja


Anyway, I have changed "den[m]++" for "++den[m]", and now run 10 times de function between tic and toc. It does actually perform a little slower...

The other i++, j++, m++ I gues I cannot try to change, since I use the values in the for loops, and thus I need i, j, and m not to increment before entering the loop. I know I could begin them from (-1) and to (lengths-1), etc, but I think that will not improve a lot anyway.


On the other hand, there's something I would be happy to change. When I call the function, I have an array/matrix, y, of uint8 values, so I have to call using double(y). Then, in the C code I use m = (int)y[index], since the values are going to be integers and in [0,255].

Is it possible to directly send them as integers (the same as I did at the beginning getting the segmentation violation error), but obviously without the error. So, can I read them as integers from the C code?


This is only to learn and make the code a little "cleaner". In fact the speed I have already achieved is really good enough.

I mean, if anybody remembers from my first "HOWTO..." post, my initial routine took 30-40s for each calculation, while now I can do 10 iterations on the 3 color channels in arround 30s!


Thanks!
Jose

"Jose Antonio " <juriguen@gmail.com> wrote in message <h2vsr1$d1s$1@fred.mathworks.com>...
> Now, even though I know it's kind of stupid, I want to accelerate the C code... Matlab cannot be faster! Jaja

No, you could beat MATLAB with MEX, but see how hard it is?

>
>
> On the other hand, there's something I would be happy to change. When I call the function, I have an array/matrix, y, of uint8 values, so I have to call using double(y). Then, in the C code I use m = (int)y[index], since the values are going to be integers and in [0,255].
>
> Is it possible to directly send them as integers (the same as I did at the beginning getting the segmentation violation error), but obviously without the error. So, can I read them as integers from the C code?

Yes, the uint8 in MATLAB corresponds to UNSIGNED CHAR in C. Ideally you should check the class of the input arrays using mxGetClassID() function, and use the right pointer type accordingly.

Bruno

Thanks again


I knew this would help me beating Matlab as well! Jeje.

>> tic; S1 = Calculate_I_Values(exposures.', (x(:, chan)).', (y.')); toc
Elapsed time is 0.304035 seconds.
>> tic; S2 = calculate_I(exposures, x(:, chan), y); toc;
Elapsed time is 0.613726 seconds.


Here is the code. I will add some error management stuff latter.

#include "mex.h"

/*
 * Calculate_I_Values.c
 * Used to speed up the I mapping calculations
 *
 * S = Calculate_I_Values(exposures.', (x(:, chan)).', double(y.'));
 *
 * This is a MEX-file for MATLAB.
*/


/* The gateway function */
void mexFunction( int nlhs, mxArray *plhs[],
                  int nrhs, const mxArray *prhs[])
{
    /* variable declarations here */
    double *e, *x, *I;
    int eRows, eCols, xRows, xCols, yRows, yCols, index, ySize;
    int m, i, j;
    unsigned char *y;
    double num[256], den[256];
    mxClassID category;

    e = mxGetPr(prhs[0]);
    x = mxGetPr(prhs[1]);

    category = mxGetClassID(prhs[2]);
    switch (category) {
        case mxUINT8_CLASS: y = (unsigned char *)mxGetData(prhs[2]); break;
default: break;
    }
    yRows = mxGetN(prhs[2]);
    yCols = mxGetM(prhs[2]);


    /* Allocate output memory */
    plhs[0] = mxCreateDoubleMatrix(1, 256, mxREAL);
    I = mxGetPr(plhs[0]);


    for (m = 0; m <= 255; m++)
        num[m] = den[m] = 0;
    
    for (i = 0; i < yRows; i++)
        for (j = 0; j < yCols; j++)
        {
            index = i * yCols + j;
            m = y[index];
            num[m] += e[j] * x[i];
            ++den[m];
        }
    
    for (m = 0; m <= 255; m++)
        if (den[m] != 0) I[m] = num[m] / den[m];
        else I[m] = num[m];
}


I am happy, because I think I have learnt a lot these days! No doubt it was a good idea to post here :) And I also like to have begun reminding a few concepts of C.

I really wanted to learn some image processing with C, and I think this "intermediate" embedded MEX codes are really helpful.

For me the worst part is to choose a good compiler / programming environment, to obtain the required libraries and all that stuff, so I have to admit Matlab developers did a pretty good job!

By the way, any suggestion regarding the "crude" C/C++ environment? And any good way to install image processing libraries (such as for jpeg, tiff reading / writting, fft calculations, etc)?


Bests
Jose

Hey

I have encountered the same problems you had before.

You said you had fixed the data type so it worked finally

I wanna know how you did that work

can you tell me how you did that in detail somehow?