When an exception occurs I would like to terminate abnormally my program. Right now, when an exception happens a write statement with an explanatory sentence is called, and then a stop statement is called.
I am debugging the program with idb (intel debugger), when the exception happens I get the write statement, but idb treats the program as terminated normally. I would like that when the exception happens the program is terminated abnormally and so that I can look to the memory with backtrace in the place where the exception happened.
I have tried changing stop in stop 1, so that a non zero value is returned, but this doesn't work
EDIT:
I have implemented the solution in one of the answer:
interface
subroutine abort() bind(C, name="abort")
end subroutine
end interface
print *,1
call abort()
print *,2
end
with this solution I still do not get any backtrace when I am using ifort 13.0.1, but this works perfectly with ifort 14.0.2.
I have resorted to use idb instead of gdb, because often the latter cannot read the values of allocatable arrays in fortran.
There are non-standard extensions for this. Gfortran uses backtrace() to print a backtrace anywhere, for the Intel's equivalent see the wander95's answer https://stackoverflow.com/a/38905855/721644.
In ifort and gfortran you can call the abort() subroutine and you will get backtrace if you used the -traceback (Intel) or -g -fbacktrace (gfortran) compiler option.
You could also call the C abort() directly using the C interoperability. (also non-standard and may not work in all circumstances):
interface
subroutine abort() bind(C, name="abort")
end subroutine
end interface
print *,1
call abort()
print *,2
end
With Fortran 2008 the ERROR STOP statement has been introduced. It's mainly used for Coarray Fortran programs to initiate error termination on all images.
Found this old question by accident. If you want abnormal termination with the intel compiler, you can use the routine tracebackqq. The call sequence can be:
call TRACEBACKQQ(string=string,user_exit_code=user_exit_code)
To quote the manual:
Provides traceback information. Uses the Intel® Fortran run-time library traceback facility to generate a stack trace showing the program call stack as it appeared at the time of the call to TRACEBACKQQ( )
I've never used idb, I've only used gdb, so this might not work. I just put a read statement in at the error point, so that the program stops and waits for input. Then I can CTRL-C it, which causes gdb to pause execution, from which I can get a backtrace, move up and down the stack, look at variables, etc.
Related
I have a Fortran code which is predominantly used for running large MPI calculations, but occasionally I want to run it on a machine which does not have MPI available for quick data processing tasks.
I have a logical variable which determines whether or not the program is being run in MPI mode or not, and when it is false the code will not call any MPI subroutines. The way I determine whether or not to run in MPI mode at the moment is by testing to see if a dummy file "NO_MPI" exists which I dislike due to its inelegance and the fact that I usually forget that I need to create this file when running in a non-MPI environment.
When the code is run in a non-MPI environment the MPI_init subroutine will fail and cause the program to crash. So what I would like to do is call it with the optional error output:
call MPI_init(ierr)
and then if an error is returned continue with the node in non-MPI mode.
The issue is that the default MPI error handler will abort the program without returning an error. For any other MPI subroutine the solution would be:
call MPI_Comm_set_errhandler(MPI_COMM_WORLD, MPI_ERRORS_RETURN)
to tell MPI not to abort and return the error code. However I cannot call this subroutine before MPI_init without getting the error
Attempting to use an MPI routine before initializing MPICH.
Is there any way to change the default error handler before calling MPI_init, perhaps specifying it with a compiler flag? I am using the IFORT compiler with MPICH.
I feel that there must be some way of testing the error code from MPI_init, otherwise what is the point of allowing MPI_init to accept the optional error return as an argument when the default behaviour is to abort without returning errors?
While debugging using gdb, I am calling the nc_print function as
(gdb)call nc_print() but there is no output and no warning.
void nc_print()
{
printf("ramanuj\n");
}
I am finding that gdb fails to call the nc_print. I am not getting why is it happening. May i know the possible reason.
I am finding that gdb fails to call the nc_print.
Your conclusion that GDB did not call nc_print is likely wrong. If you add a call to abort() to nc_print, does your program abort? If so, your conclusion is wrong.
I am not getting why is it happening
What is most likely happening is that your inferior (being debugged) program has its stdout redirected to a file (or a pipe), and thus fully buffered.
Things will likely work as you expect them if you add fflush(stdout), or use fprintf(stderr, "ramanuj\n").
I'm seeing a problem in using gdb (actually I'm using ddd which is a grahpic debugger using gdb inside) which is that I cannot see a function's return value.
With a simple program, I could see that I can print a function's output. For example, if an object.peek() return an integer, if I type p object.peek(), then I get for example 1234. And I remember printing any values when I'm degging a C or C++ program.
I'm now running and analyzing a complex program which is a python program containing a shared object library written in C++. I can set a breakpoint in C++ code and follow steps. But when I try to see some functions' output like param.input_dim_size(), the debugger give me the output :
(gdb) p param.input_dim_size()
Warning:
Cannot insert breakpoint 0.
Error accessing memory address 0x232460: Input/output error.
An error occurred while in a function called from GDB.
Evaluation of the expression containing the function
(caffe::NetParameter::input_dim_size() const) will be abandoned.
When the function is done executing, GDB will silently stop.
Has is something to do with attaching two debuggers to the same program? or using C++ library inside Python? (I guess not). Or is there any restriction for seeing the output of functions in gdb?
#defineing _GLIBCXX_DEBUG forces GCC to catch a large class of runtime errors in C++, such as out-of-bounds STL access, invalid iterators, etc.
Unfortunately, when the error happens, the message printed is not very helpful. I know how to print a backtrace with a function, and __FILE__ and __LINE__ with a macro myself.
Is there an easy way to convince GCC to do that, or to specify a function/macro for it to call when the kind of errors that _GLIBCXX_DEBUG catches actually occur?
I assume you mean you want messages that print the context of use in your code, rather than the filename and line number of some internal header file used by GCC.
There appears to be a single macro in .../debug/macros.h that all the checking code uses called _GLIBCXX_DEBUG_VERIFY. You could modify it to suit your needs.
Edit: Jonathan Wakely points out that all checks are fatal.
When a Debug Mode check fails it calls abort(), so it dumps a core file which you can easily examine with a debugger to see where it failed. If you run the program in a debugger it will stop when it aborts and you can print the stack trace with backtrace.
To make that automatic you would need to change the call to abort() (in libstdc++-v3/src/c++11/debug.cc). I think you could change it to call std::terminate() and then install your own terminate_handler with set_terminate to make it print a backtrace.
I am trying to write a program that will stop whenever an invalid operation is performed, no matter how it is compiled with GFortran. With ifort I could do something like this:
use ieee_exceptions
....
logical :: halt
....
call ieee_get_halting_mode(IEEE_USUAL,halt)
call ieee_set_halting_mode(IEEE_USUAL,.True.)
....
! Something that may stop the program
....
call ieee_set_halting_mode(IEEE_USUAL,halt)
Does GFortran have a module similar to ifort's ieee_exceptions? Or even better is there a way of stopping the halting mode without knowing how the program will be compiled or which compiler will be used?
GFortran supports the ieee_exceptions module as of the GCC 5 release.
If you're stuck on an older GFortran release, a workaround would be to implement functions in C/asm that get/set the FP trapping status register and call those from Fortran.
PS.: GFortran does have a switch (-fpe-trap) for globally enabling traps for FP exceptions, see http://gcc.gnu.org/onlinedocs/gfortran/Debugging-Options.html . But, since you explicitly said "no matter how it is compiled with gfortran", I guess you don't want to use that.