On Tue, 25 Jan 2000, Marc Lehmann <marc@xxxxxxxx> wrote: > On Mon, Jan 24, 2000 at 11:05:35AM -0500, Glyph Lefkowitz <glyph@xxxxxxxxxxxxxxxxx> 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
