Thread Subject: Seg. violation: MEX with OpenMP on Linux Only!!!

This has been really frustrating.
I have a mex file written in CPP in which I use very basic OpenMP pragmas to parallelize a simple for loop.
I can compile the code on 3 major platforms: Windows, Linux and Mac both for 32 and 64 bit version of Matlab.

The resulting mex files work perfectly on Windows and Mac version and I can confirm the results with serial version of code.

However, running the code on any Linux flavor crashes Matlab. For Linux version I have tried my code on R2009b and 2010a versions.
Based on the crash log, it seems the problem starts from libpthread.

I also tried to compile my code using gcc version 4.2 (supported by Matlab) and 4.4, to no success.

I have put a portion of the log here in order to keep the post short but I can provide the whole thing if needed.

any hint and input is appreciated

MATLAB crash file:/home/hamid/matlab_crash_dump.8320
------------------------------------------------------------------------
       Segmentation violation detected at Thu Oct 7 16:51:39 2010
------------------------------------------------------------------------

Configuration:
  MATLAB Version: 7.9.0.529 (R2009b)
  MATLAB License: 207107
  Operating System: Linux 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:10:02 UTC 2010 i686
  GNU C Library: 2.11.1 stable
  Processor ID: x86 Family 6 Model 10 Stepping 5, GenuineIntel
  Virtual Machine: Java 1.6.0_12-b04 with Sun Microsystems Inc. Java HotSpot(TM) Client VM mixed mode
  Default Encoding: UTF-8

Fault Count: 1

Register State:
  eax = 000593d7 ebx = 0386cff4
  ecx = 00000004 edx = 00000000
  esi = 00000000 edi = 09dfbd58
  ebp = a26ff2e4 esp = a26ff2c8
  eip = 0386a772 flg = 00010246

Stack Trace:
  [0] 0x0386a772(0x09dfbd58, 4, 0x09dfbd58, 0xa26ff358)
  [1] 0x0386a8ab(0x09dfbd58, 0, 0, 0x03868d7e)
  [2] 0x03868e40(0x0379a9b0, 0xa26ffb70, 0xa26ffb70, 0xa26ffb70)
  [3] libpthread.so.0:0x009a696e(0xa26ffb70, 0, 0, 0)

------------------------------------------------------------------------
       Segmentation violation detected at Thu Oct 7 16:51:39 2010
------------------------------------------------------------------------

Configuration:
  MATLAB Version: 7.9.0.529 (R2009b)
  MATLAB License: 207107
  Operating System: Linux 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:10:02 UTC 2010 i686
  GNU C Library: 2.11.1 stable
  Processor ID: x86 Family 6 Model 10 Stepping 5, GenuineIntel
  Virtual Machine: Java 1.6.0_12-b04 with Sun Microsystems Inc. Java HotSpot(TM) Client VM mixed mode
  Default Encoding: UTF-8

Fault Count: 2

Register State:
  eax = 087d89a2 ebx = 014dbc38
  ecx = 00000e5b edx = c95f5e5b
  esi = a586d8f8 edi = 09b13b00
  ebp = 0000003f esp = 0379bfa8
  eip = 00877fd4 flg = 00010283

Stack Trace:


Segmentation violation occurred within signal handler.
Unable to complete stack trace (stack was probably corrupted)

"Hamid " <spam.wax@gmail.com> wrote in message <i8ld8q$p8h$1@fred.mathworks.com>...
> This has been really frustrating.
> I have a mex file written in CPP in which I use very basic OpenMP pragmas to parallelize a simple for loop.
> I can compile the code on 3 major platforms: Windows, Linux and Mac both for 32 and 64 bit version of Matlab.
>
> The resulting mex files work perfectly on Windows and Mac version and I can confirm the results with serial version of code.
>
> However, running the code on any Linux flavor crashes Matlab. For Linux version I have tried my code on R2009b and 2010a versions.
> Based on the crash log, it seems the problem starts from libpthread.
>
> I also tried to compile my code using gcc version 4.2 (supported by Matlab) and 4.4, to no success.
>
> I have put a portion of the log here in order to keep the post short but I can provide the whole thing if needed.
>
> any hint and input is appreciated

Is it possible to post your code, or a simplified version of it, that causes the error?

Is it possible that the OpenMP libraries used by your compiler are incompatible with other OpenMP libraries that MATLAB uses?

James Tursa

"James Tursa" <aclassyguy_with_a_k_not_a_c@hotmail.com> wrote in message
> Is it possible to post your code, or a simplified version of it, that causes the error?
> Is it possible that the OpenMP libraries used by your compiler are incompatible with other OpenMP libraries that MATLAB uses?

