On Tue, 25 Jan 2000, Marc Lehmann <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 24, 2000 at 11:05:35AM -0500, Glyph Lefkowitz <[EMAIL PROTECTED]> 
>wrote:
> > 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
  binary packages.
- 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
> useless).

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.

-Raphael

Reply via email to