Activating OpenMP for VC 2008 project causes process/threads to exit abruptly

[krakaw]

I have an application with a console event handler routine which performs a clean shutdown. When OpenMP support/functionality is activated on one of the dlls (VC 2008 project) the event handler routine is never called and the process and its threads exit in quick succession each with pretty much the same error:

The thread 'queue' (0x15a8) has exited with code -1 (0xffffffff).
The thread 'Win32 Thread' (0x16d0) has exited with code -1 (0xffffffff).
The thread 'Win32 Thread' (0x440) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0x129c) has exited with code 3 (0x3).
The thread 'capture' (0x14ec) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0x354) has exited with code 3 (0x3).
The thread 'Comm2' (0xe00) has exited with code 3 (0x3).
The thread 'Comm1' (0x10a8) has exited with code 3 (0x3).
The thread 'IpReceiver' (0xa84) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0x1040) has exited with code 3 (0x3).
The thread 'IpMon' (0x11cc) has exited with code 3 (0x3).
The thread 'IpReceiver' (0xd04) has exited with code 3 (0x3).

When OpenMP support is deactivated. The process exits normally.

Given that I am rather new to OMP what will be best approach to troubleshooting such a problem.

Thanks

[jimdempseyatthecove]

Is you main thread issuing an exit, abort, otherSystemCall to terminate as opposed to returning up the call tree and then issuing return from main?

Secondly: Assuming you are returning as above, did you spawn other threads and then delete objects inuse by those threads prior to notifying threads to gracefully exit (and then waiting for them to exit)?

Jim Dempsey

[krakaw]

Main thread waits for Ctrl+C event notification to start termination sequence and return from main.

The termination sequence terminates all threads gracefully before returning from main.

Kurien

[jimdempseyatthecove]

Obviously something is not very graceful.

Assume that (or you can configure such that) your Ctrl-C event sets a global flag which is tested by all threads (OpenMP and non-OpenMP). When this flag is observed to be set (your intentions are for) your code to exit gracefully.

While your debug version of your program is running at the point where you previously experienced the termination errors, set a breakpoint in your main thread loop (or press what looks like a pause (||) button if in VS). Then use the debugger to set the Ctrl-C seen global flag. Then continue your program and see what happens.

IOW remove the actual Ctrl-C event from the termination issue. (eliminate O/S from the picture)

My guess is you will still observe the problem (but will have eliminated an O/S issue).

Assuming you still have a problem, then this is a clear indication that you have a programming error in your termination code.

Are you by chance exiting a parallel region by bypassing the end of the parallel region?

Using the previously provided termination report to identify the problem threads, place a break point in each of these threads at the action point when Ctrl-C is detected. IOW break when each of these threads detects Ctrl-C.

Now, either these threads will detect the Ctrl-C (global flag) or they will misteriously and abnormally terminate. If they (or some of) abnormally terminate then you have to figure our why (e.g. break point in wrong position, or other code terminating thread). If they reach the break point, then follow each threads path out to exit to see what is happening.

Notes:

If your bail-out is using throw (C++), then throw executed inside a parallel region must cause execution to resume within the dynamic extent of the same structured block, and it must be caught by the same thread that threw the exception.

A parallel for loop must NOT be terminated with break; (or return or throw out of loop)

A barrier (implicit or explicit)MUST be reached by all threads if any threads reach the barrirer. Therefore your Ctrl-C bailout cannot circumvent a thread from reaching a barrier that was reached by any other(s) of its team members.

What may have been a graceful exit in single threaded environment may not be gracefull in multi-threaded environment.

Jim Dempsey