[Bug libfortran/30498] New: Support traceback (backtrace) on errors

[Bug libfortran/30498] New: Support traceback (backtrace) on errors

[burnus at gcc dot gnu dot org]

+++ This bug was initially created as a clone of Bug #29649 +++
Running an application I got the following error 
Fortran runtime error: Attempt to allocate negative amount of memory.  Possible
integer overflow

This is not very helpful in debugging, as it gives no clue as to where in the
code it occurred. It would be extremely helpful to have a way to force a
backtrace produced, either explicitly via stderr (as Intel Fortran does for
code compiled with -traceback), or implicitly by producing a core dump.
------------

The core dump has been implemented in bug #29649.

A draft patch, containing both the now-checked in core dumping and the
traceback can be found at http://gcc.gnu.org/ml/fortran/2006-11/msg00634.html

That patch calls the addr2line to translate the address to the file/line
number.  The library used by addr2line cannot be used as it is GPL. (Cf. PR
5773 for gcj.)

FX wrote in the initial PR:
"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..."


-- 
           Summary: Support traceback (backtrace) on errors
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: libfortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org
 BugsThisDependsOn: 29649


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

[Bug libfortran/30498] Support traceback (backtrace) on errors

[fxcoudert at gcc dot gnu dot org]

------- Comment #1 from fxcoudert at gcc dot gnu dot org  2007-01-18 17:59 -------
(In reply to comment #0)
> "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..."

I since spoke to him again, and we'd better go ahead with our current plan.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-01-18 17:59:49
               date|                            |


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

[Bug libfortran/30498] Support traceback (backtrace) on errors

[fxcoudert at gcc dot gnu dot org]

------- Comment #2 from fxcoudert at gcc dot gnu dot org  2007-02-07 09:08 -------
Created an attachment (id=13019)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13019&action=view)
Patch implementing the -fbacktrace option

Here's an updated version of the patch I submitted some time ago. I don't have
enough time to submit it, but if someone wants to take it and do whatever you
want to do with it, go ahead!


-- 


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

[Bug libfortran/30498] Support traceback (backtrace) on errors

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2007-02-07 09:47 -------
> Patch implementing the -fbacktrace option

I think one should add also some userhandler
  signal(SIGSEGV, my_segv_handler);
which calls show_backtrace and exits/coredumps then.

That way we calso get a backtrace for signalling arithmetic errors or for wrong
pointer accesses etc.


-- 


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

[Bug libfortran/30498] Support traceback (backtrace) on errors

[patchapp at dberlin dot org]

------- Comment #4 from patchapp at dberlin dot org  2007-02-08 20:30 -------
Subject: Bug number PR30498

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-02/msg00747.html


-- 


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

[Bug libfortran/30498] Support traceback (backtrace) on errors

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

------- Comment #5 from P dot Schaffnit at access dot rwth-aachen dot de  2007-02-09 07:44 -------

Hi!

This is great!

I cannot judge how much work this would be, but would it be possible to extend
this patch a little further so that these backtraces can be requested by the
user? (i.e. like the service routines 'ERRTRA' from Lahey, 'TRACEBACKQQ' from
Digital|Compaq|HP|Intel or 'Trace_Back_Stack_and_Print' from SGI). This way it
can also be used for user error handling...

Thanks!

Philippe


-- 


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

[Bug libfortran/30498] Support traceback (backtrace) on errors

[fxcoudert at gcc dot gnu dot org]

