On Tue, 25 Jan 2000, Marc Lehmann <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 24, 2000 at 11:05:35AM -0500, Glyph Lefkowitz <[EMAIL PROTECTED]>
> > Since the only advantage of this is the stack-trace for non-developers,
> The consensus was to remove it in release versions. So if the only advantage
> is for non-developers, why not remove it altogether?
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
attach to the process, but you also have some potential problems with
pointer grabs and so on.
Here is how I see it:
- 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
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. The same choices would be
available on the command-line regardless of the default value
choosen while compiling. The main advantage of the configure option
would be to set the default so that it is not necessary to use the
command-line option every time, and this could help those who build
- 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
they forgot to enable the stack trace (some heisenbugs can be
difficult to reproduce).
- The default for the "released" code (in tar files) for the
"unstable" versions would be "--enable-stack-trace=yes", so that the
users would get a stack trace that they could easily report (if they
have gdb) without having any nasty problems with pointer grabs.
- The default for the "released" code for the "stable" versions
(1.2.x) would be "--enable-stack-trace=no" because we expect that
the GIMP would never crash (ha!) and we hope that any crash occuring
while running the program could be reproduced by running it a second
time with the command-line option that enables the stack trace.
Note that this means some additional work for the person who builds
the releases, because it will be necessary to remember to change
configure.in before building the tar file. Hmmm... Now that I think
about it, maybe "make dist" could take care of this automatically.
Tricky, but possible, I think.
> (It must be removed from the plug-in anyway, since it cribbles over
> the signal handlers prepared by the plug-in, rendering signal handling
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)
so it should not be a problem. Also, using sigaction() instead of
signal() could ensure that all signals are propagated correctly, even
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.
> BTW: the stacktrace option has never worked on my machine(s), unless you
> call "endless loop" working. Also, I could never get out of that signal
> handler. Gimp just started to suck 100% cpu time when I tried to "e"xit.
> I doubt that this thing is useful for anybody (I tried it even on a stock
> redhat 6.1 system). It is a constant annoyance.
Hmmm... I had these endless loop problems some time ago with 0.99.x
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.