[Bug libfortran/29649] Force core dump on runtime library errors

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2006-10-30 12:24 
---
I think it's better to file it with the library.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|fortran |libfortran
 Ever Confirmed|0   |1
   GCC host triplet|i686-pc-linux-gnu   |
 GCC target triplet|i686-pc-linux-gnu   |
   Last reconfirmed|-00-00 00:00:00 |2006-10-30 12:24:41
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649

[Bug libfortran/29649] Force core dump on runtime library errors

[P dot Schaffnit at access dot rwth-aachen dot de]

--- Comment #2 from P dot Schaffnit at access dot rwth-aachen dot de  
2006-10-30 12:29 ---

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...)


-- 

P dot Schaffnit at access dot rwth-aachen dot de changed:

   What|Removed |Added

 CC||P dot Schaffnit at access
   ||dot rwth-aachen dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649

[Bug libfortran/29649] Force core dump on runtime library errors

[fxcoudert at gcc dot gnu dot org]

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2006-10-31 16:01 
---
(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.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2006-10-30 12:24:41 |2006-10-31 16:01:05
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649

[Bug libfortran/29649] Force core dump on runtime library errors

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2006-10-31 15:54 ---
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).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649

[Bug libfortran/29649] Force core dump on runtime library errors

[fxcoudert at gcc dot gnu dot org]

--- Comment #5 from fxcoudert at gcc dot gnu dot org  2006-10-31 16:02 
---
Created an attachment (id=12519)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12519&action=view)
Example of how to use unwind for backtrace purposes

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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649

[Bug libfortran/29649] Force core dump on runtime library errors

[burnus at gcc dot gnu dot org]

--- Comment #6 from burnus at gcc dot gnu dot org  2006-10-31 18:37 ---
> 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) 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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649

[Bug libfortran/29649] Force core dump on runtime library errors

[pinskia at physics dot uc dot edu]

--- Comment #7 from pinskia at physics dot uc dot edu  2006-10-31 19:10 
---
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649

[Bug libfortran/29649] Force core dump on runtime library errors

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2006-11-02 23:42 ---
PR 5773 is about addr2line in gcj.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||5773


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649

[Bug libfortran/29649] Force core dump on runtime library errors

[fxcoudert at gcc dot gnu dot org]

--- Comment #9 from fxcoudert at gcc dot gnu dot org  2006-11-02 23:52 
---
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...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649

[Bug libfortran/29649] Force core dump on runtime library errors

[fxcoudert at gcc dot gnu dot org]

--- Comment #10 from fxcoudert at gcc dot gnu dot org  2006-11-19 14:58 
---
Working on this


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-10-31 16:01:05 |2006-11-19 14:58:12
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649

[Bug libfortran/29649] Force core dump on runtime library errors

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649

[Bug libfortran/29649] Force core dump on runtime library errors

[burnus at gcc dot gnu dot org]

--- Comment #11 from burnus at gcc dot gnu dot org  2007-01-02 15:10 ---
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649

[Bug libfortran/29649] Force core dump on runtime library errors

[fxcoudert at gcc dot gnu dot org]

--- Comment #12 from fxcoudert at gcc dot gnu dot org  2007-01-05 14:03 
---
(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.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2006-11-19 14:58:12 |2007-01-05 14:03:30
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649

[Bug libfortran/29649] Force core dump on runtime library errors

[patchapp at dberlin dot org]

--- Comment #13 from patchapp at dberlin dot org  2007-01-05 21:25 ---
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649

[Bug libfortran/29649] Force core dump on runtime library errors

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649

[Bug libfortran/29649] Force core dump on runtime library errors

[burnus at gcc dot gnu dot org]

--- Comment #14 from burnus at gcc dot gnu dot org  2007-01-18 12:54 ---
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  <[EMAIL PROTECTED]>
Tobias Burnus  <[EMAIL PROTECTED]>

   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  <[EMAIL PROTECTED]>
Tobias Burnus  <[EMAIL PROTECTED]>

   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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649

[Bug libfortran/29649] Force core dump on runtime library errors

[burnus at gcc dot gnu dot org]

--- Comment #15 from burnus at gcc dot gnu dot org  2007-01-18 12:56 ---
Fixed in the trunk.

Creating a backtrace is now PR 30498.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn|5773|
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649

Re: [Bug libfortran/29649] Force core dump on runtime library errors

[Andrew Pinski]

> - 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