Re: Improvement to g_on_error_stack_trace [PATCH]
- From: Tim Janik <timj gtk org>
- To: Nicolás Lichtmaier <nick technisys com ar>
- Cc: gtk-devel-list gnome org
- Subject: Re: Improvement to g_on_error_stack_trace [PATCH]
- Date: Thu, 18 May 2000 02:50:43 +0200 (CEST)
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
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
besides coding style issues, that patch seems ok to me for the most
part, but what's:
@@ -291,6 +304,12 @@
intended to do? generate a core dump on purpose? then we better
use G_BREAKPOINT (); there, i.e. SIGTRAP.
] [Thread Prev