Re: [fortran, patch] Allow displaying backtraces from user code

[Janne Blomqvist <blomqvist dot janne at gmail dot com>]

On Sat, Dec 15, 2012 at 6:04 PM, Janus Weil <janus@gcc.gnu.org> wrote:
>> - I'd prefer to reverse the name, e.g. BACKTRACE_{SHOW,PRINT,SPLURGE},
>> to make it more "discoverable" when browsing the manual.
>> BACKTRACE_PRINT would have the advantage of matching backtrace_print()
>> from libbacktrace, but then again that function takes a couple of
>> arguments so perhaps it would cause more confusion than enlightenment.
>
> well, yeah. There was discussion about the naming before. I don't have
> a very strong opinion on  that, and I just used what is there in
> libgfortran, namely SHOW_BACKTRACE.

So far show_backtrace() is just an internal implementation detail in
libgfortran, as long as it's not completely retarded anything goes.
But when we make it part of the documented public API we should make
sure it has a good, descriptive name.

> IMHO any reasonably intelligent person would be capable of using the
> "search"-feature of his browser of pdf viewer to find any *BACKTRACE*
> name in the list of intrinsics, but I guess there is no harm in
> starting the name with BACKTRACE.

I think nowadays most people would hit google before explicitly
checking the manual.. :) Still, that's not an excuse for not
organizing things in a logical manner.

> So, in principle I'm fine with all your BACKTRACE_* variants (except
> for _splurge, maybe ;)
>
> Or, why not just (plain and simple) "BACKTRACE"?

The name is the same as backtrace() in glibc, but otherwise, sure why
not. _show/_print might be preferable in the sense that they convey
that stuff will be directly printed on the screen, rather than, say,
the procedure returning an array of strings with the stack trace info.

>> - As previously show_backtrace() was always followed by program
>> termination, we now need to ensure that it properly cleans up after
>> itself in case the application continues execution. In particular,
>> make sure it doesn't leak file descriptors, and that the addr2line
>> child process terminates properly.
>
> Good point. Do you have any particular suggestions about what would be
> needed in this direction? (You're probably much more familiar with the
> libgfortran code than I am.)

As a simple test, something like the following (untested) code might do:

program b
  integer :: i
  do i = 1, 100
     call backtrace_show
  end do
  read(*, *)
end program b

When the programs waits on user input, check with "ps -eFH" that your
a.out process (or whatever you call the binary) doesn't have any child
processes, then "ls /proc/[PID]/fd" and check that the process has
only 3 fd's (std{in,out,err}).


-- 
Janne Blomqvist