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 |
|
