From owner-freebsd-gnome@FreeBSD.ORG Thu Sep 16 03:34:21 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 2EDCB16A4CE for ; Thu, 16 Sep 2004 03:34:21 +0000 (GMT) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4A2C43D5A for ; Thu, 16 Sep 2004 03:34:18 +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 99315F1860; Wed, 15 Sep 2004 20:34:18 -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 81333-07; Wed, 15 Sep 2004 20:34:17 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id C4ADCF1808; Wed, 15 Sep 2004 20:34:17 -0700 (PDT) From: Sean McNeil To: Joe Marcus Clarke In-Reply-To: <1095299723.62093.18.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> Content-Type: text/plain Message-Id: <1095305657.7380.10.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 15 Sep 2004 20:34:17 -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: Thu, 16 Sep 2004 03:34:21 -0000 On Wed, 2004-09-15 at 18:55, Joe Marcus Clarke wrote: > On Wed, 2004-09-15 at 20:03, Sean McNeil wrote: > > On Wed, 2004-09-15 at 10:01, Joe Marcus Clarke wrote: > > > Please rebuild seahorse and libgnomeui with debugging symbols, and get > > > the full backtrace again. > > > > > > > With symbols for seahorse and libgnomeui: > > > > Backtrace was generated from '/usr/X11R6/bin/seahorse' > > Can you run this from gdb, and get the output of "bt full"? I don't see > the problem, and I can't reproduce it. > sure thing. The seg 11 is in glib, so I recompiled it with symbols: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 100163)] 0x0000000202f55f8f in g_type_check_is_value_type (type=8595649152) at gtype.c:3249 3249 gtype.c: No such file or directory. in gtype.c (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=0x5699f0) at gsignal.c:1267 name = (gchar *) 0x569a00 "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=0x7fffffffe2f0) at gsignal.c:1370 param_types = (GType *) 0x5699f0 i = 5378304 signal_id = 4294959856 #3 0x0000000202f43382 in g_signal_new (signal_name=0x41adec "add", itype=5714304, signal_flags=G_SIGNAL_RUN_LAST, class_offset=160, accumulator=0, accu_data=0x0, c_marshaller=0x1, return_type=4, n_params=1) at gsignal.c:1130 ---Type to continue, or q to quit--- args = {{gp_offset = 48, fp_offset = 48, overflow_arg_area = 0x7fffffffe420, reg_save_area = 0x7fffffffe310}} signal_id = 4304364 __PRETTY_FUNCTION__ = "g_signal_new" #4 0x00000000004131c4 in seahorse_context_class_init (klass=0x56be00) at seahorse-context.c:109 gobject_class = (GObjectClass *) 0x56be00 #5 0x0000000202f511fb in type_class_init_Wm (node=0x573180, pclass=0x0) at gtype.c:1907 slist = (GSList *) 0x0 init_slist = (GSList *) 0x541180 class = (GTypeClass *) 0x56be00 entry = (IFaceEntry *) 0x0 bnode = (TypeNode *) 0x0 pnode = (TypeNode *) 0x541180 i = 0 __PRETTY_FUNCTION__ = "type_class_init_Wm" #6 0x0000000202f52f4f in g_type_class_ref (type=5509504) at gtype.c:2404 ptype = 5509504 pclass = (GTypeClass *) 0x528d00 node = (TypeNode *) 0x573180 #7 0x0000000202f35870 in g_object_newv (object_type=5714304, n_parameters=0, parameters=0x0) at gobject.c:857 ---Type to continue, or q to quit--- cparams = (GObjectConstructParam *) 0x20054b000 oparams = (GObjectConstructParam *) 0x200540e00 nqueue = (GObjectNotifyQueue *) 0x0 object = (GObject *) 0x200540c00 class = (GObjectClass *) 0x0 unref_class = (GObjectClass *) 0x0 slist = (GSList *) 0x0 n_total_cparams = 0 n_cparams = 0 n_oparams = 0 n_cvalues = 4294961152 cvalues = (GValue *) 0x200540000 clist = (GList *) 0x0 i = 0 __PRETTY_FUNCTION__ = "g_object_newv" #8 0x0000000202f36247 in g_object_new_valist (object_type=5714304, first_property_name=0x0, var_args=0x7fffffffe800) at gobject.c:984 class = (GObjectClass *) 0x0 params = (GParameter *) 0x0 name = (const gchar *) 0x7fffffffe998 "\177" object = (GObject *) 0x0 n_params = 0 n_alloced_params = 16 ---Type to continue, or q to quit--- __PRETTY_FUNCTION__ = "g_object_new_valist" #9 0x0000000202f356c7 in g_object_new (object_type=5714304, first_property_name=0x0) at gobject.c:822 var_args = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x7fffffffe8f0, reg_save_area = 0x7fffffffe820}} __PRETTY_FUNCTION__ = "g_object_new" #10 0x00000000004139eb in seahorse_context_new () at seahorse-context.c:288 No locals. #11 0x0000000000408f42 in main (argc=1, argv=0x7fffffffe998) at main.c:124 sctx = (SeahorseContext *) 0x418b77 err = 32767 new_path = (gchar *) 0x7fffffffe998 "\177" There are some bad characters in the new_path line above that will not cut/paste. There are 5 unprintable blocks before the \177. It is passed up as "name" to g_object_new_valist. This might be an issue with varargs. On the amd64 and other processors (i.e. not x86) a va_list gets passed by reference instead of copy. This can cause issues if someone expects the arg pointer to be at the beginning after it is passed to a function that uses it. Sean