- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you think this is the same bug as described here?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you think this is the same bug as described here?
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page