How to print a human-readable backtrace with nvfortran when an exception occurs?
First of all, let me acknowledge that this question is better asked on the NVIDIA Developer Forum. However, I cannot log in the forum because the verification email takes an eternity to arrive. So I try here in case someone knows the answer.
Here is a minimal example.
! test.f90
program test
implicit none
real :: a
a = tiny(a)
write (*, *) 1.0 / (a**2)
end program test
Unless you have a typo in your example nvfortran uses -traceback not -trace. Also, try -O0 -g. You best bet though is to let Ubuntu generate a core file and use gdb.
Sorry, I do not think there is a typo. I searched through the nvfortran manual but found no introduction to -traceback. Nevertheless, I tried it and got the following.
I agree that gdb + core would be a good solution. However, since my tests are conducted remotely via GitHub Actions in a non-interactive way, gdb is not really usable. I can only access the log files of the tests. It would be ideal if the compiler could print a human-readable backtrace (which can be recorded in the log), as most compilers do when invoked with -g.
I guess nvfortran also intends to do so, but either I have not found the correct way of invoking it, or the backtrace is not really human-readable (or I am not considered a human …).
Note that with the -traceback option one of the lines now identifies the file and line that the error occurred on, which is typically all you get from a traceback.
I found documentation for nvfortran that indicated that was the default, but would be turned off if certain compiler optimizations were invoked, but that does not seem to be correct from your results.
My own scripts and fpm --profile debug both add it:
Note that gdb(1) has many options for running in batch mode, and you can launch the application with gdb. Without trying it (so might be typos, but close) something like
gdb -batch -ex run -ex where -ex list -args "COMMAND ARGUMENTS"
may be enough. The -x option allows you to set up much more elaborate scripts. I used a script that was used in batch scripts for years that did something along those lines; but there was a trick to short-circuit it when it succeeded so subsequent commands were not run when the run was successful that I do not remember at the moment. The gdb(1) web page almost certainly has examples of running in batch. Assuming it is rerunnable and has a short run time on Linux/Unix
you can also say to run command and then only run it again if the initial run fails quite simply as
well, using something like
CMD ARGS || gdb CMD -args ARGS -ex run -ex where -batch
as an alternative to allowing and processing a dump. The details can vary, bugt gdb(1) is definitely usable in batch mode.
The new line in your output
/a.out(MAIN_: MAIN_ at /home/zaikunzhang/tmp/nv.f90:9) [0x401308]
now indicates to look at line nine in file nv.f90.
PS:
It was a long time ago I first heard “To err is Human. To really foul things up requires a computer.”. That has really held up well over the years.
