* [Bug libfortran/36044] user-requested backtrace
2008-04-25 12:20 [Bug libfortran/36044] New: user-requested backtrace jaydub66 at gmail dot com
@ 2008-04-27 18:44 ` fxcoudert at gcc dot gnu dot org
2008-04-28 15:45 ` jaydub66 at gmail dot com
` (4 subsequent siblings)
5 siblings, 0 replies; 11+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2008-04-27 18:44 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-04-27 18:43 -------
I think compiling with -fbacktrace and calling the STOP intrinsic should emit a
backtrace. Maybe not enough, but still useful.
--
fxcoudert at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fxcoudert at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libfortran/36044] user-requested backtrace
2008-04-25 12:20 [Bug libfortran/36044] New: user-requested backtrace jaydub66 at gmail dot com
2008-04-27 18:44 ` [Bug libfortran/36044] " fxcoudert at gcc dot gnu dot org
@ 2008-04-28 15:45 ` jaydub66 at gmail dot com
2008-04-28 16:42 ` burnus at gcc dot gnu dot org
` (3 subsequent siblings)
5 siblings, 0 replies; 11+ messages in thread
From: jaydub66 at gmail dot com @ 2008-04-28 15:45 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from jaydub66 at gmail dot com 2008-04-28 15:44 -------
(In reply to comment #1)
> I think compiling with -fbacktrace and calling the STOP intrinsic should emit a
> backtrace.
I don't think it does. Anyway I'm looking for a solution that keeps the program
running after the backtrace.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libfortran/36044] user-requested backtrace
2008-04-25 12:20 [Bug libfortran/36044] New: user-requested backtrace jaydub66 at gmail dot com
2008-04-27 18:44 ` [Bug libfortran/36044] " fxcoudert at gcc dot gnu dot org
2008-04-28 15:45 ` jaydub66 at gmail dot com
@ 2008-04-28 16:42 ` burnus at gcc dot gnu dot org
2008-04-28 21:37 ` tkoenig at gcc dot gnu dot org
` (2 subsequent siblings)
5 siblings, 0 replies; 11+ messages in thread
From: burnus at gcc dot gnu dot org @ 2008-04-28 16:42 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from burnus at gcc dot gnu dot org 2008-04-28 16:41 -------
> > I think compiling with -fbacktrace and calling the STOP intrinsic should
> > emit a backtrace.
I think it should not. For abort(), I think a backtrace is ok, but for STOP
there should be no backtrace. Using stop is a quite normal way to stop a
program because a condition has not be met, e.g
stop 'Could not file "inp"'
If one finds afterwards dozens of lines of backtrace the actual message is no
longer visible. In my opinion, ifort shows too often a backtrace.
> I don't think it does.
Try abort(). (Though I do not recall whether it works, I think it does.)
> Anyway I'm looking for a solution that keeps the
> program running after the backtrace.
This can be sometimes indeed be handy, though I have never used it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libfortran/36044] user-requested backtrace
2008-04-25 12:20 [Bug libfortran/36044] New: user-requested backtrace jaydub66 at gmail dot com
` (2 preceding siblings ...)
2008-04-28 16:42 ` burnus at gcc dot gnu dot org
@ 2008-04-28 21:37 ` tkoenig at gcc dot gnu dot org
2009-02-22 22:33 ` fxcoudert at gcc dot gnu dot org
2009-02-23 4:37 ` jvdelisle at gcc dot gnu dot org
5 siblings, 0 replies; 11+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2008-04-28 21:37 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from tkoenig at gcc dot gnu dot org 2008-04-28 21:36 -------
Confirmed, this would indeed be useful.
--
tkoenig at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tkoenig at gcc dot gnu dot
| |org
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2008-04-28 21:36:17
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libfortran/36044] user-requested backtrace
2008-04-25 12:20 [Bug libfortran/36044] New: user-requested backtrace jaydub66 at gmail dot com
` (3 preceding siblings ...)
2008-04-28 21:37 ` tkoenig at gcc dot gnu dot org
@ 2009-02-22 22:33 ` fxcoudert at gcc dot gnu dot org
2009-02-23 4:37 ` jvdelisle at gcc dot gnu dot org
5 siblings, 0 replies; 11+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2009-02-22 22:33 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from fxcoudert at gcc dot gnu dot org 2009-02-22 22:33 -------
(In reply to comment #3)
> Try abort(). (Though I do not recall whether it works, I think it does.)
Does not work. abort() raises a SIGABRT, and we only catch SIGSEGV, SIGBUS,
SIGILL and SIGFPE.
>> Anyway I'm looking for a solution that keeps the
>> program running after the backtrace.
One such solution that I can see (other than adding a new intrinsic) is to
modify the library to also catch SIGUSR2 and generate a backtrace when it's
received (untested patch below); that way, a backtrace can be emitted without
the code stopping, either
-- programmaticaly by calling the KILL and GETPID intrinsics, or the POSIX
functions via ISO_C_BINDING
-- by the user sending the signal from another terminal, to know where his
program is stuck
The only issue I see with that is that SIGUSR2 is a symbolic constant, not
available in Fortran code, so that the user needs to know what (potentialy
nonportable) signal number it corresponds to.
diff -rpu libgfortran/runtime/compile_options.c
libgfortran.new/runtime/compile_options.c
--- libgfortran/runtime/compile_options.c 2009-02-22 23:25:25.000000000
+0100
+++ libgfortran.new/runtime/compile_options.c 2009-02-22 23:30:20.000000000
+0100
@@ -73,6 +73,13 @@ handler (int signum)
desc = "Floating-point exception";
break;
#endif
+
+#if defined(SIGUSR2)
+ case SIGUSR2:
+ name = "SIGUSR2";
+ desc = "User-defined signal";
+ break;
+#endif
}
if (name)
@@ -80,6 +87,16 @@ handler (int signum)
else
st_printf ("\nProgram received signal %d.\n", signum);
+#if defined(SIGUSR2)
+ if (signum == SIGUSR2
+ && (options.backtrace == 1
+ || (options.backtrace == -1 && compile_options.backtrace == 1)))
+ {
+ show_backtrace ();
+ return;
+ }
+#endif
+
sys_exit (5);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libfortran/36044] user-requested backtrace
2008-04-25 12:20 [Bug libfortran/36044] New: user-requested backtrace jaydub66 at gmail dot com
` (4 preceding siblings ...)
2009-02-22 22:33 ` fxcoudert at gcc dot gnu dot org
@ 2009-02-23 4:37 ` jvdelisle at gcc dot gnu dot org
5 siblings, 0 replies; 11+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2009-02-23 4:37 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-02-23 04:37 -------
If anyone is looking into this, please let me know if there are any specific
posix calls needed that I should put into the gfc_posix module. ( Priority
wise.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044
^ permalink raw reply [flat|nested] 11+ messages in thread