Date: Fri, 29 Apr 2011 10:14:36 +0100 From: David Woodhouse <dwmw2@infradead.org> To: Matthias Apitz <guru@unixarea.de> Cc: gnome@freebsd.org, evolution-list@gnome.org Subject: Re: [Evolution] evolution-2.32.1 (FreeBSD HEAD) && calendar not working Message-ID: <1304068476.32168.20.camel@macbook.infradead.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1304068476.32168.20.camel>