On Tue, Jan 25, 2000 at 06:55:28PM +0100, Raphael Quinet <[EMAIL PROTECTED]> wrote:
> There is a difference between having the stack trace and having the
> program asking you if you want a stack trace...  The latter is more
> useful for developers because you can also choose to start gdb and

Sorry, but _developers_ can always use gdb on the corefile. Having a
signal handler just destroys the stack frame (and the backtrace) in many
cases (here it almost always does).

> - I like Yosh's suggestion to have a configure option that allows to
>   choose between "yes/no/query" for the stack trace.  The "yes" option

The problem is that (shell-started) perl plug-ins always suffer from the
backtrace, so a configure option wouldn't help.

>   triggers a direct call to g_on_error_stack_trace() when a SIGSEGV is
>   received, the "no" option exits immediately, and the "query" option
>   calls g_on_error_query() as it does now.

Why is that signal handler installed at all, I ask? The signal destroys
the stacktrace anyway. Why caqtch sigsegv at all? Why _exit_, and not dump
core with all trace and ip information intact?

>   available on the command-line regardless of the default value

That's nicer, but I think the signals shouldn't be caught at all if it
is "no". It just shoots the developer in the foot. A commandline option
would, however, solve my and Jens' problems immediately (well, almost, as
I need to autodetect that case somehow).

A commandline option would also have no effects on the plug-ins itself, which
suffer from exactly the same problem.

> - The default for the code in CVS would always be "query".  This
>   ensures that all developers (those who use the CVS code) can easily
>   debug the code without having to re-start with different options if

I really do not understand this. The stacktrace simply does not work.
Attaching a debugger is much better, but still: the core file a segv would
create would be _far_ more reliable.

I buy the argument that users can do bug reports better with an automatic
stacktrace, but I don't buy that it makes it easier for developers.

> What is the problem exactly?  Most plug-ins do not install a special
> handler for SIGSEGV (actually, I don't remember any plug-in doing that)

Yes, but they do so for HUP, QUIT, INT, PIPE and TERM.

> if there was a handler installed previously.  If you have a more
> specific problem, please explain it because I do not see what is wrong
> with the current plug-ins.

The libgimp overwrites signal handlers after they have been set up
(somewhere in gimp_main). That requires that I use sigaction calls rather
than using perl's own methods.

> and an old version of glib, but I haven't seen any similar problem in
> the past year.  Also, the stack trace and the option to attach the
> debugger have both been very useful for me when I had some crashes
> under Solaris.  Anyway, you could use the new command-line option to
> disable the stack trace if this is causing some problems.

Your proposal is a very good first step, and something lie that would be
a workaround for the problems. However, I still think that the stacktrace
code has done more harm than use, and I will never understand why
mindlessly scribbling over 8 signals just because you are a gimp plug-in
is ever going to help.

> Hmmm...  I had these endless loop problems some time ago with 0.99.x

The endless loop problems are most probably caused because, after a
sigsegv, it does no good to do I/O, fork, start other processes, do stdio
input etc..

After fputs(0xdeadbeaf,stdout), for example, I wouldn't expect a signal
handler to do anything except exit.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       [EMAIL PROTECTED] |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Reply via email to