1

I'm writing a scientific program to solve Maxwell's equation with C++. The task in data parallel and I want to use OpenMP to make the program parallel. But when I use OpenMP to parallelise a for loop in side a function it. When I run my code the program gets SIGABRT. I couldn't find out went wrong. Please help.

The for loop is as follows:

#pragma omp parallel for

for (int i = 0; i < totalNoOfElementsInSecondMesh; i++) {

    FEMSecondMeshElement2D *secondMeshElement = (FEMSecondMeshElement2D *)mesh->secondMeshFEMElement(i);

    if (secondMeshElement->elementType == FEMDelectricElement) {

        if (solutionType == TE) 
            calculateEzFieldForDielectricElement(secondMeshElement, i, currentSecondMeshIndex, nextFirstMeshIndex);
        else
            calculateHzFieldForDielectricElement(secondMeshElement, i, currentSecondMeshIndex, nextFirstMeshIndex);

    } else if (secondMeshElement->elementType == FEMXPMLDielectricElement) {

        if (solutionType == TE) 
            calculateEzFieldForDielectricPMLElement((FEMPMLSecondMeshElement2D *)secondMeshElement, i, currentSecondMeshIndex, nextFirstMeshIndex);
        else
            calculateHzFieldForDielectricPMLElement((FEMPMLSecondMeshElement2D *)secondMeshElement, i, currentSecondMeshIndex, nextFirstMeshIndex);

    }

}

The compiler is llvm-gcc which came with Xcode 4.2 by default.

Please help.

Raiyan Kabir
  • 1,016
  • 2
  • 11
  • 23
  • Did you ever solve this? I'm having some strange issues like this with lion, llvm-gcc and OpenMP too... – hanno Feb 23 '12 at 19:50

3 Answers3

1

It is possible you've run into a compiler problem on Lion. See this link:

https://plus.google.com/101546077160053841119/posts/9h35WKKqffL

You can download gcc 4.7 pre-compiled for Lion from a link on that page, and that seems to work fine.

RWCox
  • 26
  • 1
0

Did you try to compile your program with debugging and all warnings, i.e. with -g -Wall flags?

Then you can use a debugger (that is, gdb) to debug it.

You can enable core(5) dumps (by setting appropriately, with setrlimit(2) or the ulimit shell builtin which calls it, the RLIMIT_CORE). Once you have a core file, gdb can be used for post-mortem analysis. And there is also gcore(1) to force a core dump.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • I'm debugging with Xcode. When I ask it to run the program it runs and randomly getting this SIGABRT signal. Its not getting is at the same for loop variable i, on every run its getting the signal in a different value of i. Can it be for calling different functions in side the for loop? – Raiyan Kabir Nov 11 '11 at 13:56
  • Can't you ask for `core` files to be dumped (by setting an appropriate limit with e.g. the `ulimit` builtin of your shell), and e.g. use `gdb` on the post-mortem core dump? – Basile Starynkevitch Nov 11 '11 at 14:13
  • @BasileStarynkevitch bit dated but how do I do that? Having the same problem with seemingly too many firstprivate variables – Hirek Jan 07 '19 at 23:04
0

The most likely reason that your program crashes is memory corruption when accessing FEMSecondMeshElement2D* secondMeshElement, currentSecondMeshIndex or nextFirstMeshIndex depending what the other functions in the if clause do to them.

I recommend to check carefully the access of variables and declare them thread private / shared properly, beforehand. e.g.

FEMSecondMeshElement2D *secondMeshElement = NULL;

#pragma omp parallel for private(secondMeshElement)
...
Bort
  • 2,423
  • 14
  • 22
  • Dear Bort, as you can see I'm calling methods within for loop block, how should I declare those variables before the mop parallel loop. Can you suggest a way? – Raiyan Kabir Nov 11 '11 at 17:24
  • nextFirstMeshIndex is currently defined outside of the loop. So when it enters the loop it is shared among all processes. If this is supposed to be a private index for each thread you need to add it to the private pragma as in my answer. `#pragma omp parallel for private(secondMeshElement, nextFirstMeshIndex)`. etc.. If you need to do thread private memory allocations, you can start the parallel region with `pragma omp parallel`, do necessary local memory allocations and call `pragma omp for` on the loop. – Bort Nov 11 '11 at 18:36
  • Think about your vars as follows if you write to them from more than one thread, you have to make them private otherwise you get memory corruption. Thread private means, that each thread has its own local copy of it. If you need some return value of that thread private variable I suggest to use an array[ of size omp_get_num_threads()] of the return value and reduce the result after the loop. Alternatively look up reduce. btw. i in the for loop is automatically thread private by default. – Bort Nov 11 '11 at 18:43
  • Dear Bort, First of all I'm doing no memory allocation in any of the parallel branches. I'm creating pointers and using pointers to point preallocated shared array. nextFirstMeshIndex is fixed valued for the parallel for loop as a result, there is no need of making it private. I just tried to use omp parallel in each of the function I'm calling. But that didn't do it either. I'm having another issue with Xcode. It cannot find omp.h even if I enable openMP. – Raiyan Kabir Nov 11 '11 at 19:39
  • Do you write to nextFirstMeshIndex in the calculateFieldFunctions? Sry, I am not using Xcode but that sounds like openmp headers are missing. I cannot help you there. – Bort Nov 11 '11 at 20:07