Re: Improvement to g_on_error_stack_trace [PATCH]

[Tim Janik <timj gtk org>]

On Tue, 16 May 2000, [iso-8859-1] Nicolás Lichtmaier wrote:

> I'd like to use it in production services, to automatically log any core
> dump, but currently g_on_error_stack_trace lacks the flexibility needed,
> so I've done some modifications:

well, for production, it should be noted that these functions are
1) pretty non-portable, i.e. subject to fail on non-unix/non-gdb
   systems
2) not extremely reliable, i.e. may fail with future gdb versions and
   stand and fall with current gdb bugs
3) _can_ make a bad situation worse, e.g. by some gdb versions that tend
   to suck memory like a black hole for corrupted stacks.

> I renamed g_on_error_stack_trace() to g_on_error_stack_trace_x() and
> added two parameters, a file descriptor where the backtrace will be
> written to, and a flag to tell whether you want the process to be killed
> with SIGABRT after the trace is written.
> 
> I've created a g_on_error_stack_trace() call as a wrapper to the new
> one, to preserve backwards compatibility.
> 
> The name g_on_error_stack_trace_x() should be changed to something
> better (with the older name kept for backward compatibility). I would
> use something more simple as g_print_stack_trace() (why "on error"? "on
> error", as used in other languages, seem to imply that the function is
> setting a callback for the future, as signal() ).

those g_on_error_* functions used to have different and pretty namespace
polluting prefixes, so one day i changed them all to g_on_error/moved
them elsewhere. for your patch, i personally don't feel very strong about
keeping the current signature of g_on_error_stack_trace(), especially after
an LXR search on cvs.gnome.org reveals exactly 0 uses of that function.
so we may simply come with g_on_error_stack_trace() extended for an fd and
core dump option in 1.3.

> 
> Here is the patch (to the most current version of the files in the 1.3
> branch):

besides coding style issues, that patch seems ok to me for the most
part, but what's:


@@ -291,6 +304,12 @@
   close (in_fd[1]);
   close (out_fd[0]);
   close (out_fd[1]);
+
+  if(kill_process)
+    {
+      kill(getppid(),SIGABRT);
+    }
+
   _exit (0);
 #else
   abort ();

intended to do? generate a core dump on purpose? then we better
use G_BREAKPOINT (); there, i.e. SIGTRAP.

> 
> 

---
ciaoTJ