From owner-freebsd-gnome@FreeBSD.ORG Fri Apr 29 09:14:40 2011
Return-Path: <owner-freebsd-gnome@FreeBSD.ORG>
Delivered-To: gnome@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id 2598F106566C
for <gnome@freebsd.org>; Fri, 29 Apr 2011 09:14:40 +0000 (UTC)
(envelope-from
BATV+657967d02b08f50ffda4+2805+infradead.org+dwmw2@casper.srs.infradead.org)
Received: from casper.infradead.org (casper.infradead.org
[IPv6:2001:770:15f::2])
by mx1.freebsd.org (Postfix) with ESMTP id 72F468FC14
for <gnome@freebsd.org>; Fri, 29 Apr 2011 09:14:39 +0000 (UTC)
Received: from macbook.infradead.org ([2001:8b0:10b:1:216:eaff:fe05:bbb8])
by casper.infradead.org with esmtpsa (Exim 4.72 #1 (Red Hat Linux))
id 1QFjmd-0006UF-GU; Fri, 29 Apr 2011 09:14:43 +0000
From: David Woodhouse <dwmw2@infradead.org>
To: Matthias Apitz <guru@unixarea.de>
In-Reply-To: <20110429084846.GA2763@sh4-5.1blu.de>
References: <1303831016.6417.132.camel@macbook.infradead.org>
<20110426213920.GA15678@sh4-5.1blu.de>
<20110427062214.GA1159@sh4-5.1blu.de>
<20110428073857.GB4359@sh4-5.1blu.de>
<20110428131312.GA17412@sh4-5.1blu.de>
<1303998164.2912.123.camel@macbook.infradead.org>
<20110428140106.GA5664@sh4-5.1blu.de>
<1303999409.2912.129.camel@macbook.infradead.org>
<20110428145451.GA25158@sh4-5.1blu.de>
<1304003620.4772.16.camel@macbook.infradead.org>
<20110429084846.GA2763@sh4-5.1blu.de>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 29 Apr 2011 10:14:36 +0100
Message-ID: <1304068476.32168.20.camel@macbook.infradead.org>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14)
Content-Transfer-Encoding: 8bit
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by
casper.infradead.org See http://www.infradead.org/rpr.html
Cc: gnome@freebsd.org, evolution-list@gnome.org
Subject: Re: [Evolution] evolution-2.32.1 (FreeBSD HEAD) && calendar not
working
X-BeenThere: freebsd-gnome@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: GNOME for FreeBSD -- porting and maintaining
<freebsd-gnome.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-gnome>,
<mailto:freebsd-gnome-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-gnome>
List-Post: <mailto:freebsd-gnome@freebsd.org>
List-Help: <mailto:freebsd-gnome-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-gnome>,
<mailto:freebsd-gnome-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Apr 2011 09:14:40 -0000
On Fri, 2011-04-29 at 10:48 +0200, Matthias Apitz wrote:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 29804300 (LWP 101032/initial thread)]
> 0x29e55d87 in ?? ()
> (gdb) bt
> #0 0x29e55d87 in ?? ()
> #1 0x2910fb4d in g_hash_table_lookup_node (hash_table=0x29850e90,
> key=0x29ffc520) at ghash.c:252
OK, gdb lies about line numbers sometimes, and often you have to read
between the lines of what it's telling you. What we *can* trust, mostly,
is that g_hash_table_lookup_node()¹ called into some unknown function at
0x29e55d87.
> (gdb) p *hash_table
> $15 = {size = 8, mod = 7, mask = 7, nnodes = 0, noccupied = 0,
> nodes = 0x2a7f9b20, hash_func = 0x29e55d87, key_equal_func = 0x29e55d55,
> ref_count = 1, version = 0, key_destroy_func = 0, value_destroy_func = 0}
Oh look, 0x29e55d87 is what's set as the hash function in your hash
table. And that's where we ended up when we crashed?
Would be interesting to know where this *is*, given that gdb doesn't
seem to have a clue. In Linux I'd ask you to 'cat /proc/$PID/maps' and
see which mmap region it lies within.
> I *think* there is no correct function pointer in the hash_table because #0 is
> pointing in the air; but read_config() inserts one as:
>
> config_options = g_hash_table_new (e2k_ascii_strcase_hash,
> e2k_ascii_strcase_equal);
>
> (gdb) p e2k_ascii_strcase_hash
> $17 = {guint (gconstpointer)} 0x29fe16b7 <e2k_ascii_strcase_hash>
> (gdb) p e2k_ascii_strcase_equal
> $18 = {gint (gconstpointer,
> gconstpointer)} 0x29fe1685 <e2k_ascii_strcase_equal>
So how in hell did your hash_func get set to 0x29e55d87 <wtf> instead of
0x29fe16b7 <e2k_ascii_strcase_hash>?
(That isn't g_direct_hash(), is it?)
I'd put a breakpoint on read_config(), then step through until
immediately after the g_hash_table_new() call. Make sure the hash_func
and key_equal_func have been set to the correct values. If *not* then
dig deeper into g_hash_table_new() of course. But if they *are* OK, then
stick a hardware watchpoint on the hash_func and let it run.
If you get to the same crash, the actual hash table pointer is the same,
and the hash_func is *still* not what you set it to, call a priest.
It *could* be memory corruption; you could try running under valgrind
(make sure you set GSLICE=always-malloc or it gets horridly confused
with the gslice allocator).
--
dwmw2
¹ Or a static function that got inlined into g_hash_table_lookup_node()
but that wasn't it in this case, so I'm mentioning it just for
future reference.