public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "burnus at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libfortran/29649] Force core dump on runtime library errors Date: Tue, 31 Oct 2006 15:54:00 -0000 [thread overview] Message-ID: <20061031155428.20277.qmail@sourceware.org> (raw) In-Reply-To: <bug-29649-9410@http.gcc.gnu.org/bugzilla/> ------- 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
next prev parent reply other threads:[~2006-10-31 15:54 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2006-10-30 12:21 [Bug fortran/29649] New: " sfilippone at uniroma2 dot it 2006-10-30 12:24 ` [Bug libfortran/29649] " fxcoudert at gcc dot gnu dot org 2006-10-30 12:30 ` P dot Schaffnit at access dot rwth-aachen dot de 2006-10-31 15:54 ` burnus at gcc dot gnu dot org [this message] 2006-10-31 16:01 ` fxcoudert at gcc dot gnu dot org 2006-10-31 16:03 ` fxcoudert at gcc dot gnu dot org 2006-10-31 18:37 ` burnus at gcc dot gnu dot org 2006-10-31 19:10 ` Andrew Pinski 2006-10-31 19:10 ` pinskia at physics dot uc dot edu 2006-11-02 23:42 ` pinskia at gcc dot gnu dot org 2006-11-02 23:52 ` fxcoudert at gcc dot gnu dot org 2006-11-19 14:58 ` fxcoudert at gcc dot gnu dot org 2007-01-02 14:30 ` fxcoudert at gcc dot gnu dot org 2007-01-02 15:10 ` burnus at gcc dot gnu dot org 2007-01-05 14:03 ` fxcoudert at gcc dot gnu dot org 2007-01-05 21:25 ` patchapp at dberlin dot org 2007-01-12 6:48 ` fxcoudert at gcc dot gnu dot org 2007-01-18 12:54 ` burnus at gcc dot gnu dot org 2007-01-18 12:56 ` burnus at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20061031155428.20277.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).