Thanks for the reply.
Certainly, but the odd thing is that adding a breakpoint where the mex file is called and then stepping over it works just fine and I can validate the results!!!

Here is the core of my code:

#ifdef _OPENMP
#pragma omp parallel default(none) \
private(i,j) \
        firstprivate(int_facets,int_points,tmpqp) \
shared(st,qp,nqp,tiny,facets_bbx,ntries,xMin,xMax,nee,npp,tt,pp)
#endif
{
#ifdef _OPENMP
        #pragma omp for nowait
#endif
        for (i=0; i<nqp; ++i) {
     for (j=0; j<3; tmpqp[j] = qp(i,j), ++j);
st[i] = isinvolume_randRay(tmpqp, pp, npp, tt, nee, tiny, facets_bbx, (int) ntries, xMin, xMax, int_facets, int_points);
     }
}
}

The 'isinvolume_randRay' function starts like this:

unsigned char isinvolume_randRay(double *p0, double *pp, unsigned long npp,
double *tt, unsigned long nee, double tiny,
double *myfacets_bbx, int numPerturb, double minX, double maxX,
std::vector<ULONG>& int_facets, std::vector<points>& int_points)
{
   
    unsigned char st;
    bool debug=false;
    int_facets.clear();
int_points.clear();


It basically tests if point p0(x,y,z) is within a closed triangulated surface defined by 'tt' and 'pp'


I believe OpenMP support was added to gcc 4.1 so I have tried gcc 4.2 and 4.4
on R2010a and R2009b

Dear Hamid,

> for (j=0; j<3; tmpqp[j] = qp(i,j), ++j);

Is j increased before or after assigning tempqp[j]?
I'm not sure if the behaviour is well defined.

Is qp a function or an array?
Are you really sure that the loop should be empty according to the trailing semicolon ?! The indentation of the code looks like you want to run the loop over the following section...

Kind regards, Jan

"Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message <i8lkub$67r$1@fred.mathworks.com>...

> > for (j=0; j<3; tmpqp[j] = qp(i,j), ++j);
> Is j increased before or after assigning tempqp[j]?
> I'm not sure if the behaviour is well defined.
>

My assumption is that j is increased after the assignment. This same code works just fine under Mac OSX in which I also use gcc compilers. I'll change it and see if it'll help.

> Is qp a function or an array?
> Are you really sure that the loop should be empty according to the trailing semicolon ?! The indentation of the code looks like you want to run the loop over the following section...

qp is an array and qp(i,j) is a macro defined as
#define qp(i,j) qp[i*ncol+j]

And yes, the loop is empty. It basically copies the i'th row of qp onto 'tmpqp'

Hamid,

Did you ever solve this problem? I have the same peculiar behaviour that I can step through the whole thing in the debugger with no problems. In contrast to you, I'm using FORTRAN but the characteristics of the problem are the same.

Any hints?

Does anyone know how to check what openMP libraries MATLAB uses? Should I be linking my intel openMP libraries into my mex file statically?

Cheers!

Tom

"Thomas Clark" wrote in message <j1k0lc$oma$1@newscl01ah.mathworks.com>...
> Hamid,
>
> Did you ever solve this problem? I have the same peculiar behaviour that I can step through the whole thing in the debugger with no problems. In contrast to you, I'm using FORTRAN but the characteristics of the problem are the same.
>

No, I gave up on it. Even Mathwork's support couldn't help.
Although I had a strong feeling it was related to compiler version mismatch.

Hi Guys

I've a similar problem but I haven't tried out with other platforms. I am currently using Linux with gcc version 4.4.4. To test openmp I wrote a simple code(example.cpp):

#include "mex.h"
#ifdef _OPENMP
#include <omp.h>
#endif

void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
    plhs[0] = mxCreateNumericMatrix(1, 1, mxDOUBLE_CLASS, 0);
    double *out = mxGetPr(plhs[0]);
    double *in = (double*)mxGetPr(prhs[0]);
    double d = *in;
    int c;

    #pragma omp parallel for num_threads(nt) default(shared) private(c) reduction(+:d)
     for (c = 0; c < 100000; ++c) {
            ++d;
     }
        *out = d;
}

where nt = number of thread.
Basically the code adds any number passed to it by 100000 and returns the same. When I set nt > 1 the program runs w/o errors, but when I try to free the mex file (i.e clear example) it returns a segmentation fault. I tried to debug this with gdb and the output when 'clear example' is typed is:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd77fe700 (LWP 7186)]
0x00007fffdca4955c in ?? ()
(gdb) where
#0 0x00007fffdca4955c in ?? ()
#1 0x00007fffdca47fe6 in ?? ()
#2 0x00007fffd77fe700 in ?? ()
#3 0x0000000000000000 in ?? ()

