- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Tags:
- Parallel Computing
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>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
Link Copied
- « Previous
-
- 1
- 2
- Next »
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Try: cmd.exe
If that gives you an error, use C:\Windows\System32\cmd.exe
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jim,
I am ready to take that burden! However, I tried a few ideas but they did not work.
Best regards
Anders S
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
-
- 1
- 2
- Next »