------- Comment #6 from fxcoudert at gcc dot gnu dot org  2007-02-09 08:15 -------
(In reply to comment #5)
> I cannot judge how much work this would be, but would it be possible to extend
> this patch a little further so that these backtraces can be requested by the
> user? (i.e. like the service routines 'ERRTRA' from Lahey, 'TRACEBACKQQ' from
> Digital|Compaq|HP|Intel or 'Trace_Back_Stack_and_Print' from SGI). This way it
> can also be used for user error handling...

It's very easy to implement, but should we add yet another GNU-specific
intrinsic?

Or maybe we could add have a GNU_EXTENSIONS module that would allow us to
access our GNU-specific intrinsics.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2007-02-07 09:08:46         |2007-02-09 08:15:58
               date|                            |


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

[Bug libfortran/30498] Support traceback (backtrace) on errors

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

------- Comment #7 from P dot Schaffnit at access dot rwth-aachen dot de  2007-02-09 08:25 -------

The Digital|Compaq|HP|Intel implementation goes for a module 'DFLIB', though I
have to admit I get lost with the pros and cons.

Regarding whether this should be implemented at all, I would be very
self-centered and point that several other compilers support this extension, so
there had to be enough people requesting it...


-- 


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

[Bug libfortran/30498] Support traceback (backtrace) on errors

[burnus at gcc dot gnu dot org]

------- Comment #8 from burnus at gcc dot gnu dot org  2007-02-09 09:55 -------
Hi,

> I cannot judge how much work this would be, but would it be possible to extend
> this patch a little further so that these backtraces can be requested by the
> user?

Well, this is possible if one combines this patch with the ISO C Bindings of
our fortran-experiments branch. One could then simply use:

   integer, parameter :: SIGBUS = 7
   integer :: res
   interface
     function kill(pid, signal) bind(c, name='kill')
        use :: ISO_C_BINDING
        integer(C_INT),value :: pid, signal
        integer(C_INT),bind(c) :: kill
     end function kill
   end interface
   res = kill(0,SIGBUS)

To get a backtrace. Alternatively, with the current patch and the main branch,
one only needs to generate somehow SIGSEGV, SIGFPE, SIGILL or SIGBUS. For
instance as follows:
 -ffpe-trap=zero -fbacktrace with
  r = 0.0
  r = 1.0/r
which gives a nice backtrace.


-- 


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

[Bug libfortran/30498] Support traceback (backtrace) on errors

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

------- Comment #9 from P dot Schaffnit at access dot rwth-aachen dot de  2007-02-09 10:05 -------

Hi!

I had indeed thought about using soem variation on '0. / 0.', but I find it
somewhat messy...

Somehow generating a kill from C does looks like a viable alternative though (I
would maybe not wait for the ISO C bindings and put that in an additional C
routine).

I nevertheless consider it only a second choice (though I could personally live
with it!).

Thanks a lot!

Philippe


-- 


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

[Bug libfortran/30498] Support traceback (backtrace) on errors

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

------- Comment #10 from P dot Schaffnit at access dot rwth-aachen dot de  2007-02-09 13:25 -------

In case anyone is interested: as mnetioned in Comment #8, just calling this
tiny C routine causes a traceback

#include <sys/types.h>
#include <signal.h>
void checktraceback_()
{
    kill ( (pid_t)0, SIGILL );
}


-- 


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

[Bug libfortran/30498] Support traceback (backtrace) on errors

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

------- Comment #11 from P dot Schaffnit at access dot rwth-aachen dot de  2007-02-21 11:58 -------

Hi!

I don't seem to be able to apply this patch to '122195' sources: did it get out
of synch, or is it plain clumsiness on my part?

I get:
Hunk #2 FAILED at 3151.
1 out of 2 hunks FAILED -- saving rejects to file gcc/fortran/trans-decl.c.rej
patching file gcc/fortran/options.c

This is probably very clear when one knows what it's all about, but
unfortunately that's not the case for me...

Thanks!

Philippe


-- 


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

[Bug libfortran/30498] Support traceback (backtrace) on errors

[burnus at gcc dot gnu dot org]

------- Comment #12 from burnus at gcc dot gnu dot org  2007-03-10 16:47 -------
Latest patch:
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00607.html


-- 


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

[Bug libfortran/30498] Support traceback (backtrace) on 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   |fxcoudert at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-02-09 08:15:58         |2007-03-14 22:11:52
               date|                            |


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

[Bug libfortran/30498] Support traceback (backtrace) on errors

[fxcoudert at gcc dot gnu dot org]

------- Comment #13 from fxcoudert at gcc dot gnu dot org  2007-03-15 12:57 -------
Commited to 4.3, closing.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.3.0


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

[Bug libfortran/30498] Support traceback (backtrace) on errors

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

------- Comment #14 from P dot Schaffnit at access dot rwth-aachen dot de  2007-05-14 10:06 -------

Hi!

Sorry about the noise, I'm wondering: the trick of using a tiny C routine:
kill ( (pid_t)0, SIGILL );
is there any obvious reason for that?

Thanks!

Philippe


-- 


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