I think it's better to file it with the library.

I think a '-traceback' would be a very nice enhancement! (as you could then have the likes of 'ERRTRA' from Lahey or 'TRACEBACKQQ' from Compaq, I forgot how it translates with Intel...)

Nice idea.


coredumping is easy, simply call "abort()" or kill(0,SIGSEGV)"
and make sure that "ulimit -c" (csh: "limit core") shows a big enough number.
This is actually what NAG f95 does and has the advantage that one can easily investigate later. (And the stdout/stderr message can easily get be lost.)

We probably should implement this option first.
-ftrace=coredump or similar, or a envionment variable?
This is simple: Replacing the sys_exit() by if(coredump_option) abort() else sys_exit()  in lingfortran/runtime/error.c.


Providing a trace is rather difficult, especially obtaining the symbol information (what function in which file and which line), especially when it should work everywhere including some strange Unix systems or MingW.

Using the glibc one can use backtrace() and backtrace_symbols() to get e.g.
./a.out [0x40088a]
/lib64/libc.so.6 [0x2b6c713bd5b0]
However, this misses the symbol information such as the name of the routine (e.g. "main__") and especially line number and source file.

Using dlvsym one can obtain more information, but it is not part of POSIX.

Searching the internet, one can find e.g. the refdbg lib which does some backtracing, or gdb, which of cause does it as well. Some suggest something along the lines of "(a) got the current process' pid, (b) wrote a little gdb command script into a /tmp file which would attach to the process, bt, and detach, (c) ran system ("gdb --command=/tmp...") in the function, and (d) removed the file from /tmp."


If one seriously wants to have this feature, gdb-6.5/gdb/stack.c is probably a good starting point.

An alternative solution is to do it as g95 does: There Andy adds all needed information to a linked list, which contains filename and line.
This does not seem to work for my example and it slows down the program, but is easier and more portable than extracting the symbol information.

However, I'm more a fan of either coredumping (or, if someone wants to spend the time, of creating a real strack-tracing function as the comercial compilers [and gdb] have).

(In reply to comment #3)
> coredumping is easy, simply call "abort()" or kill(0,SIGSEGV)"

The usual signal to request a core dump is SIGQUIT.

> However, I'm more a fan of either coredumping

Same opinion here.

> (or, if someone wants to spend the time, of creating a real strack-tracing
> function as the comercial compilers [and gdb] have).

Using unwind is the way to go for a more serious solution. It's how java does it, for example (with addr2line to get file and line information). I had it working on x86 at some point:

http://www.eleves.ens.fr/home/coudert/unwind.diff

I think it's a good point for someone trying to work on that.

Created attachment 12519 [details]
Example of how to use unwind for backtrace purposes

The patch I was quoting in my previous comment; here, it will never disappear.

> Using unwind is the way to go for a more serious solution.
Looks nice as a starting point. (My biggest problem with developing this would be to find out whether it works on strange machines like Sparc, Windows etc.)

> It's how java does it, for example (with addr2line to get file
> and line information).

[to spare others the searching] addr2line is part of binutils. Using binutils' libbfd, resolving the symbols could be resolved compareably easily. (At least it looks like this, glancing at binutils/addr2line.c).


Thus, in total I think I would like to have the following in gfortran:

- Support for coredumps (compile time? Environment variable? The latter overwriting the former?)
[Advantage compile-time option: The core is there, if one needs it. Advantage run-time option: One can quickly turn it on, if needed.]

- Traceback support more or less as outlined above (comment 4, comment 3), which prints only the Hex address (similar to the unwind.diff, attachment 12519 [details]) or the backtrace_symbols() example in comment 3). One should mention the addr2line program in the manpage/manual.

- Optionally, linking with libbfd and providing symbol-resolved traceback.

Subject: Re:  Force core dump on runtime library errors

> - Support for coredumps (compile time? Environment variable? The latter
> overwriting the former?)
> [Advantage compile-time option: The core is there, if one needs it. Advantage
> run-time option: One can quickly turn it on, if needed.]
> 
> - Traceback support more or less as outlined above (comment 4, comment 3),
> which prints only the Hex address (similar to the unwind.diff, attachment
> 12519) or the backtrace_symbols() example in comment 3). One should mention the
> addr2line program in the manpage/manual.
> 
> - Optionally, linking with libbfd and providing symbol-resolved traceback.

Unless you want to make your program GPL, I would go against this.  This is why
for libgcj, they have not linked it in yet.

-- Pinski

PR 5773 is about addr2line in gcj.

We can fork+exec addr2line, but we can't link libbfd because it's GPL.

It was mentionned on IRC tonight that Daniel Berlin has a library that extracts line and file information from DWARF2 info. It's internal to Google, but he said he'll see if he can get it released. We'll have to get back to him in some time...

Working on this

(Just to make sure it is not forgotten:)
A draft patch was posted (quite a while ago) by FX:
http://gcc.gnu.org/ml/fortran/2006-11/msg00634.html

(In reply to comment #11)
> A draft patch was posted (quite a while ago) by FX:
> http://gcc.gnu.org/ml/fortran/2006-11/msg00634.html

I'd add that it's easy to separate the coredump part of the patch (handling of the option in the front-end & library, and the kill(SIGQUIT,...) line in the library), that is almost trivial, from the rest of the patch (the backtrace option), which has draft status itself.

Although I don't have time to write/regtest/submit this, I'll review such a patch if someone has time to submit it.

Subject: Bug number PR29649

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00431.html

Subject: Bug 29649

Author: burnus
Date: Thu Jan 18 12:54:11 2007
New Revision: 120897

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120897
Log:
2007-01-18  Francois-Xavier Coudert  <coudert@clipper.ens.fr>
            Tobias Burnus  <burnus@net-b.de>

       PR libfortran/29649
       * gfortran.h (gfc_option_t): Add flag_dump_core.
       * lang.opt: Add -fdump-core option.
       * invoke.texi: Document the new options.
       * trans-decl.c (gfc_build_builtin_function_decls): Add new
         options to the call to set_std.
       * options.c (gfc_init_options, gfc_handle_option): Set the
         new options.

2007-01-18  Francois-Xavier Coudert  <coudert@clipper.ens.fr>
            Tobias Burnus  <burnus@net-b.de>

       PR libfortran/29649
       * runtime/environ.c (variable_table): New GFORTRAN_ERROR_DUMPCORE
         environment variable.
       * runtime/compile_options.c (set_std): Add new argument.
       * runtime/error.c (sys_exit): Move from io/unix.c. Add coredump functionality.
       * libgfortran.h (options_t): New dump_core and backtrace members.
         (sys_exit): Move prototype.
       * io/unix.c (sys_exit): Move to runtime/error.c.
       * configure.ac: Add check for getrlimit.
       * configure: Regenerate.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/invoke.texi
    trunk/gcc/fortran/lang.opt
    trunk/gcc/fortran/options.c
    trunk/gcc/fortran/trans-decl.c
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/configure
    trunk/libgfortran/configure.ac
    trunk/libgfortran/io/unix.c
    trunk/libgfortran/libgfortran.h
    trunk/libgfortran/runtime/compile_options.c
    trunk/libgfortran/runtime/environ.c
    trunk/libgfortran/runtime/error.c

Fixed in the trunk.

Creating a backtrace is now PR 30498.