Intel® Moderncode for Parallel Architectures
Support for developing parallel programming applications on Intel® Architecture.

Breakpoint error (159) during MPI run

Anders_S_1
New Contributor III
22,149 Views

Hi,

I am running Fortran programs under Windows 7 parallelized with Intel MPI.

Program 1 runs OK with size set to 1 and up to  8, respectively (four cores 4790K).

Program 2 runs OK for size=1 but for size=2-8 I get the error

forrtl: severe (159): Program Exception breakpoint .

I am compiling and linking the program i Visual Studio 2013.

I am using version Visual Fortran 64-bit 17.0.4 Package ID: w_comp_lib_2017.4.210.

Best regards

Anders S

0 Kudos
1 Solution
jimdempseyatthecove
Honored Contributor III
22,107 Views

>>What is the MPI configuration file used for in the Compiler Fortran language?

https://software.intel.com/en-us/forums/debug-solutions/topic/673726

https://software.intel.com/en-us/node/610381

>> I launch the program with mpiexec in a bat file

If you do this, you also must assure the environment is setup correctly. One way to do this is via the Start menu

Start | All Programs | Intel Parallel Studio XE 2017 | Compiler and Performance Libraries | Intel MPI Library | Intel64 Build Environment

Then CD to your application folder and execute the .bat file.

*** Note,

>>forrtl: severe (159): Program Exception breakpoint

When starting from the .bat, the MS VS debugger is not running, but the process terminated due to an exception.

Also, note that when configuring MS VS to start your application with mpiexec or mpirun, the your application starts as a separate process. IOW the process being debugged is mpiexec, and not your application.

Your build options indicated you included /traceback. Did the console window show any traceback information?

Note, you can use Attach to Running Process with Visual Studio Debugger.

https://msdn.microsoft.com/en-us/library/3s68z0b3.aspx

The trick is to attach to the process prior to crash.

One way to do this is to add a Fortran function, name it something like WaitingToGo, that returns .true.
Add to PROGRAM:

  DO WHILE(WaitingToGo())
  ENDDO

Assure that the subroutine is in a separate file
Assure that IPO is disabled

Now then you can now use mpiexec to start the process, specify 1 rank (1 process)
The program will now hang in an infinite loop.

Use the MS VS Attach to Running Process (link above), issue Break all, issue single step until you reach the CALL to WaitingToGo (the DO WHILE loop), then use the debugger to set next statement to statement following the ENDDO then continue,

*** Note, if you start multiple processes, you can launch a 2nd, 3rd, .. MS VS instance and attach to each of the spawned processes (assure that you attach to different ID's of the named process).

Coordinating the "continues" could be problematic with more than a few processes. For this I would suggest performing the WaitingToGo only from rank 0, then immediately following that have an MPI synchronization point. You can attach to the additional processes (from additional MS VS IDEs) and not issue the break all (and reposition the next statement).

Now then, when you continue the rank 0 process all the others resume. Then when the exception occurs, hopefully it will show up in one of the debuggers (shortly afterword one or more other processes may experience an MPI timeout, which you ignore).

Jim Dempsey

View solution in original post

0 Kudos
27 Replies
Anders_S_1
New Contributor III
7,325 Views

Sorry, here are the attached files

0 Kudos
jimdempseyatthecove
Honored Contributor III
7,325 Views

Try: cmd.exe

If that gives you an error, use C:\Windows\System32\cmd.exe

Jim Dempsey

0 Kudos
Anders_S_1
New Contributor III
7,325 Views

Hi Jim,

After change of cmd to C:\Windows\system32\cmd.exe I got a command window, not two graphic windows with text!

See attached files!

Maybe it is quicker for you to define a QuickWin application in VS and run my supplied subroutine? It seems to be sort of a trial-and-error process. 

Best regards

Anders S

0 Kudos
jimdempseyatthecove
Honored Contributor III
7,325 Views

The burden of the trial and error is a learning experience for you to bear. It is better for you to learn how to figure something out, as opposed to being told what to do and not learning anything from it.

Jim Dempsey

0 Kudos
Anders_S_1
New Contributor III
7,325 Views

Hi Jim,

I am ready to take that burden!  However, I tried a few ideas but they did not work.

Best regards

Anders S

0 Kudos
jimdempseyatthecove
Honored Contributor III
7,325 Views

I suggest you enter:

attach debugger to mpi process visual studio

.AND.

how to debug mpi windows program in visual studio

into the google search term.

Jim Dempsey

0 Kudos
Anders_S_1
New Contributor III
7,325 Views

Hi Jim,

I installed the debugger and found out via google search that I can attach the debugger by introducing a break in the program at a CALL MPI_BARRIER(...) command. 

Best regards

Anders S

0 Kudos
Reply