Another interesting observation was that when 'example' is run for the first time gdb shows (n-1) new threads created but after that any further runs of example does not create these new threads. Could this mean that openmp/matlab is not closing these threads?

PS: when nt = 1. the program has no problem whatsoever.

ANY HELP is most welcome

Hi,

I have found the following article on the net:
http://www.walkingrandomly.com/?p=1795

there, it states that using openMP inside the mexFunction does not work. You have to make a separate function for anything that uses openMP. For me, this worked quite well. Hope this helps.

Nico.

"Ujwal" wrote in message <j7sc3m$8je$1@newscl01ah.mathworks.com>...
> Hi Guys
>
> I've a similar problem but I haven't tried out with other platforms. I am currently using Linux with gcc version 4.4.4. To test openmp I wrote a simple code(example.cpp):
>
> #include "mex.h"
> #ifdef _OPENMP
> #include <omp.h>
> #endif
>
> void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
> {
> plhs[0] = mxCreateNumericMatrix(1, 1, mxDOUBLE_CLASS, 0);
> double *out = mxGetPr(plhs[0]);
> double *in = (double*)mxGetPr(prhs[0]);
> double d = *in;
> int c;
>
> #pragma omp parallel for num_threads(nt) default(shared) private(c) reduction(+:d)
> for (c = 0; c < 100000; ++c) {
> ++d;
> }
> *out = d;
> }
>
> where nt = number of thread.
> Basically the code adds any number passed to it by 100000 and returns the same. When I set nt > 1 the program runs w/o errors, but when I try to free the mex file (i.e clear example) it returns a segmentation fault. I tried to debug this with gdb and the output when 'clear example' is typed is:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffd77fe700 (LWP 7186)]
> 0x00007fffdca4955c in ?? ()
> (gdb) where
> #0 0x00007fffdca4955c in ?? ()
> #1 0x00007fffdca47fe6 in ?? ()
> #2 0x00007fffd77fe700 in ?? ()
> #3 0x0000000000000000 in ?? ()
>
> Another interesting observation was that when 'example' is run for the first time gdb shows (n-1) new threads created but after that any further runs of example does not create these new threads. Could this mean that openmp/matlab is not closing these threads?
>
> PS: when nt = 1. the program has no problem whatsoever.
>
> ANY HELP is most welcome

"Nico" wrote in message <ji5osa$29s$1@newscl01ah.mathworks.com>...
> Hi,
>
> I have found the following article on the net:
> http://www.walkingrandomly.com/?p=1795
>
> there, it states that using openMP inside the mexFunction does not work. You have to make a separate function for anything that uses openMP. For me, this worked quite well. Hope this helps.
>
> Nico.

I read the above cited article and I find it misleading. To recap here, the author states a Golden Rule about not calling any API functions inside of OpenMP code. Fine, I agree with that one (specifically anything that allocates memory). But then the author makes the statement that you can't have OpenMP code inside the same function body that also has API calls. Here is where I disagree. I am currently unaware of any such restriction. I do this all the time and it seems to work just fine (e.g., my MTIMESX submission on the FEX does this). I posted a comment on the above link and am awaiting a reply.

James Tursa

"James Tursa" wrote in message <ji69h1$3d$1@newscl01ah.mathworks.com>...
> "Nico" wrote in message <ji5osa$29s$1@newscl01ah.mathworks.com>...
> > Hi,
> >
> > I have found the following article on the net:
> > http://www.walkingrandomly.com/?p=1795
> >
> > there, it states that using openMP inside the mexFunction does not work. You have to make a separate function for anything that uses openMP. For me, this worked quite well. Hope this helps.
> >
> > Nico.
>
> I read the above cited article and I find it misleading. To recap here, the author states a Golden Rule about not calling any API functions inside of OpenMP code. Fine, I agree with that one (specifically anything that allocates memory). But then the author makes the statement that you can't have OpenMP code inside the same function body that also has API calls. Here is where I disagree. I am currently unaware of any such restriction. I do this all the time and it seems to work just fine (e.g., my MTIMESX submission on the FEX does this). I posted a comment on the above link and am awaiting a reply.
>
> James Tursa

Follow-up: The author re-wrote his code and confirmed that he does *not* have any problem with having OpenMP code and API code within the same function body. He deleted the paragraph that stated this supposed restriction from the article.

James Tursa