[9390] in The GTK GIMP ToolKit mailing list archive
[gtk-list] Re: Dumping core on SIGSEGV
daemon@ATHENA.MIT.EDU (Scott Stone)
Sun Oct 18 20:41:55 1998
Date: Mon, 19 Oct 1998 09:41:53 +0900 (JST)
From: Scott Stone <sstone@ume.pht.co.jp>
To: Gtk-List <gtk-list@redhat.com>
In-Reply-To: <19981016130636.F5124@linux.ataman.com>
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com
On Fri, 16 Oct 1998 beach@ataman.com wrote:
> On Fri, Oct 16, 1998 at 11:58:44AM -0700, Brandon Long wrote:
> > You can recompile gdk/gtk and edit gdk/gdk.c, the line:
> > /* If you don't want to use gdk's signal handlers define this */
> > /* #define I_NEED_TO_ACTUALLY_DEBUG_MY_PROGRAMS 1 */
> >
> > Perhaps it would be good to make this set in some other way than a
> > compile time option? Either enable it with --debug or something.
> >
> > I generally just run my application under gdb when I'm getting a
> > segfault, since gdb will grab the app when it happens and you can do a
> > backtrace, etc.
>
> This signal handling mechanism doesn't seem appropriate to me. I
> mean, what business does Gtk have with defining these kinds of
> handlers? Shouldn't it be the job of the application to define these
> things? Would it be possible to have this functionality set at
> run-time instead of compile-time?
The person that you're replying to just said exactly the same thing :) ..
I agree, i was perplexed when I found GTK handling my sigs for me, but I
usually implement that myself so I didn't find it very annoying.. I just
use gdb when I'm getting a segfault :)
--------------------------------------------------
Scott M. Stone <sstone@pht.com, sstone@turbolinux.com>
<sstone@pht.co.jp>
Head of TurboLinux Development/Systems Administrator
Pacific HiTech, Inc (USA) / Pacific HiTech, KK (Japan)
http://www.pht.com http://armadillo.pht.co.jp
http://www.pht.co.jp http://www.turbolinux.com
--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
