Problems with try/catch/throw and OpenMP

Mark_Muller · ‎01-14-2010

I have been attempting to extend my exception handling to be compatable with some OpenMP functions. Along the way, I have encountered some perplexing segmentation faults. When I handle and exception and continue running. I have boiled it down into the following simple example:

[cpp]#include 
#include 

using namespace std;

int main()
{
  try {
    cout << "in main" << endl;
    try {
      cout << "testing error handling" << endl;
      throw exception();
      cout << "past test throw" << endl;
    }
    catch (exception &my_ex) {
      cout << "in main test driver l2 for my_ex" << endl;
    }
    cout << "past first set of try/catch" << endl;
    try {
      cout << "try testing alerts with a parallel construct" << endl;
      #pragma omp parallel for
      for (int i=0;i<10;i++) {
        try {
          #pragma omp critical
          {
            cout << " working on i = " << i << endl;
          }
        }
        catch (exception &my_ex) {
          #pragma omp critical
          {
            cout << "found an error" << endl;
          }
        }
      }
      cout << "after parallel section" << endl;
    }
    catch (exception &my_ex) {
      cout << "catching my_ex for main parallel test driver" << endl;
      throw;
    }
    cout << "past parallel alert test" << endl;
    return 0;
  }
  catch (exception &my_ex) {
    cout << "found an exception" << endl;
  }
  cout << "at end of program" << endl;
  return 0;
}
[/cpp]

If if compile this without openmp (icpc simple.cc), it runs fine. If I turn on OpenMP (icpc -openmp simple.cc), it segfaults with the following results:

[bash]kite 66% a.out
in main
testing error handling
Segmentation fault
kite 67% [/bash]

Valgrind points to the segfault occuring first catch - ie, before any OpenMP statements. The valgrind output is (when compileing with icpc -openmp -g simple.cc):

[bash]==310== Use of uninitialised value of size 8
==310==    at 0x401549: main (simple.cc:15)
==310== 
==310== Invalid write of size 8
==310==    at 0x401549: main (simple.cc:15)
==310==  Address 0x3e00000001 is not stack'd, malloc'd or (recently) free'd
==310== 
==310== Process terminating with default action of signal 11 (SIGSEGV)
==310==  Access not within mapped region at address 0x3E00000001
==310==    at 0x401549: main (simple.cc:15)
[/bash]

I really don't think I am doing anything wrong here. I first thought there was something wrong with one of my classes, but I have eliminated all of them in this example and the problem still exists. I think something is going wrong in the stack unwinding when -openmp is added in to the compile options. I have seen this with both versions 11.1.064 and 11.1.056 of the compiler, running and compiling on an x86 machine under Linux. My compiler specifically identifies itself as (icpc -V):

Intel C++ Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20091130 Package ID: l_cproc_p_11.1.064

For what it is worth, this example seems to work fine when compiled with g++ or with the intel compiler on an ia64 machine.

Mark Muller

markmuller@gmail.com

Judith_W_Intel · ‎01-14-2010

Do you think this is the same bug as described here?

http://www.thinkingparallel.com/2007/03/02/exceptions-and-openmp-an-experiment-with-current-compilers/

Mark_Muller · ‎01-14-2010

Quoting Mark Muller

Do you think this is the same bug as described here?

http://www.thinkingparallel.com/2007/03/02/exceptions-and-openmp-an-experiment-with-current-compilers/

It certainly looks similar. It looks even more similar to:

http://software.intel.com/en-us/forums/showthread.php?t=70145/

If I had to speculate, I would say they are all different manifestions of the same issue. The issue you linked at is somewhat troubling, as it from nearly three years ago.

Regards,

Mark Muller