From owner-freebsd-gnome@FreeBSD.ORG Fri Apr 29 09:14:40 2011 Return-Path: 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 ; 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 ; 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 To: Matthias Apitz 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > (gdb) p e2k_ascii_strcase_equal > $18 = {gint (gconstpointer, > gconstpointer)} 0x29fe1685 So how in hell did your hash_func get set to 0x29e55d87 instead of 0x29fe16b7 ? (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.