Hi,
Toon Moene wrote:
On 04/09/2015 09:06 AM, Patrick Begou wrote:
I'm working on a large parallel fortran application which give
(sometime) a segfault. When this error occurs I would like to backtrace
the call stack to know where it takes place but I'm unable to get this
information, no more than a list of memory addresses. I've build a small
test-case (with an error in array dimension creating a segmentation
fault in a subroutine ) to investigate gfortran/gcc options.
With gcc version 4.8.2 using options "-g -fbacktrace -gdwarf-3" I get
./plante
[...]
You could also try to compile both your program and – if relevant – the
MPI (or other) libraries with "-fsanitize=address" (ASAN).
ASAN is available since GCC 4.8, cf.
https://gcc.gnu.org/gcc-4.8/changes.html ; GCC 4.9 also has the
undefined-behaviour sanitizer (UBSAN, -fsanitize=undefined), which
catches some other issues (like integer overflows; the Fortran support
is a bit lagging behind the C/C++ support). But your issue sounds more
like a candidate for ASAN.
For the full list of GCC 5 sanitizers (GCC 5 has extended them, esp. on
the UBSAN side), see
https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-gtoggle-647
Otherwise, you might be able to run the code in the debugger - and there
doing a backtrace might work - even in cases where addr2line failed.
I assume, you already tried it without success. Still: Does addr2line
work if you try the other addresses? Often using just the first address
didn't work - while the second or third did.
Tobias
PS: Don't run "valgrind" with an ASAN instrumented binary - that won't
work. Otherwise, "valgrind" is also a useful checking tool.