From owner-freebsd-gnome@FreeBSD.ORG Sun Sep 26 18:33:45 2004 Return-Path: Delivered-To: freebsd-gnome@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B58A16A4CE for ; Sun, 26 Sep 2004 18:33:45 +0000 (GMT) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id D76FF43D4C for ; Sun, 26 Sep 2004 18:33:44 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 8EB19F1A2D; Sun, 26 Sep 2004 11:33:42 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99574-09; Sun, 26 Sep 2004 11:33:41 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id C3224F1834; Sun, 26 Sep 2004 11:33:41 -0700 (PDT) From: Sean McNeil To: Joe Marcus Clarke In-Reply-To: <1096089252.2433.7.camel@shumai.marcuscom.com> References: <1095267108.86712.2.camel@server.mcneil.com> <4148757E.8000101@marcuscom.com> <1095293014.76661.2.camel@server.mcneil.com> <1095299723.62093.18.camel@shumai.marcuscom.com> <1095305657.7380.10.camel@server.mcneil.com> <1095385263.19148.9.camel@shumai.marcuscom.com> <1095413153.57476.4.camel@server.mcneil.com> <1095833271.45253.55.camel@shumai.marcuscom.com> <1095834710.13428.9.camel@server.mcneil.com> <1095981030.22935.27.camel@shumai.marcuscom.com> <1095981948.59840.22.camel@server.mcneil.com> <1096089252.2433.7.camel@shumai.marcuscom.com> Content-Type: text/plain Message-Id: <1096223621.43615.22.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 26 Sep 2004 11:33:41 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-gnome@freebsd.org Subject: Re: seahorse crashes immediately X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2004 18:33:45 -0000 On Fri, 2004-09-24 at 22:14, Joe Marcus Clarke wrote: > On Thu, 2004-09-23 at 19:25, Sean McNeil wrote: > > On Thu, 2004-09-23 at 16:10, Joe Marcus Clarke wrote: > > > On Wed, 2004-09-22 at 02:31, Sean McNeil wrote: > > > > > > > This is what I got: > > > > > > Can you send the output of "bt full". Specifically, I want to know what > > > node is. Also, do you have malloc scrubbing enabled? If so, does it > > > still crash if you disable it? > > > > I've tried this with an /etc/malloc.conf of "aj" and without an > > /etc/malloc.conf. > > > > Here is the bt full: > > Thanks, but where is frame #0? Was caught up in some other things and I guess I got sloppy on cut/paste. Here is the first few frames again: (gdb) r Starting program: /usr/X11R6/bin/seahorse Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 100205)] 0x0000000202f55f8f in g_type_check_is_value_type (type=8595649152) at gtype.c:3249 3249 if (node && node->mutatable_check_cache) (gdb) bt full #0 0x0000000202f55f8f in g_type_check_is_value_type (type=8595649152) at gtype.c:3249 No locals. #1 0x0000000202f43faa in g_signal_newv (signal_name=0x0, itype=5714304, signal_flags=G_SIGNAL_RUN_LAST, class_closure=0x56f980, accumulator=0, accu_data=0x0, c_marshaller=0x1, return_type=4, n_params=1, param_types=0x569a00) at gsignal.c:1267 name = (gchar *) 0x569a10 "add" signal_id = 0 i = 0 node = (SignalNode *) 0x0 __PRETTY_FUNCTION__ = "g_signal_newv" #2 0x0000000202f44b98 in g_signal_new_valist (signal_name=0x41adec "add", itype=5714304, signal_flags=G_SIGNAL_RUN_LAST, class_closure=0x56f980, accumulator=0, accu_data=0x0, c_marshaller=0x1, return_type=1, n_params=1, args=0x7fffffffe2e0) at gsignal.c:1370 param_types = (GType *) 0x569a00 i = 5378304 signal_id = 4294959840 I've looked over the code and I think I know what is going on (maybe). GType is a gulong. This is 64 bits on amd64. There is a define #define SEAHORSE_TYPE_KEY (seahorse_key_get_type ()) that is passing what is suppose to be a GType as a vararg to g_signal_new. I did a break in seahorse_key_get_type and looked at what the key is suppose to be and I looked at the param_type[0] which is passed in: (gdb) p key_type $4 = 5714560 (gdb) p param_types[0] $5 = 8595649152 Cheers, Sean