Date: Sun, 26 Sep 2004 11:33:41 -0700 From: Sean McNeil <sean@mcneil.com> To: Joe Marcus Clarke <marcus@marcuscom.com> Cc: freebsd-gnome@freebsd.org Subject: Re: seahorse crashes immediately Message-ID: <1096223621.43615.22.camel@server.mcneil.com> 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>
index | next in thread | previous in thread | raw e-mail
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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1096223621.43615.22.camel>